Flamingo Commerce Testing Conventions

Unit Tests

Go like the unit test are next to the unit they are testing *_test.go

Unit Test should be useful, understandable and maintainable.

• essential for domain layer and infrastructure layer
• where useful for application and interface layer

Test smells

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

Integration Tests

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. We differentiate:

• 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)

Contract Testing

Pact Test

Use consumer based contract testing with Pact for Adapters that communicate with external (rest) APIs