|Version 3 (modified by 10 years ago) ( diff ),|
"A bug is a test case you haven't written yet"
"Unit Tests allow merciless refactoring"
Test-Driven Development is a programming styles which says that you 1st write your test cases (from the specs) & then proceed to make them pass.
Selenium provides the ability to test Sahana Eden as users see it - namely through a web browser. This therefore does end-to-end Functional Testing, however it can also be sued as Unit Testing
We are building our framework around the new WebDriver, despite having some legacy code in the older format:
These tests are stored in
Install Selenium Python Client Driver into your running Python:
pip install -U selenium
wget http://pypi.python.org/packages/source/s/selenium/selenium-2.20.tar.gz tar zxvf selenium-2.20.tar.gz cd selenium-2.20 python setup.py install
Latest edit on how to install Selenium Python Client Driver in your Python enviroment:
Download selenium 2.20.0 from: http://pypi.python.org/packages/source/s/selenium/selenium-2.20.0.tar.gz#md5=a1a7d86758b1b0e8561cd4a341c860e5 into an appropriate folder (for example: selenium-2.20) cd selenium-2.20 (cd into the folder you just downloaded selenium 2.20 in) sudo python setup.py install (install Selenium Python Client Driver)
You should now have Selenium in your environment
Before running the Selenium scripts, you should put your database into a known state:
For the whole test suite, it is assumed that you are using:
deployment_settings.base.prepopulate = 2
Run the whole test suite for the 'eden' application:
python web2py.py -S eden -M -R applications/eden/modules/tests/suite.py
Run a single test for the 'eden' application:
python web2py.py -S eden -M -R applications/eden/modules/tests/suite.py -A mytestfunction
We aim to make it as easy as possible to write additional tests, which can easily be plugged into the suite.
An example has been created:
New tests should be stored in a subfolder per module, adding the foldername to
eden/modules/tests/__init__.py & creating an
__init__.py in the subfolder.
The key is to make tests which are as least fragile as possible through:
- State (we should eb able to run individual tests easilty, which check their current state as-required)
This suggests refactoring tests to centralise common elements into a library to mean fixes should only happen in 1 place.
There are a number of possible selectors to use to find your elements...the 'ID' may be the most stable, so don't be afraid of patching the code to add IDs where you'd like to be able to reach them reliably:
- Store results in a format suitable for use by CI
- Namespacing of tests
- Include timings
- Run from Nose?
- TestCases - User Testing - List of things to test
- http://code.google.com/p/selenium/wiki/PageObjects - Style suggestion