Ask HN: How can I convince a team member to try TDD | Hacker News Reader

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

5 pointsrooam-dev18 comments

Hello,

I hope someone could share their experience with a similar situation.

Basically, I get a strong push back from a fellow co-worker to try TDD. He thinks it's a waste of time, 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. I don't want to overrule him, but it may get to it, because it gives a bad example to newer team members.

So far my best argument is: "Don't do it for you, do it for the team".

What do you think g(uy|irl)s?

Thank you in advance.

PS: Not sure if it matters, but we use groovy + spring.

View on HN

Consider how things might look from the other side:

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."

Haha, good one. My goal is just to try it before saying no.

> So far my best argument is: "Don't do it for you, do it for the team".

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.

My main goal is to improve our development process. I understand everyone is different and has their own ways, but if somebody doesn't use a tool at its full potential then in the end company/team loses, because instead of improving things, people fight/use less efficient process.

In this case I think TDD or a version of TDD acceptable to the team can really speed up development. I want that feeling if I run all the tests I can deploy.

All devs are remote devs with different timezones.

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?

The goal is to try it as a team. Having 2 devs on a project with different approaches won't be efficient.

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.

Thanks for your input.

> 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?

I think at a high level only. Try and see how it goes (write some code, execute it and see the results) could be improved.

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!

Thank you for your answer, I will try to come up with some analogy as well (so that I don't use yours).

No, I am not TDD nut, which is the opposite of the TDD, from what I understand "write enough code" for the test to pass.

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.

Thank you.

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.

Thanks, it makes sense. I personally try to apply some of it (TDD) at a smaller scale (e.g. 1 service class) and I see the benefits. I tend to over engineer so following some rules would help me, but others may write tests after whole day of work as a separate effort which I would like to improve.

For Further Information: What is the existing testing strategy (if any)? Do you have QA testing? Etc.

We have a good coverage, but we don't have that feeling that after running all tests we can release. Currently each dev decides how much tests to write, but usually after the fact to make sure whatever he wrote behaves as expected, at that time.

The problem arises when some changes are made and random tests are failing and it becomes more difficult to fix.

No, when some changes are made, very specific tests start failing, and that conveys some information. (It can take some work to sort out what the information means, though...)

How does it become more difficult to fix? Because you have to fix the tests, too? Don't just fix them. Use them as a guide to where to think a bit more. "This change broke that test. Is that telling me that the change broke the assumptions of that code, and that therefore the change is wrong? Or is it just that the test itself didn't expect this?" You should know which it is before you fix a test.

I think the situation you're describing here is not TDD-vs-after-the-fact-testwriting. It's incomplete-vs-close-to-complete test coverage.

Could be. You could have close to complete coverage, but slow integration tests. Not a big problem, CI can run those all the time. The problem is the feedback cycle. The slower the tests, the slower the feedback is. So, with each change I have to wait for integration test to run. There is a difference between 2 seconds and 20... it's ok intially but later feels like restarting the server just see if my changes work.

I think and hope with TDD (or some sort of it) to get everyone into a discipline mode, which will lead to better tests. Coverage should follow.

Anyway, I think it's worth trying, but it needs commitment and discipline, similar to agile... it has to be tried as a team.

Reply on news.ycombinator.com