NEW TESTING GUIDELINES

New Testing Guidelines

Any guidelines shown here may be subject to change.

Purpose

This page's main goal is to streamline the testing process and make it easier for developers to follow a similar structure of tests.

Unit testing

Vision

Depending on the project, the way unit tests are conducted could be different. As such, this section will depict in more detail a high level overview of what our unit tests consist of.

1. Behaviour As long as TDD is not enforced (ie determining the test criteria and making the test before the method), we should try to confirm the proper behaviour of the method tested. P.S. if we do go for TDD, we should modify this guideline accordingly This can generally be done with mocks, or other techniques.

P.S. if we do go for TDD, we should modify this guideline in consequence.

2. Singularity When testing a method, any external factors should be minimized (ie external methods should be mocked). This has the benefit of also monitoring the behaviour of the tested function as external factors are mocked.

3. Simplicity I'll try to keep this one simple:

keep it simple if you can!

More details

general structure

Mock objects and regular objects should be instantiated/initialized first.

(If you need to mock an object getting instantiated in the tested function, you can use mockConstruction.)

followed by mocking behaviour (ie doAnswer.when or when.thenReturn etc...)

For mocking behaviour, you should try to inject objects that you'll be able to track, (for example if you are verifying that an external method gets called with a specific object as argument)

Sometimes, it may be tempting to over-verify some parts of the methods, for example, testing sections that are not directly part of the method, but are part of the method calling our tested method (I know, its a lot of methodception)

Remember, if your test feels like it's getting complicated, it may be an indication that your method needs to be simplified/delegated.

Exceptions

EventMappers should have their own tests, and they should be mocked when indirectly used in other unit tests. Ambiguity: Controller methods should not be tested unless the method does more than just calling the service function.

Integration tests