Subscribe to my email list now at http://jauyeung.net/subscribe/

Follow me on Twitter at https://twitter.com/AuMayeung

Many more articles at https://medium.com/@hohanga

Even more articles at http://thewebdev.info/

With software as complex as it is today, we cans rely on manual testing to for every part of it. This is where unit tests come in.

One way to develop software is to write the tests first before writing the production code. This is called test-driven development or TDD.

In this article, well take a look at what test-driven development is in detail and how we write tests along with production code.

Three Laws of TDD

Therere 3 principles of TDD:

• We may not write production code until weve written some failing unit tests.
• We only write a test that fails and not makes compilation fail.
• We write production code to make the failing test pass.

This means that the test and code are written together. The result is that we write dozens of tests every day and test coverage would be comprehensive.

Keeping Tests Clean

Test code should be kept to the same quality as normal production code. This way, itll be easy to maintain the test.

Things like naming things properly, creating functions that arent too long, formatting, etc., all apply to unit tests just as much as production code. This makes tests easy to maintain so people can move on to writing production code.

It requires just as much care in terms of design and implementation as production code.

If we dont maintain our tests to the same quality as the production code, we lose flexibility in our production code since we dont have confidence in our production code without the tests. Well fear of making changes because we dont have tests to tell us that our production code isnt creating bugs.

Clean Tests

Clean tests are readable. Its the most important part of unit tests because we have to look at them and know what they are testing.

Readability includes clarity, simplicity, and density of expression. We want to say a lot with a few expressions as possible.

Each test should follow the build-operate-check pattern. This means that we should set up our mocks if needed and set any real data, then we do something with them by calling the code that were testing, then we check for the expected result.

Dual Standard

Since test code runs in a test environment only, they dont have to be as efficient as production code. However, they do have to be fast so that we dont have to wait too long to run all the tests since theyre going to be run as we develop the code.

One Assert Per Test

To make tests as granular as possible, its a good idea to have only one assert statement per test.

This makes our tests simple and we can change them more easily. Its also more clear of what were checking.

Single Concept Per Test

A single concept is a better rule for unit tests. Tests are used to check one concept so everyone knows what each test is checking. Therere no surprises or hidden code.

FIRST

FIRST is an acronym for the principles for writing tests. Each letter stands for one principle. Theyre as follows:

• F for fast tests should run fast. Slow tests are torture to run, so we won't want to run them frequently. If we dont run them frequently then well miss regressions until we catch them later. Also, well be less comfortable with code changes since we cant verify the results by running tests.
• I for independent tests shouldnt depend on each other. They shouldnt set up the conditions for the next test. This is because when one fails, then all the other fails, making diagnosis hard
• R for repeatable tests should be repeatable in any environment. It shouldnt matter if theres a network connection or not. So for these kinds of things, we should mock them. Well run into problems when tests depend on external resources that might not always be available.
• S for Self-validating tests should have boolean output, either they pass or fail. We shouldnt have to read through logs to tell if tests pass. Failure becomes subjective otherwise and they require long, manual evaluation
• T for Timely tests need to be written in a timely fashion. They should be written before the production code to make them pass. We might run into production code thats hard to test if we write tests after.

Conclusion

Test-driven development is something we should consider when writing our code. We can write tests before production code to make sure theres coverage for everything and that production code is easy to test.

Each test should run fast and are small. They should stick to testing single concepts and do it independently of other tests.

Tests should run in any environment the same way. They shouldnt rely on external resources that aren t always available.

Test results should either be pass or fail. It shouldnt be up for subjective interpretation by people.

Finally, the test code has to be as clean as production code so that we can read and maintain them easily.