Merge lp:~coreygoldberg/selenium-simple-test/bump-version-0-2-5dev into lp:selenium-simple-test

[Corey Goldberg]

bump version to 0.2.5dev

bumped version number to 0.2.5dev (post-release)

[Vincent Ladeuil (vila)]

Would be worth adding the header in docs/changelog.rst no ?

[Vincent Ladeuil (vila)]

I encounter issues with packaging around the version string.

It appears that '0.2.4dev' is greater than '0.2.4' so both 'bzr merge-upstream' and the ppa fail to recognize '0.2.4' as the final release version string.

We need to use a different scheme than appending 'dev'.

And the simplest way to address the packaging issues would be to release '0.2.5' as a bump-release-version only :-/

review: Needs Fixing

[Vincent Ladeuil (vila)]

Appending '~dev' instead of 'dev' should work.

[Vincent Ladeuil (vila)]

Never mind, I've found a workaround for the ppa: I released a 0.2.5~bzr430-0ubuntu2 which is really 0.2.4.

I'll file a merge proposal for my updates of the packaging.rst doc once 0.2.5 is opened.

In summary, just create the section in changelog.rst and we'll be good.

[lp:~coreygoldberg/selenium-simple-test/bump-version-0-2-5dev]

432. By Corey Goldberg on 2013-07-31

updated README to match index.rst content

433. By Corey Goldberg on 2013-07-31

fixed rst headers in release instructions

434. By Corey Goldberg on 2013-07-31

added changelog section for 0.2.5

[Corey Goldberg (coreygoldberg)]

added the changelog section, and updated README properly. I should have done that *before* release :/

[Corey Goldberg (coreygoldberg)]

review: Needs Resubmitting

[Vincent Ladeuil (vila)]

We shouldn't duplicate that much between README and index.rst especially when we have up-to-date doc online as per the release process :-/

Would you mind simplify the README in this direction ?

305 - * run `make_actions_rst.py` under /docs, which will create `actions.rst`
306 -

Why did you remove that ? AFAIR, I added it because it's required and wasn't easy to guess.

[Corey Goldberg (coreygoldberg)]

> We shouldn't duplicate that much between README and index.rst

I think I agree. So, the README is what ends up on the PyPI index page as documentation when we release there. It made sense to have some basic instructions/examples for using it there (common practice)... but it's grown much too big :)

I can trim it down to just a few line description with a link to the official web docs. I think that makes more sense.

> Why did you remove that ?

that step was duplicated.. it's already listed in the step above.

http://bazaar.launchpad.net/~coreygoldberg/selenium-simple-test/bump-version-0-2-5dev/view/head:/docs/releasing.rst#L35

[Vincent Ladeuil (vila)]

> > We shouldn't duplicate that much between README and index.rst
>
> I think I agree. So, the README is what ends up on the PyPI index page as
> documentation when we release there. It made sense to have some basic
> instructions/examples for using it there (common practice)... but it's grown
> much too big :)
>
> I can trim it down to just a few line description with a link to the official
> web docs. I think that makes more sense.

Great, let's do that !

>
>
>
> > Why did you remove that ?
>
> that step was duplicated.. it's already listed in the step above.

/me blinks

WTH ?

Oh, I think I remember now. 'generate HTML documentation' is what I was looking for. 'generate actions doc' doesn't make much sense to me at the time.

I think having all steps in 'generate HTML documentation' is clearer so the reader doesn't have to guess the relationship between the two steps.

Does that make sense ?

[Corey Goldberg (coreygoldberg)]

> > I can trim it down to just a few line description with a link to the
> official
> > web docs. I think that makes more sense.
>
> Great, let's do that !

will do. I will update this branch.

> > > Why did you remove that ?
> >
> > that step was duplicated.. it's already listed in the step above.
>
> /me blinks
> I think having all steps in 'generate HTML documentation' is clearer so the
> reader doesn't have to guess the relationship between the two steps.
>
> Does that make sense ?

yes, I'll update as well.

[lp:~coreygoldberg/selenium-simple-test/bump-version-0-2-5dev]

435. By Corey Goldberg on 2013-07-31

moved generate actions.rst instructions within release doc

436. By Corey Goldberg on 2013-07-31

trimmed down README

[Corey Goldberg (coreygoldberg)]

pushed.

[Vincent Ladeuil (vila)]

<3 So much clearer !

Thanks for the fixes in releasing.txt, I can never find the correct rst rules... there are so many of them used differently on different projects ;-D

review: Approve

[Corey Goldberg (coreygoldberg)]

review: Approve

=== modified file 'README'
--- README	2013-06-03 18:15:36 +0000
+++ README	2013-07-31 18:03:25 +0000
@@ -16,16 +16,17 @@
 SST (selenium-simple-test) is a web test framework that uses Python
 to generate functional browser-based tests.
 
-Tests are made up of scripts, created by composing actions that drive
-a browser and assert conditions. You have the flexibilty of the full
-Python language, along with a convenient set of functions to simplify
-web testing.
+Tests are made up of scripts or test case classes, created by composing
+actions that drive a browser and assert conditions. You have the flexibilty
+of the full Python language, along with a convenient set of functions to
+simplify web testing.
 
 SST consists of:
 
  * user actions and assertions (API) in Python
  * test case loader (generates/compiles scripts to unittest cases)
  * console test runner
+ * concurrent/parallel tests
  * data parameterization/injection
  * selectable output reports
  * selectable browsers
@@ -40,304 +41,16 @@
     Install
 -----------
 
-SST can be installed from `PyPI <http://pypi.python.org/pypi/sst>`_ using
+SST can be installed or upgraded from `PyPI <http://pypi.python.org/pypi/sst>`_ using
 `pip <http://www.pip-installer.org>`_::
 
     pip install -U sst
 
-For example, on an Ubuntu/Debian system, you could Install SST (system-wide)
-like this::
-
-    $ sudo apt-get install python-pip xvfb
-    $ sudo pip install -U sst
-
-or with a `virtualenv`::
-
-    $ sudo apt-get install python-virtualenv xvfb
-    $ virtualenv ENV
-    $ source ENV/bin/activate
-    (ENV)$ pip install sst
-
-* note: `xvfb` is only needed if you want to run SST in headless mode
-
-
----------------------------
-    Example SST test script
----------------------------
-
-a sample test case in SST::
-
-    from sst.actions import *
-
-    go_to('http://www.ubuntu.com/')
-    assert_title_contains('Ubuntu')
-
-
-------------------------------------
-    Running a test with SST
-------------------------------------
-
-Create a Python script (.py) file, and add your test code.
-
-Then call your test script from the command line, using `sst-run`::
-
-    $ sst-run mytest
-
-* note: you don't add the .py extension to your test invocation
-
-
------------------------------------
-    Actions reference (sst.actions)
------------------------------------
-
-Test scripts perform actions in the browser as if they were a user.
-SST provides a set of "actions" (functions) for use in your tests.
-These actions are defined in the following API:
-
- * `Actions Reference <http://testutils.org/sst/actions.html>`_
-
-
-------------------------------------
-    Command line options for sst-run
-------------------------------------
-
-Usage: `sst-run <options> [testname]`
-
-* Calling sst-run with testname(s) as arguments will just run
-  those tests. The testnames should not include '.py' at
-  the end of the filename.
-
-* You may optionally create a data file for data-driven
-  testing.  Create a '^' delimited txt data file with the same
-  name as the test, plus the '.csv' extension.  This will
-  run a test using each row in the data file (1st row of data
-  file is variable name mapping)
-
-Options::
-
-  -h, --help                show this help message and exit
-  -d DIR_NAME               directory of test case files
-  -r REPORT_FORMAT          report type: xml
-  -b BROWSER_TYPE           select webdriver (Firefox, Chrome, PhantomJS, etc)
-  -j                        disable javascript in browser
-  -m SHARED_MODULES         directory for shared modules
-  -q                        output less debugging info during test run
-  -V                        print version info and exit
-  -s                        save screenshots on failures
-  -x                        run browser in headless xserver (Xvfb)
-  --failfast                stop test execution after first failure
-  --debug                   drop into debugger on test fail or error
-  --with-flags=WITH_FLAGS   comma separated list of flags to run tests with
-  --disable-flag-skips      run all tests, disable skipping tests due to flags
-  --extended-tracebacks     add extra information (page source) to failure reports
-  --collect-only            collect/print cases without running tests
-  --test                    run selftests (acceptance tests with django server)
-
-
---------------------
-    Organizing tests
---------------------
-
-For logical organization of tests, you can use directories in your filesystem.
-SST will recursively walk your directory tree and gather all tests for
-execution.
-
-For example, a simple test setup might look like::
-
-    /selenium-simple-test
-        /mytests
-            foo.py
-
-and you would call this from the command line::
-
-    $ sst-run -d mytests
-
-A more complex setup might look like::
-
-    /selenium-simple-test
-        /mytests
-            /project_foo
-                /feature_foo
-                    foo.py
-            /project_bar
-                feature_bar.py
-                feature_baz.py
-            /shared
-                module.py
-                utils.py
-
-and you would still call this from the command like::
-
-    $ sst-run -d mytests
-
-SST will find all of the tests in subdirectories (including symlinks) and
-execute them. SST won't look in directories starting with an underscore. This
-allows you to put Python packages/modules directly in your test directories
-if you want. A better option is to use the shared directory.
-
-
----------------------------------
-Using sst in unittest test suites
----------------------------------
-
-sst uses unittest test cases internally to wrap the execution of the script
-and taking care of starting and stopping the browser. If you prefer to
-integrate some sst tests into an existing unittest test suite you can use
-SSTTestCase from runtests.py::
-
-  from sst.actions import *
-  from sst import runtests
-
-  class TestUbuntu(runtests.SSTTestCase):
-
-      def test_ubuntu_home_page(self):
-          go_to('http://www.ubuntu.com/')
-          assert_title_contains('Ubuntu')
-
-So, with the above in a file name test_ubuntu.py you can run the test with
-(for example)::
-
-  python -m unittest test_ubuntu.py
-
-`sst-run` provides an headless xserver via the `-x` option. `SSTTestCase`
-provides the same feature (sharing the same implementation) via two class
-attributes.
-
-`xserver_headless` when set to `True` will start an headless server for each
-test (and stop it after the test). If you want to share the same server
-across several tests, set `xvfb`. You're then responsible for starting and
-stopping this server (see `src/sst/xvfbdisplay.py` for details or
-`src/sst/tests/test_xvfb.py` for examples.
-
-
---------------------
-    Shared directory
---------------------
-
-SST allows you to have a directory called `shared` in the top level directory
-of your tests, which is added to `sys.path`. Here you can keep helper modules
-used by all your tests. `sst-run` will not run Python files in the `shared`
-directory as tests.
-
-By default SST looks in the test directory you specify to find `shared`,
-alternatively you can specify a different directory using the `-m` command
-line argument to `sst-run`.
-
-If there is no `shared` directory in the test directory, then `sst-run` will
-walk up from the test directory to the current directory looking for one. This
-allows you to run tests just from a subdirectory without having to explicitly
-specify where the shared directory is.
-
-
----------------------
-    sst.config module
----------------------
-
-Inside tests you can import the `sst.config` module to know various things
-about the current test environment. The `sst.config` module has the following
-information::
-
-    from sst import config
-
-    # is javascript disabled?
-    config.javascript_disabled
-
-    # which browser is being used?
-    config.browser_type
-
-    # full path to the shared directory
-    config.shared_directory
-
-    # full path to the results directory
-    config.results_directory
-
-    # flags for the current test run
-    config.flags
-
-    # A per test cache. A dictionary that is cleared at the start of each test.
-    config.cache
-
-------------------------
-    Disabling Javascript
-------------------------
-
-If you need to disable Javascript for an individual test you can do it by
-putting the following at the start of the test::
-
-    JAVASCRIPT_DISABLED = True
-
-
---------------------------------
-    Development on Ubuntu/Debian
---------------------------------
-
-* SST is primarily being developed on Linux, specifically Ubuntu. It should
-  work fine on other platforms, but any issues (or even better - patches)
-  should be reported on the Launchpad project.
-
-* Get a copy of SST Trunk, create and activate a virtualenv, install requirements, 
-  and run examples/self-tests from the dev branch::
-
-    $ sudo apt-get install bzr python-virtualenv xvfb
-    $ bzr branch lp:selenium-simple-test
-    $ cd selenium-simple-test
-    $ virtualenv ENV
-    $ source ENV/bin/activate
-    (ENV)$ pip install -r requirements.txt
-    (ENV)$ ./sst-run -d examples
-    
-* (optional) Install test dependencies and run SST's internal unit tests::
-
-    (ENV)$ pip install mock nose pep8
-    (ENV)$ nosetests --match ^test_.* --exclude="ENV|testproject|selftests"
-
-* (optional) Install `django` and run SST's internal test application with
-  acceptance tests
-
-    (ENV)$ pip install django
-    (ENV)$ ./sst-run --test -x
-
-* `Launchpad Project <https://launchpad.net/selenium-simple-test>`_
-
-* `Browse the Source (Trunk)
-  <http://bazaar.launchpad.net/~canonical-isd-qa/selenium-simple-test/trunk/files>`_
-
-* To manually setup dependencies, SST uses the following non-stdlib packages:
-
-    * selenium
-    * testtools
-    * django (optional - needed for internal self-tests only)
-
-------------------------
-    Running the examples
-------------------------
-
-SST source code repository and package download contain some trivial example
-scripts.
-
-You can run them from your local sst directory like this::
-
-    $ ./sst-run -d examples
-
-
---------------------------
-    Running the self-tests
---------------------------
-
-SST source code repository and package download contain a set of self-tests
-based on an included test Django project.
-
-You can run the suite of self-tests (and the test Django server) from your
-local branch like this::
-
-    $ ./sst-run --test
-
-
------------------
-    Related links
------------------
-
-* `Selenium Project Home <http://selenium.googlecode.com>`_
-* `Selenium WebDriver (from 'Architecture of Open Source Applications')
-  <http://www.aosabook.org/en/selenium.html>`_
-* `Python Unittest <http://docs.python.org/library/unittest.html>`_
+
+--------------------------
+    Official Documentation
+--------------------------
+
+Please visit the official docs at: `http://testutils.org/sst <http://testutils.org/sst>`_
+
+For the full `actions` reference, go directly to: `http://testutils.org/sst/actions.html <http://testutils.org/sst/actions.html>`_
 
=== modified file 'docs/changelog.rst'
--- docs/changelog.rst	2013-07-30 13:55:45 +0000
+++ docs/changelog.rst	2013-07-31 18:03:25 +0000
@@ -9,6 +9,10 @@
 Official Releases:
 ------------------
 
+version **0.2.5** (under development)
+*************************************
+
+
 version **0.2.4** (2013 July 30)
 ********************************
 
 
=== modified file 'docs/releasing.rst'
--- docs/releasing.rst	2013-05-23 10:11:12 +0000
+++ docs/releasing.rst	2013-07-31 18:03:25 +0000
@@ -1,7 +1,10 @@
-SST Release Instructions
+============================
+    SST Release Instructions
+============================
 
-Instructions for releasing SST to PyPI from Launchpad Trunk
------------------------------------------------------------
+---------------------------------------------------------------
+    Instructions for releasing SST to PyPI from Launchpad Trunk
+---------------------------------------------------------------
 
 * get a branch of SST trunk:
 
@@ -29,17 +32,15 @@
 
     $ bzr push lp:selenium-simple-test
 
-* generate actions doc:
-
-    under /docs, run:
-
-    $ python make_actions_rst.py
-
 * generate HTML documentation:
 
     * install sphinx (`$ sudo apt-get install python-sphinx`)
 
-    * run `make_actions_rst.py` under /docs, which will create `actions.rst`
+    * generate `actions.rst` doc:
+
+        under /docs, run:
+
+        $ python make_actions_rst.py
 
     * go up to the main SST directory and run:
 
 
=== modified file 'src/sst/__init__.py'
--- src/sst/__init__.py	2013-07-30 13:55:45 +0000
+++ src/sst/__init__.py	2013-07-31 18:03:25 +0000
@@ -18,7 +18,7 @@
 #
 
 
-__version__ = '0.2.4'
+__version__ = '0.2.5dev'
 
 DEVSERVER_PORT = 8120  # django devserver for internal acceptance tests