Unit Testing

One of the biggest trends in testing is the use of unit tests to test logical units in isolation for their correctness. However, in many cases, the time and effort it takes to create tests is the time taken away from other, more valuable efforts. Unit tests often slow down development rather than speed it up.

When to use unit tests

Unit testing is most useful in larger organizations where many programmers work on the same projects. As each programmer contributes their part to the project, the unit tests ensure that each piece still works well in the overall structure of the project with each change. If the unit test identifies a problem, the team can easily identify and correct the issue so that it minimizes or eliminates their effect on other elements, and therefore saves development time.

However, in hobbyist or small team settings, creating unit tests can actually cost more development time than it saves. This is because unit tests are only effective if they’re comprehensive and, therefore, time-expensive. If there are not many programmers working on the same project, each member will be more aware of each change and so unit tests can often just give information that the team is already aware of. In cases like these, unit tests may require more development time to make than they save in execution.

The benefits of unit testing

Let’s discuss the purported benefits of unit testing.

Provides a benchmark of progress

Test-driven development requires that we write everything twice:

• We write the test.
• We write the code.
• Then, we modify them to agree.

If we misunderstood the goal, that means we’ve now written a wrong implementation and a test that passes for that wrong implementation.

On the other hand, if we understood the goal, then we wrote the code correctly and didn’t need the test as evidence. Below, we’ve tried out our approach in a REPL to ensure that it works.