DevNotes_DevGuide_CodeTesting

Testing SasView code (Draft)

There are three different ways to perform code testing in SasView depending on what part of functionality we are testing: core, models, GUI

1. For sasview core, tests are located in sasview/test.

• Tests are stored in subdirectories of the test directory, as package/test/utest_*.py.
• Other files in the test subdirectory are data, expected output and other support files.
• Before running any tests you must first run setup.py build in the root.
• Tests are run against the current source directory with run magic to find the compiled code, so you only need to rebuild between tests if you are modifying the C code.

2. For 5.x GUI, tests are located in respective folders e.g for Fitting sasview/src/sas/qtgui/Perspectives/Fitting/UnitTesting/.

• For this part we use unit test with MagickMock (for general introduction please refer to https://www.thedigitalcatonline.com/blog/2016/03/06/python-mocks-a-gentle-introduction-part-1/ and https://aaronlelevier.github.io/python-unit-testing-with-magicmock/)

3. For sasmodels tests are part of model definition (see https://github.com/SasView/sasmodels/blob/master/doc/guide/plugin.rst#test-your-new-model)

General notes about tests

• Unit tests should test one method only. This allows you to easily identify what failed if the test fails.
• Unit tests should not be coupled together, therefore one unit test CANNOT rely on another unit test having completed first.
• Unit tests should use small and simple data sets.
• Tests should be fast, ideally really fast - certainly not more than a few seconds.
• Untestable code is a code-smell, if you can't get the code under test it probably needs refactoring.
• Weight your testing to be destructive rather than demonstrative. Destructive tests are more efficient in finding bugs.
• Use long and descriptive names for testing functions. The reason is testing functions are never called explicitly. square() or even sqr() is ok in running code, but in testing code you would have names such as test_square_of_number_2(),test_square_negative_number(). These function names are displayed when a test fails, and should be as descriptive as possible.
• Attributes of a good test: Fast, Clear, Isolated, Reliable
• Models: Include at least one test for each model and PLEASE make sure that the answer value is correct (i.e. don't blindly use the function return value to set the test results; instead check against the paper or another program).
• Models: Remember to test a model for critical values (e.g. q=0)