Testing testing

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

• JUnit
• Spring Testing
• mockito

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.

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.

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

• React Test Utils
• Mocha
• Chai

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

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();