Behaviour vs Implementation Testing in AEM: How, When and What to Test?
Most sessions on developer testing today talk about the tools and libraries we can use to write our unit and integration tests. The "how" question has been answered in most popular framework nowadays, as is the case in AEM. JUnit, Mockito and AEM Mocks are already quite mature testing libraries that enable us to write both unit and integration tests.
However, we developers rarely find any time to talk about our testing strategy. Important questions like: "What should we test and what not?", "What scenarios/requirements need to be covered?" or "When should we write unit vs integration test?" have not been discussed enough and proper guidelines have not been set by many companies.
In this presentation we will try to shed some light on questions like these for AEM customized solutions in general. Same as with writing your implementation code, when writing your test cases, clarity is king. We will discuss some guidelines for writing tests that actually make sense and demonstrate best practices to make your tests more cleaner, readable, understandable and thus maintainable.
Highlights:
- Test your business logic, not the framework you are using
- Only test the things you expose, your public API, nothing else
- Invest the needed time to describe what you are testing
- Create mocks for services based on their interfaces
- Separate mocked classes from test classes to make tests cleaner
- Never test or mock private methods and utilities
- Secure time for writing tests in advance, it needs to be planned
- You are in charge of the code quality and code coverage