DRAFT

Testing for services

For examples of how to test services, please look at the repository fineract-cn-template.

Unit tests

Unit tests are tests which cover a single class.  Unit tests are kept in the repository module, and the package name of the class they tests.  Most services have three submodules: api, service, and component test.  Unit tests should be written to cover the first two of these submodules.  Unit tests should be very fast.  A unit test which takes a second is already too long.  Unit tests should not access resources like databases or files.

...

Component tests test an api and a service together but mock any services that the service-under-test is dependent on.  Component tests are kept in the same repository with the code they test.  Component tests submit changes via the feign api, listen for changes using ActiveMQ, and check results using the feign api again.  Data for component tests is persisted to an embedded Cassandra and an embedded MariaDB.  These are spun up before the service is spun up.  Because so many things need to be started, starting a test can be rather slow.

...

Because the EventRecorder collects all events that it "sees" in memory, it is not suitable for most production uses.  It depends on the limited run times of component tests; in most other contexts its approach will be indistinguishable from a massive resource leak.  If you want to wait for a specific event in production code, consider using EventExpectation instead.

...

<TODO: work here next>

Testing for libraries

Library tests consist only of unit tests.  All other granularities of testing for the libraries are covered through their usage in the services.  Because its hard to discover bugs in a library from dependent code, this makes unit testing of libraries far more important than it is for services.  So think twice before you omit a unit test for a new library class.

Integration Tests

Integration tests are very similar to component tests except that they start multiple services instead of just one.  Integration tests are kept in a separate repository.  The only example we currently have is: fineract-cn-demo-server.  Because services need to communicate with each other, services also need the following:

• The same public key for the provisioner across all the services.
• The same public key for identity within a tenant across all the services.
• The same provisioned name of at least one tenant across all the services.
• A locally running instance of Eureka for use in service discovery.
• A locally running instance of ActiveMQ.

We have a few classes in fineract-cn-service-starter which are intended to make this easier:

• InitializedMicroservice is a test rule which starts, initializes, and stops a service.
• ActiveMQForTest is a test rule which starts and stops ActiveMQ
• EurekaForTest is a test rule which starts and stops Eureka.
• IntegrationTestEnvironment which sets the necessary ports and environment variables for the services.