10.7:documentation:conventions:dev:testing

Testing

Backend

On back-end, the tests are written using frameworks:

The former support for tests in TestNG has been removed to make tests writing more simple - the annotations testng vs. junit do not compete with each other. To write load tests, the product jMeter or SoapUI may be used.

Tests classification (super classes are prepared for the individual types):

  • unit test
    • descendant of AbstractUnitTest
    • uses the framework JUnit and mockito
    • serves for testing the individual functionalities (services, managers). If a functionality depends on another functionality, then this functionality is mocked through mockito.
  • integration test
    • descendant of AbstractIntegrationTest
    • uses JUnit framework
    • testing of the whole controllers (without the rest envelope)
  • workflow integration test
    • descendant of AbstractWorkflowTest
    • uses JUnit framework
    • testing of the individual workflow definitions
  • rest integration test
    • descendant of AbstractRestTest
    • uses the framework JUnit and hamcrest
    • integration test for testing the whole controllers including the rest envelope. There is only a little difference between the rest and integration test. If there is no express need to test e.g. the rest interface, an integration test is enough
  • controller integration test
    • descendant of AbstractReadWriteDtoControllerRestTest
    • test CRUD methods on controllers, which implements AbstractReadWriteDtoController.
Naming convention: When tests should cover DefaultFormService ⇒ DefaultFormServiceUnitTest for unit tests, DefaultFormServiceIntegrationTest for integration test. Make sure tested class is prefix and use test type as suffix. This provides better overview which test is related to which implementation.

Use TestHelper for data preparing in integration on rest tests.

Maven has been configured to launch all types of tests.

In case the functionality has already been exactly defined, it is possible to define the tests the functionality will comply with (input, output) already before the implementation itself - the tests can fittingly complete the entering. When the developer submits the functionality for the test / external examination, a test covering the newly developed functionality must exist - the basis is a unit test completed, depending on its type, by integration / workflow or rest test.

Frontend

On front-end, the tests are written using frameworks:

The tests are placed into the file test with the -test suffix. In case the functionality has already been exactly defined, it is possible to define the tests the functionality (component, service) should satisfy (input, output) already before the implementation itself - the tests can fittingly complete the entering. Before the developer submits the functionality for test / external examination, the following must exist:

  • unit test for each new component (e.g. Icon-test.js) or service (e.g. IdentityWorkingPositionService-test),
  • unit test for redux store (e.g. FlashMessagesActions-test)
  • [draft] for integration tests of the front-end, the libraries nock, redux-thunk will be used - the aim is to test the components which depend on the context and possibly also on the rest service.
    • personally I wouldn´t really call the rest, but I would mock the rest response using nock
    • or call rest api mocked e.g. in apiary

Testing tips

When you will create (or already have) integration test which creates (updates, delete) form definitions, configurations or other cached data and this test is transactional (~rollback after test ends), then don't forget to evict related caches ⇒ because database rollback will be done and caches needs to be evicted too.
Default role is not defined in test. Make sure you assign role (even default), if you testing some authorization policies.
Integration tests can be skipped adding parameter -DdocumentationOnly=true into maven command.
Identity in test can be created withou password - it's quicker, because no crypt for password will be called.
IdmIdentityDto owner = getHelper().createIdentity((GuardedString) null);

Mocking

If you need to mock some method of your class, but not the whole class, you can use a Spy. Be careful to use Mockito.doReturn method instead of thenReturn, otherwise the original method will still be called and that can make a mess (see Spying with Mockito). Example of mocking the method "someMethod" of a class "SomeClass" return the "mockValue": 

SomeClass partiallyMockedObject = Mockito.spy(new SomeClass());
doReturn(mockValue).when(partiallyMockedObject).someMethod();

Single test from cmd line

To run concrete test class from cmd line run this command from module with tests: 

mvn -Dtest=DefaultSchedulerManagerIntegrationTest test -DfailIfNoTests=false

If it's an integration test, it probably needs to run with the test profile: 

mvn -Dtest=DefaultSchedulerManagerIntegrationTest test -DfailIfNoTests=false -Ptest -Dspring.profiles.active=test

You can run concrete test with separator # behind class name: 

mvn -Dtest=DefaultSchedulerManagerIntegrationTest#testReferentialIntegrityAfterInitiatorDelete test -DfailIfNoTests=false

Single test from cmd line

Project testing

For all project is required made integration test for all java implementation (eq. processors, filter, service override, helpers, etd.). Frontend tests for overridden components, url isn't needed.

Backend coverage for java implementation is at least 80% of code. This percentage coverage is made by sonar.

After project implement required tests is needed create new project on jenkins.

If you want to run Sonar analysis for some other branch, you may use its tool by clicking on the Help icon (upper-right corner in sonar) → Tutorials → Analyze a new project → generate a token → Java → run the command locally in your command line.