...

In component tests, service security code is not skippedstill run for all calls.  Component tests also don't start the identity service and the provisioner to produce valid headers.  Instead we've provided libraries which simulate the provisioner and identity to make it possible to produce valid headers.  To do this there are several steps:

• start the service configured with a valid public key for the simulated provisioner.
• initialize the service with a valid public key for the mocked identity service.  The service will check that the request is valid by checking the header against the simulated provisioner's public key.
• include a valid user token header in all the calls to the service.  The service will check the user token header against the 

<not complete>

testing events

...

• .  The public key provided to the service in the call to initialize is used to check the signature.

To make this possible the libraries fineract-cn-test and fineract-cn-anubis contain some supporting code:

• TestEnvironment sets the public key for the simulated provisioner and keeps the corresponding private key around for future use.  It's a so-called test resource with a before and after clause which are run automatically by the framework.
• TenantApplicationSecurityEnvironmentTestRule uses the TestEnvironment to create the necessary call to initialize, and to set a user token header in the REST calls to the service.  In most cases a new user context is created for each test.

testing events

Almost all changes made to service data are executed asynchronously.  That means that in order to check that they were made correctly we need some sort of notification that the change is complete.  The services notify of change completion via ActiveMQ events.  The event ID definitions are part of the API.  This means that:

• We need to test that events are sent when asynchronous changes are complete, and
• we need to wait on events before we can check that changes are correctly made.

To support these needs, we've created an EventRecorder which can be used to note events and to wait for events.  To use it, do four things:

• enable it using the @EnableEventRecording annotation on your test configuration,
• make sure that your event objects have equals and hashcode implemented,
• create a listener for the event in question, similar to the SampleEventListener.  The listener should pass event notifications into the event listener.
• call eventRecorder.wait(<event id>, <location identifying object>) when you're expecting an event.

Once wait matches an event, it removes that event from the list of events to match.  So if you're expecting several identical events in sequence, you can safely call wait for each of them.

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.

Integration tests

<TODO: work here next>

Testing 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.