Ask HN: How can I convince a team member to try TDD

I prototype, then tests, then refactor and I know some people would be zealously against this style; demanding tests before everything. However my mind just doesn't work this way, I need to play with code to get ideas out of my head; coming up with relevant test cases takes a magnitude of time longer than making the prototype.

Now if your co-worker is not writing tests at all, this is a different matter, but as long as the code he writes is covered by a test suite in the end, what does it matter which order he/she does it in?

Even after this great experience, I would not say that tdd is for everyone and for all situations. I like to have some layer of test that I see red then green, and tdd helps with that. But I find tdd _only_ works when I know what the end result will be. I often don't. I know that something kinda foggy has to happen, and I'll build a first pass, then go from there. As long as a test gets done, I'm good to go.

I'm getting a big push from a fellow co-worker to try TDD. He thinks it's the best thing since sliced bread, giving examples of random articles that validate his point of view. I trust him and he is a hard-working person, but in this case I think he doesn't want to get out his comfort zone and at the end of the day, just isn't seeing the bigger picture. I don't want to overrule him, but it may get to it, because it gives a bad example to newer team members. And because for some random reason I have weight to throw around and he doesn't.

It's like I keep trying to tell him, 'Yo -- Been There, Done That... back in 2003, bro'. But still he keeps pushing and pushing and pushing.

Do you see the pre-set bias here? "I'm the one who's innovative and well-rounded and following best practices; he's the one stuck in his comfort zone, trotting out random articles to support his point of view."

Measuring? No! not code coverage, but rather as in real life...

If you drink coffee, and you like to add some sugar/milk/gold or whatevs, do you just blindly add a random amount? or do you use a spoon or a pre-"measured" packet? The later? Yeah? And why is that? Because you could ruin the coffee if you add to much or too little!

The test is the measure!!!

Try with anything else: if you doctors prescribes something, do you take the amount prescribed or do you just shake the bottle, or throw some dice to come up with the amount to ingest? (granted, people these days... rolls eyes)

So you see, if you want to guarantee that your program, function, App, etc. works correctly with certain confidence, and that parts can be changed as needed while also having some assurance that it won't "OD" your users, you have to have some measures for it!!! Or not and be sued for negligence, or enjoy some bad coffee, or whatever your analogy is!

So tell your co-worker if he lives by the same philosophy he codes, you're gonna tell his life/health insurance about it ;-)

Also, ask him how he would feel about being the passenger of someone that drives a car that's never maintained, sometimes is fueled with gasoline but some other times with diesel, and really enjoys driving blindfolded... you know, be he can "sense" stuff... HA HA HA HA HA

BUT, if you are the kind of TDD-nut that what to test abs-ol-ute-ly everything, even the variables... then, you, are, crazy! And wrong! Be mindful of the things that should be tested... you know what's really important, and what makes sense... every project is different. If you aren't mindful with your TDD, everybody will hate you and your project will suffer.

Thanks for your question!

Currently you're just proselytizing and thinking about only what you like and how you want to work.

What concrete problems are you having that you think TDD is going to make better? Are too many bugs making it to production? Are you not writing enough tests? Are your tests poor quality?

I would have a bad reaction if somebody was trying to push TDD on to a project without objectively weighing up the benefits as TDD isn't suitable everywhere.

Instead of citing random articles, you should all work together to objectively weigh up the pros and cons for your team, then perhaps give a version of TDD a trial on a suitable small project or subproject.

If you can't convince people, maybe you're not selling the specifics of how it's going to help with the issues your team is facing or you haven't considered this aspect hard enough yet.