Cognitivity Automated Testing
Like every other large system, Cognitivity is also a testable environment, and is tested fully using automated tools to increase the certainty that the logic is correct, and the implementation is full.
As stated in previous sections, The backend of our system is written in Java, which provides very simple tools for testing, as we will soon reveal.
The components being tested automatically:
- The Controllers.
- The Data Transfer Objects.
- The Logic of the Services.
- The Database Access Object.
- Integration tests of all of the above.
The controller units are the first layer component of the service the backend provides its clients.
Because of that, there are two things we want to test:
- The first layer it receiving the data passed to it correctly, using the correct HTTP messages.
- The first layer delegates the controller calls to calls to service classes methods, handling the rest of the logic.
These two were achieved using MVCMocks (for the first part), emulating an HTTP request being received by the spring boot framework and passed on to out controller classes.
Also, by using the mocking framework Mockito, we verified the second requirement, by mocking the second (service) layer of the application.
This layer is called by the controller layer. We wanted to make sure that the logic of the services that was offered is doing its job right. Since this is the business logic, this is imperative, and it holds most of the code for that.
In a similar way to the first layer, this second layer was tested by mocking the third and bottom layer of the data access objects, and making sure the results of the service methods were as expected.
These objects are the third and final layer of the application's logic. They represent the ORM mapping between the database's tables (represented in software by the Data Entities and Data Transfer Objects) and Java objects.
It is extremely important to test these classes since we want to make absolutely sure that the SQL and Database access queries are executed correctly, and provide exactly what we want them to.
And so, in order to test these classes, no mocks took part, and the data access was managed between the program and a local live mysql database (either by using the actual software or by using a wrapper docker client). Guide for using docker for the testing: here.
These objects, along with entity object represent the structure of the data in the database, and the data that is being transfered to the fronend client (website).
The tests for these classes are very shallow, but they test that the simple logic and structure is defined as it should be.
Integration testing is extremely important because tests of this type assert that the entire backend system works from top to bottom, without any mocks.
As stated before, the layers for the backend are: Controller->Service->DAO->Database.
And so, a common, generic test of this type would be:
- Create or mock an HTTP (GET/POST) request for the application.
- This request will go through the layers and have an effect on the data in the database, or the log file, and so on.
- The test will then use more requests to make sure that the data in the database was updated according to the last request.
- Clean the environment and the database for the next tests.
For example: an actual test method from an integration test class.
In order to run the automated tests, we again recommend using IntelliJ for that, since running JUnit unit tests is a very simple and intuitive, maven integrated process, as described here.
Some of the automated tests are unit tests, as stated, and some have dependencies (DAO tests and integration tests) - the live MySQL database.
Its not possible to fulfill these dependencies when building and testing the project in the CI platform, and its not wise. So, the tests with dependencies are to be ignored when uploading them GitHub (and subsequently to Travis CI).
Tests are defined as 'ignored' by annotating them in the code (the entire test class or each individual test method) with the @Ignore annotation.
All other tests are okay to run since they dont have dependencies.
And still, the DAO and integration tests are okay for running locally, with a database live.
So, in order to run these tests, just create a database locally, as explained here and run these tests as you would the other tests with no dependencies.
Maven is a build tool for Java and is used to build the Cognitivity Application.
Maven also offers a way to test our project in a convenient fashion from within intelliJ or from the command line. Since the CI platform builds and tests the project with a specific Code Coverage tool called Cobertura, it is highly recommended to test the project by using the following maven command:
mvn clean cobertura:cobertura
The command output is as follows: