This is the 3rd part of a series about 67 Bricks’s coding principles. The previous posts are: 1, 2 and 3.
The principle
Test at multiple levels
I don’t think it’s controversial to say that tests are A Good Thing.
Functionality should be well tested so that we can be confident that it works correctly. Tests at different levels bring different benefits and should be combined to provide a high level of confidence in the software’s quality.
A rough common rule of thumb is that there should be:
- lots of unit tests
- these focus on individual units of code
- they should be small, focused and quick to run
- slightly fewer integration tests
- these focus on testing multiple units together, potentially including external systems like databases
- they tend to be a bit slower to run and more involved to set up
- fewer again end-to-end tests
- these test the whole stack
- they generally test from the point of view of an end user or client of the system, so they might run via a headless browser or via a REST API
- they tend to be comparatively slow and complex so they should be used sparingly and where they add real value
- a small number of smoke tests
- these are very basic end-to-end tests that can be run post-deployment or at regular intervals to check that the service is healthy
There is much that sensible people can disagree on in the above, like where the line sits between unit and integration tests; how much value there is in mocking in unit tests and much more. But I think the broader point that there is value in having tests at multiple levels stands.
By writing good tests at multiple levels, and running them often, it is possible to have a high level of confidence that a piece of software is in good working order.
Well written tests can bring a huge number of benefits, some of which are perhaps less obvious than others.
Tests verify that a piece of functionality works as intended
This is perhaps the most obvious benefit of tests: they test that some code does what you think it does.
While at 67 Bricks we are fairly agnostic to TDD (you’re welcome to use it, but you don’t have to), we do advocate for interleaving writing code with writing tests, rather than writing all the code first and leaving the tests till the end. Writing tests throughout the process can be hugely helpful in writing code that does what you intend it to with minimal bugs.
Tests encourage good, clean, modular code
It is a good rule of thumb that if a unit of code is hard to test, it’s probably an indication of a problem that you should fix. If it’s hard to test, perhaps it’s too tightly coupled or it’s making some undue assumptions or it has a confusing interface or it’s relying on hard-to-reason-about side effects… Wherever the difficulty springs from, the fact that it’s hard to test is a useful warning sign.
Tests act as specifications of behaviour
Each of your tests can act as an encapsulated description of how this unit of code is intended to act in particular circumstances. This is great as a way of documenting the developers’ intentions. If I come to a method and find myself wondering what to expect if null is passed into it, then my life will be made a lot easier if there’s a corresponding test like
it('throws an error when null is passed in', () => {This example uses jest, a popular testing framework in the Javascript/Typescript world that allows you to write very spec-friendly, descriptive test names. In languages or frameworks that require you to use function names rather than strings for test names, I advocate making those function names as long and descriptive as possible, like
void throwsAnErrorWhenNullIsPassedIn()Tests act as examples of how to use units of code
Related to the above point, they also act as written examples to future developers of how to use or consume the module under test.
Tests guard against regressions and other unintended changes
One of the most valuable things about adding tests as new features develop is that they remain in the codebase indefinitely as guards against unintended behaviour changes in the future. When working on a large system – particularly when developers come and go over time – it’s invaluable to be able to get instant feedback that a change you’ve made has caused a test to fail. This is especially true if that test is descriptively named, as recommended above, because it will help you understand what to do to fix the failure. Perhaps your change has had unintended consequences, or perhaps the test simply needs updating based on your change – a well named and well written test will help you make that call.
For this reason, it can sometimes be useful to test fairly trivial things that wouldn’t be worth testing if the only benefit were checking that your code works. Sometimes it’s valuable to simply enshrine something in a test to prevent accidental changes to important behaviour.
Tests help you refactor with confidence
When refactoring, tests are indispensable. If the code is well covered by good tests, and those tests pass after you’ve finished the refactor, you can have a high degree of confidence that you haven’t inadvertently changed any behaviour.
Resources
https://martinfowler.com/articles/practical-test-pyramid.html