Unit Tests

Introduction

The HappyTree API has a well-defined structure of unit tests for each method and each interface made available to the API client. In this context, JUnit is adopted for unit tests.

In the first part, the unit tests structure will be shown. Finally, this document will explain how collaborators can help us by following standards/recommendations for writing tests.

The unit tests structure

Currently, the HappyTree API provides the API client with four interfaces for handling trees. Each interface contains a set of services (methods) that help the API Client to handle trees. Those interfaces are:

• Element
• TreeManager
• TreeTransaction
• TreeSession

With this in mind, the unit tests structure is based on two types of tests:

Demo tests

They are customized tests, free of any rule. Any collaborator can perform any type of tests for the HappyTree API here. The test classes are located in: demo.

Already, there are model and util sub-packages for better organization. You can feel free to create subpackages inside demo.

API client interfaces tests

These tests are fundamental for each available service provided by their respective interfaces. So, each interface is represented by a package, and each package can contain:

• The happy scenario tests (mandatory);
• The alternative scenario tests (optional);
• The error scenario tests (optional);
• The suited test class to run all the tests from a package which represents an interface (mandatory).

Nomenclature

For each interface, it is adopted the following nomenclature, for example: [TreeManager]

[Interface Name] + [Scenario Test] + [Test Suffix] (Except for the happy scenario)

For happy scenario, the [Scenario Test] is omitted.

• Happy Scenario: TreeManagerTest
• Alternative Scenario: TreeManagerAlternativeTest
• Error Scenario: TreeManagerErrorTest
• Suited Test Class: TreeManagerSuiteTest

For methods, the name of the test method matches the interface method to which this test refers. When testing alternative or error scenarios, a short description is recommended. Example: updateElement().

Scenario	Name
Happy	updateElement()
Alternative	updateElement_nullIdElement()
Error	updateElement_duplicateId()

Main Test Class

The main test class of the HappyTree API is HappyTreeTest in the root level of the test package.

Just as HappyTree represents an entry class for the API, HappyTreeTest represents an entry test class to perform all unit tests of the HappyTree API. It seems like a Master Suited Test Class. Every new suited test class has to be added to the HappyTreeTest.

HappyTreeTest -> TreeManagerSuiteTest     -> TreeManagerTest
                                          -> TreeManagerAlternativeTest
                                          -> TreeManagerErrorTest
              -> ElementSuiteTest         -> ElementTest
                                          -> ElementAlternativeTest
              -> TreeSessionSuiteTest     -> TreeSessionTest
              -> TreeTransactionSuiteTest -> TreeTransactionTest
                                          -> TreeTransactionAlternativeTest
                                          -> TreeTransactionErrorTest

Standards

Before starting, the most important recommendation is below:

Each interface (mentioned in this section) method must have at least one test in the happy scenario.

The recommendations are:

• If your test is related to one of those API interfaces, your test must be located within the respective package related to its respective interface.
• Implement your test and place it within the class to which the type of scenario the test indicates (happy, alternative or error scenarios).
• It is highly recommended that the name of the test method matches something close to the method name of the interface to which the test refers. If, in addition, it is an error or alternative test, it would be appropriate to concatenate with "_" plus the description of the situation:
  • e.g: public void updateElement_nullArgument().
• It is highly recommended to write comments, compatible with the Javadoc convention, and define the following criteria within the comments:
  • The interface method which the test refers;
  • A quick description of the test objective;
  • A quick description of what is expected from the test;
  • The enumerated steps of what the test does.

Example

• It is not recommended to change tests already implemented.
• If your test is just a demo, it should be located in the demo package.

Questions

For any questions regarding tests, create an Issue with the question or test labels.