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

Proposed by Corey Goldberg
Status: Merged
Approved by: Corey Goldberg
Approved revision: 436
Merged at revision: 431
Proposed branch: lp:~coreygoldberg/selenium-simple-test/bump-version-0-2-5dev
Merge into: lp:selenium-simple-test
Diff against target: 407 lines (+30/-312)
4 files modified
README (+14/-301)
docs/changelog.rst (+4/-0)
docs/releasing.rst (+11/-10)
src/sst/__init__.py (+1/-1)
To merge this branch: bzr merge lp:~coreygoldberg/selenium-simple-test/bump-version-0-2-5dev
Reviewer Review Type Date Requested Status
Corey Goldberg (community) Approve
Vincent Ladeuil (community) Approve
Review via email: mp+177696@code.launchpad.net

Commit message

bump version to 0.2.5dev

Description of the change

bumped version number to 0.2.5dev (post-release)

To post a comment you must log in.
Revision history for this message
Vincent Ladeuil (vila) wrote :

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

Revision history for this message
Vincent Ladeuil (vila) wrote :

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
Revision history for this message
Vincent Ladeuil (vila) wrote :

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

Revision history for this message
Vincent Ladeuil (vila) wrote :

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.

432. By Corey Goldberg

updated README to match index.rst content

433. By Corey Goldberg

fixed rst headers in release instructions

434. By Corey Goldberg

added changelog section for 0.2.5

Revision history for this message
Corey Goldberg (coreygoldberg) wrote :

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

Revision history for this message
Corey Goldberg (coreygoldberg) :
review: Needs Resubmitting
Revision history for this message
Vincent Ladeuil (vila) wrote :

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.

Revision history for this message
Corey Goldberg (coreygoldberg) wrote :

> 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

Revision history for this message
Vincent Ladeuil (vila) wrote :

> > 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 ?

Revision history for this message
Corey Goldberg (coreygoldberg) wrote :

> > 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.

435. By Corey Goldberg

moved generate actions.rst instructions within release doc

436. By Corey Goldberg

trimmed down README

Revision history for this message
Corey Goldberg (coreygoldberg) wrote :

pushed.

Revision history for this message
Vincent Ladeuil (vila) wrote :

<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
Revision history for this message
Corey Goldberg (coreygoldberg) :
review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'README'
2--- README 2013-06-03 18:15:36 +0000
3+++ README 2013-07-31 18:03:25 +0000
4@@ -16,16 +16,17 @@
5 SST (selenium-simple-test) is a web test framework that uses Python
6 to generate functional browser-based tests.
7
8-Tests are made up of scripts, created by composing actions that drive
9-a browser and assert conditions. You have the flexibilty of the full
10-Python language, along with a convenient set of functions to simplify
11-web testing.
12+Tests are made up of scripts or test case classes, created by composing
13+actions that drive a browser and assert conditions. You have the flexibilty
14+of the full Python language, along with a convenient set of functions to
15+simplify web testing.
16
17 SST consists of:
18
19 * user actions and assertions (API) in Python
20 * test case loader (generates/compiles scripts to unittest cases)
21 * console test runner
22+ * concurrent/parallel tests
23 * data parameterization/injection
24 * selectable output reports
25 * selectable browsers
26@@ -40,304 +41,16 @@
27 Install
28 -----------
29
30-SST can be installed from `PyPI <http://pypi.python.org/pypi/sst>`_ using
31+SST can be installed or upgraded from `PyPI <http://pypi.python.org/pypi/sst>`_ using
32 `pip <http://www.pip-installer.org>`_::
33
34 pip install -U sst
35
36-For example, on an Ubuntu/Debian system, you could Install SST (system-wide)
37-like this::
38-
39- $ sudo apt-get install python-pip xvfb
40- $ sudo pip install -U sst
41-
42-or with a `virtualenv`::
43-
44- $ sudo apt-get install python-virtualenv xvfb
45- $ virtualenv ENV
46- $ source ENV/bin/activate
47- (ENV)$ pip install sst
48-
49-* note: `xvfb` is only needed if you want to run SST in headless mode
50-
51-
52----------------------------
53- Example SST test script
54----------------------------
55-
56-a sample test case in SST::
57-
58- from sst.actions import *
59-
60- go_to('http://www.ubuntu.com/')
61- assert_title_contains('Ubuntu')
62-
63-
64-------------------------------------
65- Running a test with SST
66-------------------------------------
67-
68-Create a Python script (.py) file, and add your test code.
69-
70-Then call your test script from the command line, using `sst-run`::
71-
72- $ sst-run mytest
73-
74-* note: you don't add the .py extension to your test invocation
75-
76-
77------------------------------------
78- Actions reference (sst.actions)
79------------------------------------
80-
81-Test scripts perform actions in the browser as if they were a user.
82-SST provides a set of "actions" (functions) for use in your tests.
83-These actions are defined in the following API:
84-
85- * `Actions Reference <http://testutils.org/sst/actions.html>`_
86-
87-
88-------------------------------------
89- Command line options for sst-run
90-------------------------------------
91-
92-Usage: `sst-run <options> [testname]`
93-
94-* Calling sst-run with testname(s) as arguments will just run
95- those tests. The testnames should not include '.py' at
96- the end of the filename.
97-
98-* You may optionally create a data file for data-driven
99- testing. Create a '^' delimited txt data file with the same
100- name as the test, plus the '.csv' extension. This will
101- run a test using each row in the data file (1st row of data
102- file is variable name mapping)
103-
104-Options::
105-
106- -h, --help show this help message and exit
107- -d DIR_NAME directory of test case files
108- -r REPORT_FORMAT report type: xml
109- -b BROWSER_TYPE select webdriver (Firefox, Chrome, PhantomJS, etc)
110- -j disable javascript in browser
111- -m SHARED_MODULES directory for shared modules
112- -q output less debugging info during test run
113- -V print version info and exit
114- -s save screenshots on failures
115- -x run browser in headless xserver (Xvfb)
116- --failfast stop test execution after first failure
117- --debug drop into debugger on test fail or error
118- --with-flags=WITH_FLAGS comma separated list of flags to run tests with
119- --disable-flag-skips run all tests, disable skipping tests due to flags
120- --extended-tracebacks add extra information (page source) to failure reports
121- --collect-only collect/print cases without running tests
122- --test run selftests (acceptance tests with django server)
123-
124-
125---------------------
126- Organizing tests
127---------------------
128-
129-For logical organization of tests, you can use directories in your filesystem.
130-SST will recursively walk your directory tree and gather all tests for
131-execution.
132-
133-For example, a simple test setup might look like::
134-
135- /selenium-simple-test
136- /mytests
137- foo.py
138-
139-and you would call this from the command line::
140-
141- $ sst-run -d mytests
142-
143-A more complex setup might look like::
144-
145- /selenium-simple-test
146- /mytests
147- /project_foo
148- /feature_foo
149- foo.py
150- /project_bar
151- feature_bar.py
152- feature_baz.py
153- /shared
154- module.py
155- utils.py
156-
157-and you would still call this from the command like::
158-
159- $ sst-run -d mytests
160-
161-SST will find all of the tests in subdirectories (including symlinks) and
162-execute them. SST won't look in directories starting with an underscore. This
163-allows you to put Python packages/modules directly in your test directories
164-if you want. A better option is to use the shared directory.
165-
166-
167----------------------------------
168-Using sst in unittest test suites
169----------------------------------
170-
171-sst uses unittest test cases internally to wrap the execution of the script
172-and taking care of starting and stopping the browser. If you prefer to
173-integrate some sst tests into an existing unittest test suite you can use
174-SSTTestCase from runtests.py::
175-
176- from sst.actions import *
177- from sst import runtests
178-
179- class TestUbuntu(runtests.SSTTestCase):
180-
181- def test_ubuntu_home_page(self):
182- go_to('http://www.ubuntu.com/')
183- assert_title_contains('Ubuntu')
184-
185-So, with the above in a file name test_ubuntu.py you can run the test with
186-(for example)::
187-
188- python -m unittest test_ubuntu.py
189-
190-`sst-run` provides an headless xserver via the `-x` option. `SSTTestCase`
191-provides the same feature (sharing the same implementation) via two class
192-attributes.
193-
194-`xserver_headless` when set to `True` will start an headless server for each
195-test (and stop it after the test). If you want to share the same server
196-across several tests, set `xvfb`. You're then responsible for starting and
197-stopping this server (see `src/sst/xvfbdisplay.py` for details or
198-`src/sst/tests/test_xvfb.py` for examples.
199-
200-
201---------------------
202- Shared directory
203---------------------
204-
205-SST allows you to have a directory called `shared` in the top level directory
206-of your tests, which is added to `sys.path`. Here you can keep helper modules
207-used by all your tests. `sst-run` will not run Python files in the `shared`
208-directory as tests.
209-
210-By default SST looks in the test directory you specify to find `shared`,
211-alternatively you can specify a different directory using the `-m` command
212-line argument to `sst-run`.
213-
214-If there is no `shared` directory in the test directory, then `sst-run` will
215-walk up from the test directory to the current directory looking for one. This
216-allows you to run tests just from a subdirectory without having to explicitly
217-specify where the shared directory is.
218-
219-
220----------------------
221- sst.config module
222----------------------
223-
224-Inside tests you can import the `sst.config` module to know various things
225-about the current test environment. The `sst.config` module has the following
226-information::
227-
228- from sst import config
229-
230- # is javascript disabled?
231- config.javascript_disabled
232-
233- # which browser is being used?
234- config.browser_type
235-
236- # full path to the shared directory
237- config.shared_directory
238-
239- # full path to the results directory
240- config.results_directory
241-
242- # flags for the current test run
243- config.flags
244-
245- # A per test cache. A dictionary that is cleared at the start of each test.
246- config.cache
247-
248-------------------------
249- Disabling Javascript
250-------------------------
251-
252-If you need to disable Javascript for an individual test you can do it by
253-putting the following at the start of the test::
254-
255- JAVASCRIPT_DISABLED = True
256-
257-
258---------------------------------
259- Development on Ubuntu/Debian
260---------------------------------
261-
262-* SST is primarily being developed on Linux, specifically Ubuntu. It should
263- work fine on other platforms, but any issues (or even better - patches)
264- should be reported on the Launchpad project.
265-
266-* Get a copy of SST Trunk, create and activate a virtualenv, install requirements,
267- and run examples/self-tests from the dev branch::
268-
269- $ sudo apt-get install bzr python-virtualenv xvfb
270- $ bzr branch lp:selenium-simple-test
271- $ cd selenium-simple-test
272- $ virtualenv ENV
273- $ source ENV/bin/activate
274- (ENV)$ pip install -r requirements.txt
275- (ENV)$ ./sst-run -d examples
276-
277-* (optional) Install test dependencies and run SST's internal unit tests::
278-
279- (ENV)$ pip install mock nose pep8
280- (ENV)$ nosetests --match ^test_.* --exclude="ENV|testproject|selftests"
281-
282-* (optional) Install `django` and run SST's internal test application with
283- acceptance tests
284-
285- (ENV)$ pip install django
286- (ENV)$ ./sst-run --test -x
287-
288-* `Launchpad Project <https://launchpad.net/selenium-simple-test>`_
289-
290-* `Browse the Source (Trunk)
291- <http://bazaar.launchpad.net/~canonical-isd-qa/selenium-simple-test/trunk/files>`_
292-
293-* To manually setup dependencies, SST uses the following non-stdlib packages:
294-
295- * selenium
296- * testtools
297- * django (optional - needed for internal self-tests only)
298-
299-------------------------
300- Running the examples
301-------------------------
302-
303-SST source code repository and package download contain some trivial example
304-scripts.
305-
306-You can run them from your local sst directory like this::
307-
308- $ ./sst-run -d examples
309-
310-
311---------------------------
312- Running the self-tests
313---------------------------
314-
315-SST source code repository and package download contain a set of self-tests
316-based on an included test Django project.
317-
318-You can run the suite of self-tests (and the test Django server) from your
319-local branch like this::
320-
321- $ ./sst-run --test
322-
323-
324------------------
325- Related links
326------------------
327-
328-* `Selenium Project Home <http://selenium.googlecode.com>`_
329-* `Selenium WebDriver (from 'Architecture of Open Source Applications')
330- <http://www.aosabook.org/en/selenium.html>`_
331-* `Python Unittest <http://docs.python.org/library/unittest.html>`_
332+
333+--------------------------
334+ Official Documentation
335+--------------------------
336+
337+Please visit the official docs at: `http://testutils.org/sst <http://testutils.org/sst>`_
338+
339+For the full `actions` reference, go directly to: `http://testutils.org/sst/actions.html <http://testutils.org/sst/actions.html>`_
340
341=== modified file 'docs/changelog.rst'
342--- docs/changelog.rst 2013-07-30 13:55:45 +0000
343+++ docs/changelog.rst 2013-07-31 18:03:25 +0000
344@@ -9,6 +9,10 @@
345 Official Releases:
346 ------------------
347
348+version **0.2.5** (under development)
349+*************************************
350+
351+
352 version **0.2.4** (2013 July 30)
353 ********************************
354
355
356=== modified file 'docs/releasing.rst'
357--- docs/releasing.rst 2013-05-23 10:11:12 +0000
358+++ docs/releasing.rst 2013-07-31 18:03:25 +0000
359@@ -1,7 +1,10 @@
360-SST Release Instructions
361+============================
362+ SST Release Instructions
363+============================
364
365-Instructions for releasing SST to PyPI from Launchpad Trunk
366------------------------------------------------------------
367+---------------------------------------------------------------
368+ Instructions for releasing SST to PyPI from Launchpad Trunk
369+---------------------------------------------------------------
370
371 * get a branch of SST trunk:
372
373@@ -29,17 +32,15 @@
374
375 $ bzr push lp:selenium-simple-test
376
377-* generate actions doc:
378-
379- under /docs, run:
380-
381- $ python make_actions_rst.py
382-
383 * generate HTML documentation:
384
385 * install sphinx (`$ sudo apt-get install python-sphinx`)
386
387- * run `make_actions_rst.py` under /docs, which will create `actions.rst`
388+ * generate `actions.rst` doc:
389+
390+ under /docs, run:
391+
392+ $ python make_actions_rst.py
393
394 * go up to the main SST directory and run:
395
396
397=== modified file 'src/sst/__init__.py'
398--- src/sst/__init__.py 2013-07-30 13:55:45 +0000
399+++ src/sst/__init__.py 2013-07-31 18:03:25 +0000
400@@ -18,7 +18,7 @@
401 #
402
403
404-__version__ = '0.2.4'
405+__version__ = '0.2.5dev'
406
407 DEVSERVER_PORT = 8120 # django devserver for internal acceptance tests
408

Subscribers

People subscribed via source and target branches