Testing

Unit tests

Integration tests

The integration tests are in review, pull request #222,

We have two integration tests. A back-end only tests and an end-to-end test which tests 3 main scenarios.

Back-end test

This test mostly tests the connection between the back-end and the Django service. We mock the Django server and verify that all the HTTP requests are made to the right resources.

We use the HTTPMock library to verify the requests:

       with HTTMock(mocker):
            ans = requests.get(self.binder._SERVER_URL + received)
            self.binder.assertEqual(len(mocker.urls_requested), 1)
            self.binder.assertEqual("/players/api/games/" in mocker.urls_requested[0], True)
       return ans.text

End-to-end tests

We test 3 scenarios:

1. Simple server start-up
2. Try to use the service with wrong credentials
3. Try to play the first level with a default created character

As most of the functionality is accessible using the API or other methods, we use simple requests rather than Selenium (though selenium should be easily be added to the module). Resources are exposed at plain paths inside aimmo-game/service. We can also use minikube with this test, but we need a different nginx configuration for this.

Most of the resources are pooled for multiple times, to give the site enough time for the resource to get deployed.

    def __pool_callback(self, callback, tries):
        while tries > 0:
            tries -= 1
            time.sleep(1)
            try:
                if callback():
                    return
                    break
            except:
                print("Waiting for resource...")
        self.assertTrue(False)

The test class has two verbosity levels, the verbose one being useful for when tests don't pass.

Setuptool

For integration test setuptool works differently than the usual automatic package discovery. The test_suite automatic discovery looks for "test_" prefix methods. The automatic test suite is also looking for the corresponding file in the actual package, thus we need a custom_test_suit method to run the tests.

For more information this link may be helpful.

def custom_test_suite():
    return unittest.TestLoader().discover('tests', pattern='test_*.py')

setup(
    [...]
    test_suite="setup.custom_test_suite",
    [...]
)

Killing services

Killing the local services can be done by killing the process tree that spawns the Django service from the top to the bottom. We need to kill the tree of processes in this order as some components might spawn other components. (e.g. game-creator or game)

Coverage