-
Notifications
You must be signed in to change notification settings - Fork 1
Deliverable 2: Backend, Testing
Documentation of all our RESTful service endpoints can be found in the link below. The URL of the service endpoint, the accepted operation, the parameters as well as a description of its functionality are included.
https://documenter.getpostman.com/view/6755770/S11KQdui
This Software Quality Assurance Plan (SQAP) defines the processes, methods, and standards that will be used to ensure the correct functionality as well as the maintainability and quality of the code of the Co-Op-Erator Project. The SQAP for the project includes three main components:
- A set of testing suites. (Dynamic validation and verification)
- Code reviews performed by the team. (Static validation and verification)
- Semi-automated code formatting.
Testing the correct functionality of the project will be done through unit and integration tests implemented using the JUnit 4 framework. The tests will be divided into four layers that operate at different levels of the application, with each layer being implemented as a separate testing suite. Additionally, the EclEmma Eclipse tool will be used to generate test coverage statistics.
The first layer will test the correct functionality of the business methods using unit tests. This layer should run in isolation, i.e. these tests should run independently of any real database so that only the methods' logic is tested. For this purpose, the Mockito mocking framework will be used to stub the functionality required from the database interactions. As a minimum goal, this test suite should achieve 90% statement coverage of the service class (which contains all the business methods) according to EclEmma statistics.
The second layer of tests will test that the business methods behave correctly when interacting with a database. The main purpose of this tests is to verify that the business methods are able to create and manipulate domain model instances on the database correctly without breaking any of the constraints imposed by the JPA and the domain model itself. This testing layer will use an H2 in memory database to run the tests in order to reduce runtime and to ensure that the tests' results are independent of other simultaneous operations taking place in the database. Using an H2 in memory database is required in order to add this testing layer to the continuous integration system, otherwise builds could randomly fail. As in the previous layer, this test suite should achieve at least 90% statement coverage of the service class according to EclEmma statistics.
The next testing layer will test the correct functionality of the POST and GET REST service endpoints provided by the application. This will be a higher level testing layer with the purpose of ensuring that the REST controller is able to receive and communicate HTTP requests to the underlying business methods. For the same reasons discussed in the previous testing layer, this testing suite will be setup to use an H2 in memory database. This test suite should achieve at least 90% statement coverage of the REST controller class according to EclEmma statistics.
In addition to testing the RESTful service endpoints provided by this team, a last testing layer will be developed to test the GET REST service endpoints provided by the other teams in this development unit. The purpose of these tests will be to ensure that the application can successfully communicate with the other views developed in this unit. Unlike in the previous testing layers, this test suite will have no minimum statement coverage goal since such a statistic is unavailable.
For details about how to run these test suites see Testing Documentation.
Although automated testing can dramatically speed up development while guaranteeing base functionality, code reviews are still a valuable resource for ensuring the quality and maintainability of the codebase.
Following recent best practices and taking into account the busy schedules of the members of this team it was decided to use a modern code review approach to avoid recurrent heavyweight meetings that would slow down the development process. To facilitate the code review process, team members will be assigned as reviewers of one of the main components of this Sprint: the service class (which contains all the business methods), the REST controller class or one of the test suites. Authors of one of the components will be assigned as reviewers of one or more of the other components. The integrator role will be held by the team's CTO which has the most knowledge about the technologies used and the verifier role will be performed by the team's main testing engineer.
Given that the integrator and verifier roles will be always held by the same team members, the author and reviewer roles for the different parts of the code will be as follows:
| Code Component | Authors | Reviewers |
|---|---|---|
| Service Class (Business Methods) | Remi Carriere | Boyang Ma, Naxin Fang, Angel Ortiz |
| REST Controller Class | Angel Ortiz, Remi Carriere | Marie Vu, Naxin Fang, Boyang Ma |
| Business Methods Unit Test Suite | Angel Ortiz, Marie Vu | Naxin Fang, Remi Carriere |
| Business Methods Integration Test Suite | Angel Ortiz, Marie Vu | Naxin Fang, Boyang Ma |
| REST Services Integration Test Suite | Boyang Ma | Remi Carriere, Angel Ortiz |
The authors of each code section will notify the corresponding reviewers when significant changes are made to the code. Subsequently, the reviewers will proceed to revise the code. If the reviewers determine that any corrections or enhancements need to be considered, they will be discussed with the authors and the team's integrator. Should the integrator decide that the suggested changes are indeed needed, the authors will proceed to implement a patch to add those changes. Finally, the team's reviewer will ensure that the patch behaves as expected.
In order to ensure the readability and quality of the code, the Google Style Guide for the Java Programming Language will be used as a standard for the entire codebase of the project. To minimize the time spent on the task of formatting the code, all the members of this team will set the formatting settings of the Eclipse IDE to follow the Google Style Guide using the XML Document Format Style Guide for the Eclipse IDE provided by Google. This makes the task of formatting semi-automatic by only requiring each team member to run the Eclipse IDE formatting tool on the code before committing any changes to the project repository.
It is required that all the members of the team perform the following steps before pushing code to the repository to ensure that the formatting conventions are being respected:
- Run the Eclipse IDE clean up tool to remove unused imports.
- Run the Eclipse IDE import organizer tool to group the remaining imports which increases readability.
- Run the Eclipse IDE format tool to enforce the Google Style Guide conventions.
Optionally, a developer has the option to have the Eclipse IDE run all this tasks automatically every time that a file is saved. This can be set in Preferences > Java > Editor > Save Actions.
Additionally, when working on long classes which contain sections of code relevant to different parts of the domain model, like the service class, it is recommended to use headers to group different sections of the logic and indicate what domain model class they belong to. The headers should follow the following format:
/*------- <CLASS NAME IN UPPER CASE> METHODS -------*/
The header should have two empty lines before it and one after it to indicate that it refers to the code below until the next header is found.
This Software Quality Assurance Report discusses the results obtained for this Sprint and how they compare to the previously discussed Software Quality Assurance Plan (SQAP).
As planned in the SQAP, four test suites were developed to test the application backend in different layers. The SQAP minimum statement coverage requirement for each test suite and the results achieved as measured by the EclEmma Eclipse tool are shown in the table below.
| Test Suite | Number of Tests | Minimum Coverage | Achieved Coverage |
|---|---|---|---|
| Business Methods Unit | 38 | 90% | 97.5% |
| Business Methods Integration | 40 | 90% | 100% |
| RESTful Services Integration | 37 | 90% | 100% |
| External RESTful Services Integration | 5 | N/A | N/A |
The results above show that all the tests suites achieve higher statement coverage than that required by the SQAP, with some test suites achieving perfect statement coverage of the target classes.
For details about how to run these test suites see Testing Documentation.