Bit of a rant, but bear with me.

People call me purist. I do not code in any way other than TDD. When I try to push TDD as a company policy, the following conversation:

company owner: "we'll do TDD when the project warrants it"
me: "if you can't do TDD on even small/simple projects, you won't suddenly know how to do it for big projects. Also if a project is small/simple. the so-called cost of unit test should be negligible".
company owner: "all the devs here know how to do TDD, they'll do it when required".

That last sentence struck me as complete B(each) S(and).

My argument is if a dev "choose to do TDD when he's told it's required". He's doing it wrong and he has no clue about unit test/TDD. Unit testing is like my left hand and my code is like my right hand. Yeah sure I can just use my right hand. It'll just do things wonky and slower.

Do I have my head too far up my @$$? I just have a hard time believing a dev who does TDD fluently would prefer not to do it. (For a whole application)

Edit- I'm not talking about whether TDD/Unit testing is/if/how/when required and its benefit. It's a dead horse. I'm talking about now that I do it day in and day out, I feel uncomfortable NOT doing it. I just want to know if it is a healthy mentality.

closed as primarily opinion-based by Eric King, Karl Bielefeldt, GlenH7, Bryan Oakley, BЈовић Jul 9 '13 at 18:47

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    Are you suggesting that TDD is the only right way to write software? Or that your company should just do software the way that you think is best because you prefer it? I'm confused on why you think your way of doing software should be forced onto the other developers. You mention that you aren't as efficient without TDD, but is anyone saying that you CAN'T do TDD on the code you write? – Ampt Jul 9 '13 at 17:36
  • 1
    What kind of applications don't require unit tests ? – Tulains Córdova Jul 9 '13 at 18:24
  • 4
    I'd like to point out that not doing TDD is different than not doing unit tests. One can certainly write an application with unit tests and not do TDD. – Eric King Jul 9 '13 at 20:06
  • 2
    I'll second @EricKing here. Are you talking about TDD or unit testing? I'm not sold on the benefits of TDD, but unit testing is way less controversial, and it would be very suspicious if your company wasn't doing it (unless it's a very specific scenario you haven't told us about) – Andres F. Jul 9 '13 at 21:12
  • 3
    This is what religion does to you. – Robert Harvey Jul 11 '13 at 0:12

No, I suspect the issue here is that the company owner doesn't really understand that one of the core points of TDD is that you have to do it from the beginning of a project or else it'll likely never happen, at least that has been my experience where whenever it is tried to be adopted mid-project it falls apart quite quickly. As a methodology, I can appreciate TDD and if a place used it, I'd probably acclimatize to it. However, I'm not sure many places can see the full value of doing things in that manner and thus it is like trying to educate the owner that falls short as he doesn't quite get it would be my interpretation here.

There is nothing wrong with preferring a style and seeking out companies that use a specific methodology, as long as you understand how limiting your pool of potential employers would be in this case.


It's not too hard to imagine projects that don't gain any benefit from test driven development.

After all, if the code will never be updated, is so simple it almost can't be written incorrectly, and has so little variation edge cases just can't happen, then writing tests won't help at all.

Of course, what's hard to imagine is a professional software development shop that does this sort of thing day in and day out, and manages to stay In business.

It shouldn't be the size of a project that determines the choice of TDD or not. It should be the complexity of the code and the possibility of re-use.

  • What does reuse have to do with TDD? – Robert Harvey Jul 11 '13 at 0:11
  • re-use of your code elsewhere means that you need to preserve that functionality when you refactor, hence unit tests, hence TDD. Code that DOESN'T get re-used may not benefit from unit tests, hence tdd lowers in utility. – DougM Jul 11 '13 at 1:32
  • +1. An example would be quick scripts written to support financial trading. You need an answer really quickly (within minutes at most), because you spot an opportunity. You are only going to run the script once. You need to be correct more often than not, but being fast is more important than being 100% accurate. – MarkJ Jul 11 '13 at 16:25

A common perception of TDD (or any practice which includes writing an extensive number of automated test code alongside the "real" code) is that it adds to the cost of a project: the time to write the unit test code and the time it takes to maintain unit test code. After all, there's more code, right? It can't come for free, can it? As such, TDD is thought of as overhead. Sure, it provides some value, but it's expensive.

To management, costs need to be justified. Not every widget requires the highest possible construction standards, and likewise not every project should need TDD, right? At some point, a project might become sensitive enough to justify TDD, and at that point it's worth the cost.

As a developer comfortable with TDD, you see that TDD done well doesn't necessarily add to the cost of the project, but may actually reduce the cost, especially in the long run. You're convinced of this, but it's a hard sell to other developers who are comfortable with their own process. It's an even harder sell to management.

Your best bet is to show (other developers, management) that the benefits of TDD outweigh the costs. That takes time. It may never happen. But you will not get anywhere trying to "push TDD as a company policy" without proving its value first.


company owner: "all the devs here know how to do TDD, they'll do it when required".

It is pretty obvious that the company owner is running out of arguments and tries end up the discussion.

But honestly, as long as the company owner is not also the lead developer, you are talking to the wrong person. TDD is something you have to convince your dev colleagues of, and if they are willing to adopt it, then the company owner most probably won't resist. If your boss is a good one, he will listen to what the whole team says, and you have just one voice among many. Accept that if you want to be a good team-worker.

Not the answer you're looking for? Browse other questions tagged or ask your own question.