Unit testing is a way to check automatically that code works as expected. Alongside new features, one writes logic to test inputs, outputs and internal states.
Usually this reduces bugs. Moreover, unit-testing, i.e., “testing isolated units”, forces writing in small chunks with decreased coupling. One can generate coverage reports, objectively measuring code quality.
Initially, there appear to be disadvantages:
- It seems to slow development, doubling the “normal” amount of effort just for tests. However, time “lost” on testing is regained on future bug-fixing, and any developer should check their code, so why not just write unit tests?
- It can be tricky prioritising what to test, and time can be wasted on trivial tests. However, this usually owes to inexperience, and becomes less of an issue over time.
In Henesis we find, overall, unit-testing speeds up development, because we build on more stable code. There are fewer bugs, and reduced coupling eases maintenance.
We aim for high code-coverage on all production code—in some cases we still move “quick and rough” to verify something—as soon as this is checked, we unit-test. Like this, we maximise productivity and code stability.
How does your dev-team handle testing?
