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

Maybe TDD just isn't for him/her/other?

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?

I didn't "get" tdd (even after what I thought was a fair shake) until I paired with a person who was well versed in it. Suddenly, it clicked. It even happened in a code base that I said you can't do tdd 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.

TDD can be counter-intuitive for a lot of people, but I think that the most important thing that anyone should be aware about TDD, and you as a Manager/Lead/Overlord should use as your battle cry is that "TDD is all about measuring".

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!

Try evaluating pros and cons for TDD on your current project and make a decision together based on them.

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

> The part I strongly believe is that before writing a piece of code I need to know what I am writing. Similar to a task/story, I need to have an acceptance criteria. Knowing to write a test means knowing what are you writing.

Is there an existing problem in the team where people don't know what they're writing though?