TDD extremists

The other day I came across a particularly abusive post about TDD. Here’s a quote:

If you don’t use TDD in your project you are either lazy or you simply don’t know how TDD works. Excuses about lack of time don’t apply here.

I’ve been seeing this type of attitude for a while now but this one had some code attached so I decided to rant about it. First of all tests have costs, maybe the trade-off is worth it but it’s important to actually acknowledge that it’s happening in the first place.

1) Spending your limited time structuring your workflow around tests could be better spent around architecture and design of the overall code base.
2) In a poorly architected code base test give a false sense of security.
3) Most interesting use cases that you actually want to test are not amenable to testing.
4) Tests mean you have extra code that you need to maintain.
5) Writing tests manually is not particularly efficient.

The purpose of good design is to decrease the surface area of possible mistakes by construction of the architecture. What does this mean in practice?

Here’s the original class from the post:

1 & 2 & 3) Architecture/Design

There’s quite a few things here right away that I think could be improved. First this class is mutable. Someone coming from a functional language or having read “Effective Java” or “Java Concurrency in Practice” will pick up on this right away. Immutability is often a design choice. Do you want to write tests that try to verify the behavior of this class in a concurrent environment? Do you really want to accept a double precision float for money? An arguably better approach is to structure this class so that these problems don’t occur in the first place. Here’s a rewritten version:

Is immutability harder in a language like Java than Clojure or Scala or Kotlin? Yes, but it sure saves a lot of work in the amount tests you have to write. I don’t have to worry about this class not doing the right thing with money because of weird rounding issues/floats. If you want to learn about floating point arithmetic go for it. I prefer to use Joda Money or in this case for the sake of an example I am using BigRational. You don’t have to worry about someone else extending this class and breaking encapsulation. No need to test if synchronization is done correctly. All of these things are extremely hard to unit test to the point where almost nobody does it. However if you think about the architecture of your code before writing tests perhaps you can avoid writing these tests in the first place. I’d argue the easiest things to test are quite simple and don’t end up saving much time. The real hard bugs are in the later category and it’s best to get rid of them via good architecture that doesn’t allow them to exist vs dozens of unit tests that will try to achieve the same thing.

4) Unit tests are things you have to maintain. I think most people with large code bases have experienced this. I have a 2 line change in the code that causes 20 tests to be changed. It becomes very difficult to change the architecture in a large codebase because of all the tests but the tests don’t necessarily improve or imply good architecture and design. It could be argued that tests failing when code is changed is a good thing but it’s worth acknowledging the costs associated with that kind of a workflow. In the above example I hope it’s clear that even in a simple “POJO” class where there isn’t much going on design is important.

5) It’s difficult to test interactions via unit tests, even in simple cases. Wouldn’t it be better to have your code come up with hundreds or even thousands of tests for you? With the invention of quickcheck and the porting of it to most mainstream languages it’s now possible. This can drastically decrease the amount of unit tests you have to write in the first place and I find it more convenient to write those type of tests after the code is designed and written rather than writing tests first before I have a design.

The worst part for me is that the author is probably aware of all of this since he writes Scala. The above is nothing more than a verbose version of a Scala’s case class or Kotlin’s data class.

2 thoughts on “TDD extremists

  1. Hey, Dan =)

    Thanks for the deep analysis of the TDD part 1 =)
    I agree with many thoughts in your post.

    E.g. number of tests shouldn’t be HUGE. But it’s a common situation, when you need to add some extra logic even in an object creation (amount > 0). Such places suit well good for mistakes.

    Also I agree with BigRational or JodaMoney usage.

    I didn’t use immutable design in order to simplify a code.

    Thanks =)

  2. Well Dan, I do not agree with your post.
    The problem is that TDD is an “instrument” you can use to “design your code”.
    The problem I have seen is that it seems there are always reasons to not use it and I think sometimes people who lived these situations decided to become “extremists”.
    Another problem I have seen is that, without it, it is very difficult to know if your design matches what you really need (YAGNI?) or if it is gone towards an overdesign.
    Sometimes I’m an extremist, sometimes not :) Usually, the reason I am an extremist is that I lived projects where the team achieved wonderful results, using TDD from the beginning (I mean really the first line of code) and I hate when I see “issues” that could be avoided/fixed/handled just using that approach.
    I suggest to follow people like Ron Jeffries that sometimes in the yahoo group of extreme-programming explains in a clear manner that you are free to decide when to use TDD and when to avoid it. It’s up to you.
    Probably the reason you wrote this post is that in your company, you are not free to decide it.
    Thanks Bye

Leave a Reply