...
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:
| Code Block | ||
|---|---|---|
| ||
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"]) |
| Code Block | ||
|---|---|---|
| ||
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:
| Code Block | ||
|---|---|---|
| ||
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.
...
| Code Block |
|---|
.............. ---------------------------------------------------------------------- Ran 14 tests in 3.586s |
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 https://github.com/openimis/openimis-be-core_py/actions
| Code Block |
|---|
..........................................................................................
System check identified no issues (0 silenced).
----------------------------------------------------------------------
Ran 90 tests in 0.571s |
Medical items & services
This module doesn’t have actual business logic, so only API tests are performed:
...