
Ask HN: How can I convince a team member to try TDD - rooam-dev
Hello,<p>I hope someone could share their experience with a similar situation.<p>Basically, I get a strong push back from a fellow co-worker to try TDD. He thinks it&#x27;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&#x27;t want to get out his comfort zone. I don&#x27;t want to overrule him, but it may get to it, because it gives a bad example to newer team members.<p>So far my best argument is: &quot;Don&#x27;t do it for you, do it for the team&quot;.<p>What do you think g(uy|irl)s?<p>Thank you in advance.<p>PS: Not sure if it matters, but we use groovy + spring.
======
drugme
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."

~~~
rooam-dev
Haha, good one. My goal is just to try it before saying no.

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

~~~
rooam-dev
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.

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

~~~
rooam-dev
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.

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

~~~
rooam-dev
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.

------
maketechfair
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!

~~~
rooam-dev
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.

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

~~~
rooam-dev
Thank you.

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

~~~
rooam-dev
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.

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

~~~
rooam-dev
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.

~~~
AnimalMuppet
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.

~~~
rooam-dev
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.

