Skip to content

Unit Tests

it is a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed.

The Three Laws of TDD

TDD asks us to write unit tests first.

First Law You may not write production code until you have written a failing unit test.

Second Law You may not write more of a unit test than is sufficient to fail, and not compiling is failing.

Third Law You may not write more production code than is sufficient to pass the currently failing test.

The tests and the production code are written together, with the tests just a few seconds ahead of the production code.

Keeping Tests Clean

Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code.

Tests Enable the -ilities

It is unit tests that keep our code flexible, maintainable, and reusable. The reason is simple.

Clean Tests

Three things. Readability, readability, and readability. Readability is perhaps even more important in unit tests than it is in production code.

The same thing that makes all code readable: clarity, simplicity, and density of expression. In a test you want to say a lot with as few expressions as possible.

So keep our Test as clear.

Domain-Specific Testing Language

Rather than using of API’s that programmers use to manipulate the system, we build up a set of functions and utilities that make use of those API’s and that make the tests more convenient to write and easier to read.

These functions and utilities become a specialized API used by the tests. They are a testing language that programmers use to help themselves to write their tests and to help those who must read those tests later on.

A Dual Standard

Production code and testing code runs in two different environments.

Test code must still be simple, succinct, and expressive, but it need not be as efficient as production code.

One Assert per Test

write one assert per test only.

Single Concept per Test

F.I.R.S.T.

Fast

Tests should be fast. They should run quickly.

Independent

Tests should not depend on each other.

Repeatable

Tests should be repeatable in any environment.

Self-Validating

The tests should have a boolean output. Either they pass or fail.

Timely

The tests need to be written in a timely fashion. Unit tests should be written just before the production code that makes them pass.