The purpose of testing
When starting to learn about test-driven development, many developers struggle with the question: "Why are we doing this?" This is also reflected in the tests they write. They write tests to verify the framework they're using, or for simple trivial code. They also write brittle tests or tests that are testing too much. They have not reflected on why they're testing and often only do it because they've been told to, the worst kind of motivation.
The value of testing is shown in the following image:
The original illustration comes from a talk by Martin Fowler on refactoring. The title is Why refactor? and the same applies to testing. The value of testing comes not from quality, clean code, professionalism, or that it is the right thing. The value is economics. You write tests in order to save money. Bad programming will lead to bugs in your software, which can have the following consequences:
- Projects running over time: This is because the team spends time on fixing bugs instead of writing new features. Bugs become a bottleneck for productivity.
- Corruption of data: The cost of retrieving lost data or a bad reputation for losing customer data will have substantial economic consequences.
- System looking unpolished: Your software will behave irrationally and the users will stop trusting your product. They will take their business elsewhere, to a competitor that doesn't let bad quality shine through.
We need to avoid bugs in order to avoid unnecessary and hard-to-predict costs. By adding testing to our process, we create predictability and reduce the risk to software development projects.
Note
ObamaCare, officially named The Patient Protection and Affordable Care Act, is a law signed on March 23, 2010, in the United States. It was aimed at reforming the American healthcare system by providing more Americans with access to affordable health insurance.
The US government issued a website where people could apply and enroll for private health insurance through ObamaCare. However, the launch of the website was a dead fish in the water.
Not only was the site unable to handle the substantial load of visitors while going live, but it was also having to solve performance problems for several months. The site sent personal information over unencrypted communication, and the e-mail verification system was easily bypassed without any access to a given e-mail account.
An estimation of 20 million Americans experienced the broken ObamaCare site, seriously hurting the reputation of software developers worldwide. By writing tests for our code, we will achieve higher quality, cleaner code, and maintain a higher level of professionalism, but what it eventually boils down to is that the code we write will have greater value. Tested code will:
- Have fewer bugs: Bugs are expensive to fix. The code will be cheaper in the long run.
- Be better specified: This leads to fewer changes over time. The code will be cheaper in the long run.
- Be better designed: Bad code can't be tested. The tested code will be easier to read and less expensive to change.
All of these points of interest lead to predictability, a precious thing in software development.
When not to test
As a part of software development mentoring teams, I tell developers to test everything because they always seem to find some excuse for not writing tests.
Always write tests for your code, except if the following applies; if it does, then it makes no sense to test it:
- The code will never go into production
- The code is not valuable enough to spend tests on
- The code is not mission-critical
The most common excuse developers have for not writing tests is that they claim it is too hard. This holds true until they've learned how to, and they will not learn unless they try.
