Skip to content

Latest commit

 

History

History
56 lines (37 loc) · 3.86 KB

testing.rst

File metadata and controls

56 lines (37 loc) · 3.86 KB
Raw

Testing Ion

Unit tests are hugely important to ensuring that Ion functions as expected. By writing and running tests before deploying every change, we can be much more confident that our new changes don't break the existing design in Ion. As such, every change that introduces a new feature should also include at least one unit test that corresponding to that feature.

Unit Tests

For most modules, the unit tests go in intranet/apps/<module>/tests.py. Currently, the sole exception is eighth, where tests are broken out into several different files under intranet/apps/eighth/tests/. Testing functionality that is useful for multiple tests can be found in intranet/test.

Running Tests

To actually execute tests, run pytest inside your dev environment. If you want to only test a specific app, you can run pytest <apps_name>. Do note that this deletes and re-creates the db from scratch each time, so you may want to pass the -k option when developing tests as it significantly reduces run-time.

Coverage

Coverage information is auto-generated at Coveralls <https://coveralls.io/github/tjcsl/ion>. This is useful for finding files with insufficient coverage, so you can focus your test writing more accurately.

Writing Tests

Looking at pre-existing tests can give you a good idea how to structure your tests. The IonTestCase class is a wrapper around the standard Django test class. It handles some ion-specific logic, such as mocking out ldap queries. Here is an bare-bones example of the basic layout for a test:

from ...test.ion_test import IonTestCase

class ModuleTest(IonTestCase):
  def test_module_function(self):
    # Put your tests here
    self.assertEqual(1, 1)

Every test should include comments that explain, almost in narrative form, what the test is doing and what the expected results are.

Generally, there are two ways that you test Ion's code. These are not comprehensive, but should work for most cases. The first is calling methods directly; the second is making a GET or POST request to the view that you are interested in testing. The best tests utilize both. After you do either/both of these to call the code, you should use assertions to see if the code behaved as expected. A list of assertion options can be found `here <https://docs.python.org/3/library/unittest`_.html#assert-methods>`. A useful tool for making requests to the view is self.client. More documentation on that can be found here. Alternatively, just search through Ion's testing files for examples of using self.client.

Good Testing Examples

Ion has lots of tests; the following are examples of very well-written ones. Note the abundance of comments and the attention to detail. Test everything.

  • Polls - Note the throughness of the checks; assertions are made even when nothing should have changed.
  • Emailfwd - Note the use of self.client and checking messages generated by the page.
  • Eighth - eighth is the most complicated app in Ion and thus has the most varied examples of testing methods to check out.

References