Unit Testing · UT-01

These basic rules should be followed:

• Unit tests should cover core business logic and validation, including edge cases
• Unit tests generally are not needed for simple CRUD functionality
• Communication is needed with test engineers to ensure effort is not duplicated among different kinds of automated test
• Unit testing is not a substitute for manual developer testing

All unit test methods should follow the same naming convention. Each project can have it’s own conventions so long as it’s adequately documented.

Writing unit tests as documentation helps to ensure that when the project is handed over to support, or when different teams are delivering new phases of work, there is clear, reliable, and up-to-date documentation of the code’s intended functionality. This facilitates smoother transitions and reduces onboarding time for new team members.

In other words, don’t have a test method name that says one thing, and then assert on something else within the method.

Each test must be independent of other tests, i.e. a test should not rely on any other test already having run.

There should be a step in any pipeline that builds the software to also run unit tests.

For example:

• Randomly generated data
• DateTime.Now/DateTime..Today

EXCEPTION Random data can be used if it does not impact the outcome of the test, e.g. a mandatory property that is not needed by the behaviour under test.

For example, you should generally not mock other classes within your codebase, but should mock things like external APIs, message queues, and email clients.

Generally speaking, when business logic code is changed, unit tests that test that logic should fail. Re-using domain logic in a test can mean that happen, and therefore should be avoided.

Using realistic data in unit tests can help to document the behaviour under test and ensures that the tests are as close as possible to real-world usage.

NOTE The Audacia.Seed library can be used to help the structured, reusable generation of test data.