Understanding TDD in the Wider Testing Landscape

Besides the mechanics of test-driven development, this book has touched on a few ideas about the mindset of the TDD practitioner: how and when to “cheat,” systematic refactoring, strict TDD, and so on.

Some dev teams like to adopt the mantra of move fast and break things. TDD is the opposite: go slow and think about things. To understand what this means in practice, we can compare TDD with various other popular testing techniques.

The following topics will be covered in this chapter:

• Test-driven development as a testing technique
• Manual testing
• Automated testing
• Not testing at all

By the end of this chapter, you should have a good idea of why and how we practice TDD compared to other programming practices.

Test-driven development as a testing technique

TDD practitioners sometimes like to say that TDD is not about testing; rather, it’s about design, behavior, or specification, and the automated tests we have at the end are simply a bonus.

Yes, TDD is about design, but TDD is certainly about testing, too. TDD practitioners care that their software has a high level of quality, and this is the same thing that testers care about.

Sometimes, people question the naming of TDD because they feel that the notion of a “test” confuses the actual process. The reason for this is that developers misunderstand what it means to build a “test.” A typical unit testing tool offers you practically no guidance on how to write good tests. And it turns out that reframing tests as specifications and examples is a good way to introduce testing to developers.

All automated tests are hard to write. Sometimes, we forget to write important tests, or we build brittle tests...

Manual testing

Manual testing, as you may have guessed, means starting your application and actually using it.

Since your software is your creative work, naturally, you are interested to find out how it performs. You should certainly take the time to do this but think of it as downtime and a chance to relax, rather than a formal part of your development process.

The downside to using your software as opposed to developing your software is that using it takes up a lot of time. It sounds silly but pointing, clicking, and typing all take up valuable time. Plus, it takes time to get test environments set up and primed with the relevant test data.

For this reason, it’s important to avoid manual testing where possible. There are, however, times when it’s necessary, as we’ll discover in this section.

There is always a temptation to manually test the software after each feature is complete, just to verify that it works. If you find yourself doing this a lot...

Automated testing

TDD is a form of automated testing. This section lists some other popular types of automated testing and how they compare to TDD.

Integration tests

These tests check how two or more independent processes interact. Those processes could either be on the same machine or distributed across a network. However, your system should exercise the same communication mechanisms as it would in production, so if it makes HTTP calls out to a web service, then it should do so in your integration tests, regardless of where the web service is running.

Integration tests should be written in the same unit test framework that you use for unit tests, and all of the same rules about writing good unit tests apply to integration tests.

The trickiest part of integration testing is the orchestration code, which involves starting and stopping processes, and waiting for processes to complete their work. Doing that reliably can be difficult.

If you’re choosing to mock objects...

Not testing at all

There is a belief that TDD doesn’t apply to some scenarios in which it does – for example, if your code is throwaway or if it’s presumed to never need modification once it’s deployed. Believing this is almost ensuring the opposite is true. Code, particularly code without tests, has a habit of living on beyond its intended lifespan.

Fear of deleting code

In addition to reducing the fear of changing code, tests also reduce the fear of removing code. Without tests, you’ll read some code and think “maybe something uses this code for some purpose I don’t quite remember.” With tests in place, this won’t be a concern. You’ll read the test, see that the test no longer applies due to a changed requirement, and then delete the test and its corresponding production code.

However, there are several scenarios in which not writing tests is acceptable. The two most important ones are as follows.

When...

Summary

Becoming a great practitioner of TDD takes great effort. It requires practice, experience, determination, and discipline.

Many people have tried TDD and failed. Some of them will conclude that TDD is broken. But I don’t believe it’s broken. It just takes effort and patience to get right.

But what is getting it right, anyway?

All software development techniques are subjective. Everything in this book is subjective; it is not the right way. It is a collection of techniques that I like to use, and that I have found success with. Other people have found success with other techniques.

The exciting part of TDD is not the black-and-white, strict form of the process; it is the grays in which we can define (and refine) a development process that works for us and our colleagues. The TDD cycle gives us just enough structure that we can find joy in fleshing it out with our rules and our own dogma.

I hope you have found this book valuable and enjoyable. There...

Further reading

To learn more about the topics that were covered in this chapter, take a look at the following resources:

• Useful Kata resources:

http://codingdojo.org/kata/

http://codekata.com

http://kata-log.rocks

https://github.com/sandromancuso/Bank-kata

http://www.natpryce.com/articles/000807.html

• Global Day of Coderetreat: https://www.coderetreat.org
• Getting Started with Debugging JavaScript in Chrome DevTools: https://developers.google.com/web/tools/chrome-devtools/javascript/
• Property-based testing for JavaScript: https://github.com/leebyron/testcheck-js