Changes between Version 108 and Version 109 of DeveloperGuidelinesTesting

08/08/11 20:45:42 (10 years ago)
Mike A

Added notes on unit tests and test command instructions


  • DeveloperGuidelinesTesting

    v108 v109  
    6060  * [ Lightning Talk] (2.30)
    6161== Unit Tests ==
    62 Building the Code Right
     62"Building the Code Right"
     64Unit tests test the system at the level of units of source code a.k.a. code blocks. Not to be confused with functional or acceptance/customer tests; unit tests verify rather than validate.
     67 * stability and reliability - vital for scaling developer teams due to the need for a stable trunk,
     68 * self documenting system - with documentation that can't drift.
     69 * simplification of integration testing (because all the parts are known to work, only interfaces between them need testing),
     70 * better system design by:
     71 * * easing refactoring (changes can be more rapidly verified not to create new bugs),
     72 * * promoting refactoring (dividing units into testable pieces also creates more reusable pieces),
     73 * * standing in for specification documents (i.e. describing by example what the code needs to do).
     76* it takes time to develop and maintain the tests - which means sloppy tests are as bad or worse than sloppy code.
     78=== Test Runner ===
     80Web2py imposes a severe problem on any external test runner, i.e. application code is provided a global environment by web2py, it must expect that environment. Therefore, the test runner must reproduce and provide that environment to the tests. This means that we can't use any external test runner that doesn't know about web2py.
     82nose is a python module/command which finds and runs tests. nose is suitable as it has been widely adopted in the python community, allows standard test specifications and is highly configurable and customisable, without confusing "magical" behaviour. To work with web2py, a plugin has been written, which means that nosetests isn't run in the normal way, although we'll aim for that as much as possible.
     84To run the unit tests in Sahana Eden via nose, there is a command in the tests/ folder within the application. Note: This command is not installed outside of the application as it is designed for developers, who may have several versions of Sahana Eden at any one time.
     86=== Examples ===
     87Assume our current directory is web2py/, which contains the applications folder.
     89To run all unit tests:
     90{{{ ./application/trunk/tests/ }}}
     92Currently these tests are stored in {{{/tests}}}. The nose plugin will look for tests in this folder. To select tests, give a file or folder path relative to the tests folder.
     94For example, there is a gis folder containing tests for the GIS mapping code. To run these particular tests:
     95{{{ ./application/trunk/tests/ gis }}}
     97Particular python version. runs the tests with whichever python version ran it. It will use /usr/bin/python if run as an ordinary command as above. To select a different python version run (e.g. python 2.5):
     98{{{ /path/to/python2.5 ./application/trunk/tests/ }}}
     100This may be useful to test different versions but also installed modules. N.B. No testing has been done with virtualenv as of this time.
     102=== Javascript unit tests ===
     103Selenium enables functional testing but not really unit testing other than reporting the results of javascript test runs.
    64105[ Selenium RC] is great due to ability to handle !JavaScript & also due to having an [ IDE] for generating them (export as Python).[[BR]]
    65106The IDE output needs to be [ modified] to work with Web2Py.[[BR]]
    66107NB Custom functions (e.g. for Random) cannot be shared with the Functional Tests (custom=JS) but the rest of the tests can be.[[BR]]
    67 These tests are stored in {{{/tests}}}.[[BR]]
    68108!ToDo:  Port the storeRandom function from JS to Python: