Usual arguments for not doing TDD are:

1. We have no time
2. Brittle tests
3. Too much work
4. No “real” benefits
5. Bad experiences with too much imposed testing (after manager single day agile training)
6. “We get payed for features, not tests”

Those are all valid arguments.

I have no problem with that. If you’ve tried it and it is not working for you, that’s great.

Some people try testing and are not quite sure what to think about it.

My heart goes to those people that linger between ‘doing it’ and ‘not doing it’.

I’ve realized, in hindsight, that I have two simple rules that help me yield much better results in ROI sort of way. Who knows, they might help tip over some more people.

First to clarify what I mean by borderline.

Borderline cases

People that use TDD, but are insecure about benefits.

They generally:

1. Write tests after writing code
2. Worry about time spent on writing tests
3. Worry about not being able to quantize benefits(to self or manager)

Rule #1 - Test as Little as Possible

My first rule is to test as little as possible.

The more you know about domain the less useful tests are.

If you have no clue about what you are trying to achieve test-first approach can get you a long way.

Rich Hickey once said:

Tests are like guard rails, and you don’t steer your car by bouncing it off the guard rails until you find the destination.

I got a bit offended, but he is right. If you know your destination, tests are of little benefit. But my TDD is NOT driving by bouncing off the guard rails.

It is more like: “I am going south where I’ve never been before, let see what is behind that mountain”.

No matter how smart you are if you don’t know the map, you’ll have to go over there and check the terrain. (That is unless you posses psychic abilities).

Unknown domain is like uncharted map. The less you speculate about it, the better off you are.

So, if you know what you are doing and you’ve done something similar before, then you are not profiting as much from testing.

Rule #2 - Almost No Integration Testing

My second rule is not do to integration testing. A lot of people do integration testing because they think it’s the RIGHT thing to do, so they suck it up. When they get tired of sucking it up, they skip it and than feel guilty about it. Some abandon testing altogether.

So there I’ve said it: I am not doing integration testing and I am proud of it!

You probably need some basic integrations tests if you don’t have Q&A department but since it is mathematically impossible to test all possible paths, trust me… it’s a scam.

It would be a shame to eliminate testing just because you wrote one too many useless/brittle test (kind that integration tests tend to end up like).

Conclusion

There are no silver bullets. Adhere to the Pareto principle and try to achieve 80% benefit from doing the right 20% of work.

Try test-first approach on some hard domain problem that you have.

I assure that after you taste sweet elixir of being able to “grow” better solution in less time you’ll never have second thoughts about testing.

It will be just another tool in your arsenal.