Flamingo Commerce Testing Conventions¶
Go like the unit test are next to the unit they are testing
Unit Test should be useful, understandable and maintainable.
- essential for domain layer and infrastructure layer
- where useful for application and interface layer
- Mocking the hell: If you see that most of your testcode is mocking dependencies there is something wrong with the test approach or the design
- Table testing complex logic is often not useful - instead create small individual subtests.
This repository contains a folder
test/integrationtest with integrationtests. Integration tests boot up a Flamingo application (or parts of it) and let you run blackbox tests.
module tests: Where modules are tested standalone: This makes sure that each module:
- has its dependencies defined well (and don't have too much dependencies)
- is runnable by default (making sure the FakeAdapters work)
- This kind of test are essential useful to test controller logic (they are often easier to read and provide more value than mocked controller unit tests)
project test: Boots up a complete commerce application - making sure that the integration between the modules work.
All this test still do not depend on any external system (because they are supposed to use the FakeAdapters)
Use consumer based contract testing with Pact for Adapters that communicate with external (rest) APIs