Merge lp:~coreygoldberg/selenium-simple-test/bump-version-0-2-5dev into lp:selenium-simple-test
- bump-version-0-2-5dev
- Merge into trunk
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 |
Related bugs: |
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)
Vincent Ladeuil (vila) wrote : | # |
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-
Vincent Ladeuil (vila) wrote : | # |
Appending '~dev' instead of 'dev' should work.
Vincent Ladeuil (vila) wrote : | # |
Never mind, I've found a workaround for the ppa: I released a 0.2.5~bzr430-
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
Corey Goldberg (coreygoldberg) wrote : | # |
added the changelog section, and updated README properly. I should have done that *before* release :/
Corey Goldberg (coreygoldberg) : | # |
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_
306 -
Why did you remove that ? AFAIR, I added it because it's required and wasn't easy to guess.
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/
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.
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/
> 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) 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
Corey Goldberg (coreygoldberg) wrote : | # |
pushed.
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
Corey Goldberg (coreygoldberg) : | # |
Preview Diff
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 |
Would be worth adding the header in docs/changelog.rst no ?