Code Standards
We generally follow the Google Java Style Guide.
The entire build is driven from a Maven file, itself run from a single Dockerfile.
Refer to Source Layout.
- Code coverage >= 80%
- Writing methods which provide a response to be better testable (avoid void if feasible).
Unit Testing Objectives: (TUT technical unit tests)
- Isolating code section, if possible
- Verify the correctness and the proper functioning of the code
- Test every function, method and procedure
- Find bugs early on
- Fix bugs directly in development mode and not afterward to save costs
- The code base is understandable to any developer
- Changes could be made quickly without any fear of breaking something
- Focus on reusability of code wherever possible
Functional Testing Objectives (FUT unit tests)
- Testing the functionality for each requirement and acceptance criteria
- Confidence for fulfilling acceptance criteria
- Improve the level of quality.
- Preventing defects
- Combine multiple units together and test them together, not isolated.
- Ensurement and confidence towards feature meets the business requirements and objectives.
We generally follow the principles of Clean Code written by Robert C. Martin. We try to incorporate the following grades of Clean Code Development in our work.
Rules on code structuring apply to test code as well, though certain linting rules can be relaxed. Copy-pasting is bad in test code as well; instead, refactor tests with utility methods and classes as needed.
We generally use an AAA test structure, and make that structure clear using comments.
// Arrange
myCar = ...;
loadVehicleInDatabase(myCar);
// Act
String vehicle = api.getVehicle(myCar);
// Assert
assertThat(vehicle).usingRecursiveComparison().isEqualTo(myCar);
When suitable, though, we condense Act and Assert into fluent statements.
We use fluent testing assertions (rather than static matchers) for a more fluent style and better IDE integration. We use AssertJ and its extension JsonUnit.
// Good
assertThat(string).contains("Hello"); // AssertJ
assertThatJson("{\"a\":1, \"b\":2}").isEqualTo("{b:2, a:1}"); // JsonUnit with AssertJ integration
// Bad
assertThat(string, contains("Hello")); // Hamcrest - discouraged
We use JavaFaker for generating sample values for testing. This is preferred to hard-coding values in tests that make tests less readable and robust.
// Good
Faker faker = new Faker();
String name = faker.name().fullName(); // Miss Samanta Schmidt
String vin = faker.vehicle().vin();
// Bad
String vin = "YS3DD78N4X7055320"; // "Magic value" - discouraged
For integration and smoke testing, we use REST Assured for robust client code generation and fluent assertions, and are categorized using JUnit5 Tags:
- IntegrationTests
- SmokeTests
The maven surefire plugin is configured to run only tests tagged as "IntegrationTests" as default. SmokeTests can be run either manually from the IDE or by overriding the "groups" configuration:
mvn -Dgroups=SmokeTests test
Consistent style increases readability and maintainability of the code base. Hence, we use analyzers to enforce consistency and style rules. We enforce the code style and rules in the CI to avoid merging code that does not comply with standards.
| Tool | Scope | Rule | Configuration (via files/annotation) |
|---|---|---|---|
| Tidy | nforce Maven POM Code Convention | Fail build on untidy pom.xml | N/A |
| SpotBugs | Static analysis to look for bugs in Java code. Successor of popular FindBugs tool | Fail build on violations | ci/spotbugs-excludes.xml @SuppressFBWarnings(...) |
| FindSecBugs | SpotBugs plugin adding security bugs coverage | Fail build on violations | N/A |
| Checkstyle | Enforce coding standard | Fail build on violations | ci/checkstyle-suppressions.xml Code style based on Azure Java SDK. @SuppressWarnings("checkstyle:XXX") |
| PMD | Source code analyzer to finds common programming flaws | Fail build on violations | ci/pmd-rules.xml @SuppressWarnings("PMD.XXX") |
| JaCoCo | Test coverage | Fail build on coverage < 80% | pom.xml @ExcludeFromCodeCoverageGeneratedReport |
