Skip to content

Writing functional tests

Eugene Alvin Villar edited this page Mar 28, 2018 · 4 revisions

Test code structure

Tests inside the cadasta-test repository are generally divided according to the test cases they implement in the Functional Test Cases spreadsheet. For example, tests for the User Accounts test cases can be found under the account_tests directory and tests for the Resources test cases can be found under the resource_tests directory.

Furthermore, tests are generally divided into test files that correspond to the sub-feature column of the Functional Test Cases spreadsheet. For example, tests for the Login sub-feature of the User Accounts test cases can be found in the account_tests\test_login.py test file. Each test file should only have one test class named with the sub-feature (e.g., TestLogin) and all test classes inherit from the SeleniumTestCase base class found in the base_test.py file.

Individual tests are implemented as individual methods of the test class and named test_<name> where <name> is generally the same as the corresponding test case title in the Functional Test Cases spreadsheet. For example, the test that implements the Projects #U1 test case (“PM can update project”) is named test_pm_can_update_project.

For tests that implement more than one test case, use a test name that makes sense for those test cases. For example, the test that implements the Records #LC1 (“User can create location”) and #LD1 (“User can delete location”) test cases is named test_user_can_create_delete_location.

For all tests, they should have a docstring indicating which test cases they are targeting for traceability with the Functional Test Cases spreadsheet. For example, the test_user_can_create_delete_location test has the following docstring:

"""Verifies Records test case #LC1, #LD1."""

Test fixtures

Tips

Clone this wiki locally