2. System test

Test the complete software

The backend system can a lot more easily create automated tests for every API, feature, service and run them automatically.

In Django projects, tests are in files starting with test in the app folder. For example, in the medical module:https://github.com/openimis/openimis-be-medical_py/tree/develop/medical there is mainly test_api.py This file in turn contains a list of methods also starting with test. They can be specified directly or within a TestCase class (the method still have to start with test)

By convention, test_services.py performs tests specific to the service interfaces of the module, testing mostly the business logic. test_api.py is more targeted at the GraphQL API. It should contain a few typical queries, a minimal, a maximal one, one without authentication at all, another with authentication but without the required rights to perform the operation, at least one test per mutation and whatever makes sense for that module. There can be additional test suites. The claim module for example includes a test_validations.py that tests every claim validation rule and combination thereof.

Examples:

def test_basic_services_query(self): response = self.query( ''' query { medicalServices { edges { node { id name } } } } ''', headers={"HTTP_AUTHORIZATION": f"JWT {self.admin_token}"}, ) self.assertEquals(response.status_code, status.HTTP_200_OK) content = json.loads(response.content) # This validates the status code and if you get errors self.assertResponseNoErrors(response) # Add some more asserts if you like self.assertGreater(len(content["data"]["medicalServices"]["edges"]), 0) self.assertIsNotNone(content["data"]["medicalServices"]["edges"][0]["node"]["id"]) self.assertIsNotNone(content["data"]["medicalServices"]["edges"][0]["node"]["name"])
def test_get_claim_category_S(self): # Given claim = create_test_claim() service1 = create_test_claimservice(claim, "S") # when category = get_claim_category(claim) # then self.assertIsNotNone(category) self.assertEquals(category, "S") # tearDown service1.delete() claim.delete()

The tests are using test_helpers methods that allow easy creation of dependencies. For example:

cls.noright_user = create_test_interactive_user(username="testMedicalNoRight", roles=[1]) cls.noright_token = get_token(cls.noright_user, DummyContext(user=cls.noright_user)) cls.test_item_hist = create_test_item(item_type="M", custom_props={ "name": "Test history API", "code": "TSTAP9"})

The methods have a custom_props is a dict of properties to override/set on top of the sensible defaults. Note that one should only set the xxx_id from foreign keys, not the objects to avoid conflicts when specifying both.

All these test suites are run automatically by GitHub actions on each push/pull request. The results of those test runs are available on each module in the Actions tab. That includes the tests for that module specifically. The openimis-be_py module does run all tests of all modules but it is not run when another module is updated, mostly when preparing a release.

Sample test run of medical items: https://github.com/openimis/openimis-be-medical_py/runs/3552714124?check_suite_focus=true

The run section reports:

 

Core

https://github.com/openimis/openimis-be-core_py/tree/develop/core

This module contains:

  • test_models.py: mostly User object methods testing

  • test_security.py: test access rights

  • test_services.py: test core services, mostly user management

  • test_api.py: not yet implemented, should contain the GraphQL API tests, especially regarding security

Test runs are in

Medical items & services

This module doesn’t have actual business logic, so only API tests are performed:

 

Did you encounter a problem or do you have a suggestion?

Please contact our Service Desk



This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. https://creativecommons.org/licenses/by-sa/4.0/