Home » Software Development » TDD in an Economically Sensible Way

About Calen Legaspi

Calen Legaspi
Calen is CEO and founder of Orange & Bronze Software Labs (http://orangeandbronze.com), an outsourcing, consulting & training firm based in Manila, specializing in Agile Software Development, Spring Framework and Grails. He is an advocate and trainer of Test-Driven Development, Object-Oriented Design, and Domain-Driven Design.

TDD in an Economically Sensible Way

On TDD, we’re often at two extremes: At the start of a project, we’re as idealistic as many TDD authors would have us do – writing tests for almost everything. Then, as deadlines near, we drop TDD altogether, and then deliver a product with ticking production-issue time bombs.

The right attitude be somewhere in the middle: Apply TDD in an economically sensible way, so that you can sustain it consistently throughout the project.

Two questions are important:

  1. What is the chance this scenario will have bugs?
  2. How critical is this scenario?

#1: What is the chance this scenario will have bugs?

Obviously, we shouldn’t test things so simple as getters/setters, null-checks, is-positive-number-checks, etc. If a one-second inspection of the code in question reassures you that it works, you probably don’t need a test for it.

You can actually *increase* the amount of code that falls into this category. How? By using well-trusted third-party libraries. For example, instead of writing your own regex, check if the methods in Apache Lang 3 StringUtils will do the trick.

This is why I don’t favor minimum code-coverage standards. More tests doesn’t mean better quality. In fact, you get better quality if you increase the amount of code that is so simple that it doesn’t need tests at all.

#2: How critical is this scenario?

Let’s use university enlistment as an example.

Say, there’s a rule where the student may not enlist in two sections with the same subject. There’s a bit of complexity in implementing this rule, but not all that much. It doesn’t fall into the category of 1-second-inspection; maybe it will take around 30 seconds to read through the code to verify if it works. Looks like we should write a test for this, right?

However, how many times would a student be silly enough to enlist in two sections with the same subject? And wouldn’t the student notice if he does? And what is the consequence to the school? Not much – they end up billing the student for two sections, which can be corrected later.

On the other hand, check the scenario of cancellation of an enlistment. This is very easy to implement, it could actually fall into the 1-second-inspection category. However, the consequences of a failed cancellation process can be serious for the school – they’ll have a lot of complaints from students and parents, they’ll have to make a lot of accounting adjustments. So even if cancellation is very easy, it still merits a test.

Published on Java Code Geeks with permission by Calen Legaspi, partner at our JCG program. See the original article here: TDD in an Economically Sensible Way

Opinions expressed by Java Code Geeks contributors are their own.

(0 rating, 0 votes)
You need to be a registered member to rate this.
1 Comment Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Nick Christopher
nwillc
3 years ago

Reading this I agree with the considerations it discusses but it’s focused on the moment. There’s a long game to TDD as well. Test’s you write today continue asserting themselves all time. Something that seems obvious now might be obscure months later. Good coverage helps you confidently make changes in the future. I’m not saying 100% test coverage is the correct choice. I am saying that skipping tests today because the code seems obvious, may leave assumptions untested that might be significant in the future.