Unit testing code of conduct #1216
ameteiko
started this conversation in
Discussions and decisions
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
General
Small
The unit test must be as concise as possible and not contain any sophisticated logic, for it will make it bug-prone and more challenging to maintain.
Anti Example:
Fast
The unit test must not operate over any real dependency (any operate over a test double instead), making it fast to execute.
Simple
Avoid any complex logic in the tests because it will lead to the necessity of testing them, too.
Any generic logic that would shorten the test code by following a DRY perspective will inevitably fail at some point, leading to debugging this logic together with the test to find the problem.
Generic code will grow in complexity over the time making tests also subject to refactoring. It is crucial to find a good balance between simplicity and repetitiveness.
Anti example
It is better to use
assert.ElementsMatch
instead of in-place sorting.Readable
Unit tests should be easy to read and clear in their intent so that the developers can easily understand what is being tested under which conditions. To facilitate this, it’s best to structure the unit test according to the AAA pattern.
Naming
Test files
The unit test files should be named according to the Golang convention as
*_test.go
and reside next to the code under test. If the code inside a test file grows too big, it is recommended to split it into several files with prefixes that describe the clustering of the files:The name of the should reflect the system under test:
TBD
Test scenarios
There are two main conventions for naming the test scenarios:
Anti Example
Test doubles
The most used test doubles are:
TBD
Descriptive variable names
Variable names should describe the tests’ expected inputs and states to make unit tests to be more readable. Verbosity is acceptable if it improves readability.
Organisation
Easy to find
TBD:Test file organisation
TBD:Assertion
Follow the Arrange/Act/Assert (AAA) principle
Favour Precise Assertions
TBD:Test data
Make your scenario under test and test values extremely obvious
Do not use magic constants
Try to avoid predefined constants in test fixtures and using constants for test pre-configuration. Use meaningful variables instead.Test doubles
Use fakes when you depend on external systems you don’t control
TBD:Avoid complex logic inside your fakes
The test doubles must simplify the behaviour of the external dependencies and not contain any complex logic (which can become a subject for testing on its own)Don’t write assertions for stubs
Stubs should simulate the expected behaviour of an external dependency in a simple and predictable way. It should never change its state or cause any side effects.Keep one mock per test
Mocks are used for assessing the interactions of the system under test with an an external dependency. There should be just one aspect of testing in each unit test, meaning that it should utilise just one mock for a unit test.Design
Test one concept at a time in Isolation
Unit test isolation
Keep unit tests stateless
Recognise a test setup pain as a design smell
One use case per unit test
Checklist
TBD
Beta Was this translation helpful? Give feedback.
All reactions