Menu
▾
▴
Tree [80c337] master / tests / History
Read Me
Lurch uses a lot of unit testing, especially for the core (non-GUI) functionality. This has tons of advantages which I won't belabor here; Google unit testing if you're curious. Each subdirectory of this trunk/tests directory has one unit test in it. It is a small, command-line application that runs tests and reports on their success/failure. It contains a simple run_test.sh (Unix) script that will build the most recent version of the test (if needed) and then run it, reporting errors if they occur either when the test is being built or when it is being run. To run all tests at once, see the trunk/utils/testlurch script, which can not only do that, but also summarize the output, test builds of other utilities, ensure you have the latest version checked out from SVN, etc. The create_tests script in this directory can be useful for automating the creation of a new test_* subdirectory. It assumes you're running it with one command line argument, the name of a class to test, one that's defined in .h and .cpp files in trunk/. It creates the directory and source code for the unit test and tries to build and run an empty test. This may or may not succeed depending on whether you have such a class that needs testing; if not, you'll need to tweak the generated code and documentation a bit to make it make sense for your situation. For instance, test_lob is a unit test whose skeleton/stubs could have been created by running create_tests Lob, because there are lob.h and lob.cpp files in trunk/, and the Lob class defined therein is what we wanted to test. However, test_script is not so. If you ran create_tests script, you would get a test_script directory with a test_script.cpp file in it, and corresponding test_script.pro and run_test.sh files, but they would be trying to test a nonexistant class Script defined in nonexistant files trunk/script.h and trunk/script.cpp. So you would need to tweak the autogenerated code to suit your needs. Lastly, tests written in JavaScript are in the trunk/tests/script_tests subdirectory, and there is a suitable run_test.sh file therein that can be invoked on any of the .js files in that directory to run that script-based unit test. They use the script-based unit testing tools defined in the qstestlib subdirectory, which are written by Kent Hansen and are described in the README_LURCH file in that same subdirectory.