Backend testing strategies | Reports

Testing strategy for the web-app back-end

Overview

The testing process for the web-app back-end and API will be integrated into the source control flow, eventually leading to a Continuous Integration approach. The goal here is to require minimal developer interaction in the process of testing pushed code and deploying it to production.

During the next stage of development for the application a strategy of test-driven development will be employed. This will reduce the time spent testing near to the release deadline, while also helping to ensure that edge cases are covered earlier on and not patched as an afterthought or with a workaround. To understand the process that will be used during development knowledge of the source control flow is required.

Source Control

For the repository there will be three key branches for active development:

master
testing
development

The master branch will only contain code that has passed all acceptance testing and that is suitable for a release candidate. Acceptance testing encompasses the unit-tests which code must be written to pass, as well as full-feature testing using headless browser automation tests and testing on the HoloLens code base. Any code merged here must pass the acceptance testing, to minimise fault in release candidates.

The testing branch will contain code which should pass the unit-tests but is awaiting a pass on the full-feature testing or awaiting code review. This is the only branch which should be merged into the master branch, aside from in cases where an emergency hotfix might be needed.

The development branch is where most active development should occur. Ideally unit tests will pass, but it is expected that they may not. This branch will be merged into testing only when all critical unit tests are passing. In ideal circumstances all unit tests should pass but that may not be the case.

Other branches for feature development may be forked from development and merged on a case by case basis, but these should only be used when necessary to avoid cluttering the repository.

Unit Testing

The core frameworks which we plan on using for writing unit tests are Arquillian[1] and JUNit[2], alongside Mockito[3] for when mocks are required (namely API tests).

Before developing a new piece of functionality a minimum specification for it should be written in the form of tests. The new code should then be written to pass this minimum specification. A specification for the functionality may evolve over time as new information becomes available or scope changes. In this instance tests should be added before introducing potentially breaking changes to the functionality. These tests should then also pass before new functionality is merged in to the codebase of the master or testing branches.

Full-feature Testing

Full-feature testing will be mainly performed in two ways, with more added as they become appropriate. It will be performed against a test deployment of the webapp with the methods as follows:

Browser Automation: Testing of the webapp through an automated headless browser will be done using Selenium WebDriver[4], acting upon the test deployment of the web app and mainly testing the front-end for the application.
HoloLens Testing: The release candidate for the HoloLens will be pointed at the test deployment and a combination of manual testing and potentially unit testing will be performed to ensure that the test deployment does not break the interface between the two. If the test deployment does contain breaking changes then it must wait for HoloLens test version to be updated to fit the new changes.

It is important to note that once the final prototype of the solution is released then no breaking changes should be made without first deprecating and then dropping support for old versions of the HoloLens application. Breaking changes to the webapp should not be pushed to deployment without syncing the release of a HoloLens application version that supports the changes at that point.

Continuous Integration