AGA Automated Testing Process¶
The AGA projects has set up several different types of automated testing in order to ensure a high quality standard is kept throughout each new release.
All tests both unit, coverage and acceptance tests run in a cascading fashion whenever anyone commits to the projects. Thanks to the cascading testing and snapshot distributions the AGA SNAPSHOT binaries can quickly be built, distributed and used to test higher level projects.
As an example:
If a user pushes a change to the SDP project it will trigger testing on the server. If it passes it builds the binaries and distributes them to the repo and queues all project that uses those binaries for testing.
Thanks to the gradle build scripts on each project the newest binaries will always be downloaded before testing occurs.
Each patch that is contributed to the AGA project should, unless it is impracticable to do so, be tested with either unit testing and(or) acceptance testing. Well tested code has a larger chance of being accepted when sending in a patch. More info regarding making a patch and contributing here Make a Patch Process.
In the bottom of our testing line we have the extensive unit tests that makes sure that our base functionalities does not fail. As time goes on we will be able to add more complicated unit tests that will increase the quality of AGA.
To help ensure that user scenarios are accomplished. Several projects uses so called "behavior driven development" type of acceptance tests. This technique is based upon the test driven development technique and helps to laser focus our effort into very precise functionality that the end-user wants at lower cost and higher quality. The resulting tests are easy for everyone to read without requiring knowledge about the code itself.
The final tool that is used is the coverage test. This test controls how much of the code that is covered by existing unit and acceptance tests. While this does not help discover any bugs it can help the AGA Contributors to see what parts of the code that is lacking testing coverage. A lack of coverage does not imply bugs nor does full coverage imply bug free code, coverage testing is to help guide testing effort so that as much code as possible is of higher quality.