TDD for new team

[[e-mail] [SCRUMDEVELOPMENT]]

Hi, I have one question about TDD for new team.



I know TDD is a great tool to have deliveries with high quality, but what should we do until everybody learns it. In your experience, how long does it takes in average for someone produce unit tests with quality?




I've got a new project with a new team, and none of them knows TDD. Basically, all of them have no experiences with any similar to unit testing. They are trying to learn it, for real, but so far unit testing they are doing is quite poor.


There are some points they test to much, other points they forget. To make it harder, contract demands a test coverage percentage and it's been quite hard for them to focus on quality, not just quantity.


thanks, Daniel

[George Dinwiddie [e-mail] [SCRUMDEVELOPMENT]]

Daniel,

Post by ***@yahoo.com.br [SCRUMDEVELOPMENT]
Hi, I have one question about TDD for new team.
I know TDD is a great tool to have deliveries with high quality, but
what should we do until everybody learns it. In your experience, how
long does it takes in average for someone produce unit tests with quality?

Doesn't that depend on whose judgement of quality? How do your team
members feel about the quality of their unit tests?

Post by ***@yahoo.com.br [SCRUMDEVELOPMENT]
I've got a new project with a new team, and none of them knows TDD.
Basically, all of them have no experiences with any similar to unit
testing. They are trying to learn it, for real, but so far unit testing
they are doing is quite poor.
There are some points they test to much, other points they forget.

Hmmm... Are you sure they're doing TDD and not Test-After?

Post by ***@yahoo.com.br [SCRUMDEVELOPMENT]
To
make it harder, contract demands a test coverage percentage and it's
been quite hard for them to focus on quality, not just quantity.

Ugh, test coverage targets invite poor testing. But if they're really
doing TDD, it shouldn't be a problem.

Are you practicing TDD, yourself?

The best, easiest, fastest way for people to learn TDD in my experience
is for them to pair with someone who is already experienced in TDD.
Another good technique is to have sessions with the whole team where you
look at some code and tests and discuss it.

It's not hard if people want to learn it. It is hard if people aren't
really interested but are being pushed into it.

- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------



------------------------------------
Posted by: George Dinwiddie <***@iDIAcomputing.com>
------------------------------------

To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-***@eGroups.com

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

The way I describe it to my teams is that they should write all the tests
that make them confident that a new change won't break existing
functionality. If they see tests as just a path to a required metric, it
will always be about quantity (you get what you measure). But if they see
tests as a tool that will allow them to spend more time developing and less
time debugging and firefighting, they will be motivated to write good
tests. When a bug slips through the tests, use it as a learning
opportunity to get better at writing tests that prevent bugs from
escaping. As the team starts to develop a zero tolerance for bugs, you
will get your test coverage as a natural byproduct of development.


-Cass

Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]
Daniel,

Post by ***@yahoo.com.br [SCRUMDEVELOPMENT]
Hi, I have one question about TDD for new team.
I know TDD is a great tool to have deliveries with high quality, but
what should we do until everybody learns it. In your experience, how
long does it takes in average for someone produce unit tests with

quality?
Doesn't that depend on whose judgement of quality? How do your team
members feel about the quality of their unit tests?

Post by ***@yahoo.com.br [SCRUMDEVELOPMENT]
I've got a new project with a new team, and none of them knows TDD.
Basically, all of them have no experiences with any similar to unit
testing. They are trying to learn it, for real, but so far unit testing
they are doing is quite poor.
There are some points they test to much, other points they forget.

Hmmm... Are you sure they're doing TDD and not Test-After?

Post by ***@yahoo.com.br [SCRUMDEVELOPMENT]
To
make it harder, contract demands a test coverage percentage and it's
been quite hard for them to focus on quality, not just quantity.

Ugh, test coverage targets invite poor testing. But if they're really
doing TDD, it shouldn't be a problem.
Are you practicing TDD, yourself?
The best, easiest, fastest way for people to learn TDD in my experience
is for them to pair with someone who is already experienced in TDD.
Another good technique is to have sessions with the whole team where you
look at some code and tests and discuss it.
It's not hard if people want to learn it. It is hard if people aren't
really interested but are being pushed into it.
- George
--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------

[[e-mail] [SCRUMDEVELOPMENT]]

For sure they are not doing TDD the right way, probably testing later. I didn't say test coverage is good or bad, just that it makes them loosing their focus.

The point is that besides reading and training, they are slow adopters for this technique. Meanwhile, quality is suffering.


Thank you, Daniel




---In ***@yahoogroups.com, <***@...> wrote :

The way I describe it to my teams is that they should write all the tests that make them confident that a new change won't break existing functionality. If they see tests as just a path to a required metric, it will always be about quantity (you get what you measure). But if they see tests as a tool that will allow them to spend more time developing and less time debugging and firefighting, they will be motivated to write good tests. When a bug slips through the tests, use it as a learning opportunity to get better at writing tests that prevent bugs from escaping. As the team starts to develop a zero tolerance for bugs, you will get your test coverage as a natural byproduct of development.
-Cass
On Jun 28, 2014 12:30 PM, "George Dinwiddie ***@... mailto:***@... [SCRUMDEVELOPMENT]" <***@yahoogroups.com mailto:***@yahoogroups.com> wrote:
Daniel,

Post by ***@yahoo.com.br [SCRUMDEVELOPMENT]
Hi, I have one question about TDD for new team.
I know TDD is a great tool to have deliveries with high quality, but
what should we do until everybody learns it. In your experience, how
long does it takes in average for someone produce unit tests with quality?

Doesn't that depend on whose judgement of quality? How do your team
members feel about the quality of their unit tests?

Post by ***@yahoo.com.br [SCRUMDEVELOPMENT]
I've got a new project with a new team, and none of them knows TDD.
Basically, all of them have no experiences with any similar to unit
testing. They are trying to learn it, for real, but so far unit testing
they are doing is quite poor.
There are some points they test to much, other points they forget.

Hmmm... Are you sure they're doing TDD and not Test-After?

Post by ***@yahoo.com.br [SCRUMDEVELOPMENT]
To
make it harder, contract demands a test coverage percentage and it's
been quite hard for them to focus on quality, not just quantity.

Ugh, test coverage targets invite poor testing. But if they're really
doing TDD, it shouldn't be a problem.

Are you practicing TDD, yourself?

The best, easiest, fastest way for people to learn TDD in my experience
is for them to pair with someone who is already experienced in TDD.
Another good technique is to have sessions with the whole team where you
look at some code and tests and discuss it.

It's not hard if people want to learn it. It is hard if people aren't
really interested but are being pushed into it.

- George

--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org http://www.agilemaryland.org
----------------------------------------------------------

[Adam Sroka [e-mail] [SCRUMDEVELOPMENT]]

Post by ***@yahoo.com.br [SCRUMDEVELOPMENT]
For sure they are not doing TDD the right way, probably testing later. I
didn't say test coverage is good or bad, just that it makes them loosing
their focus.

If you know they aren't doing it right then you know the problem you have
to solve. Try to identify the root cause and an experiment you could do to
look for improvement.

For sure one of the main problems with coverage metrics is that they steal
the focus away from proper testing. As I've said before on this and other
lists they can be useful as a tool to sell testing to management, but that
is the only way I use them.

Post by ***@yahoo.com.br [SCRUMDEVELOPMENT]
The point is that besides reading and training, they are slow adopters for
this technique. Meanwhile, quality is suffering.

I would be careful. There are at least a couple assumptions there that you
could test. Why do they appear to be slow? What difficulties can you
directly attribute to quality? How would it look different if they were
doing it better? What are some things you could try to move in that
direction? Etc.

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

Daniel,

Post by ***@yahoo.com.br [SCRUMDEVELOPMENT]
I know TDD is a great tool to have deliveries with high quality, but what should we do until everybody learns it. In your experience, how long does it takes in average for someone produce unit tests with quality?
I've got a new project with a new team, and none of them knows TDD. Basically, all of them have no experiences with any similar to unit testing. They are trying to learn it, for real, but so far unit testing they are doing is quite poor.
There are some points they test to much, other points they forget. To make it harder, contract demands a test coverage percentage and it's been quite hard for them to focus on quality, not ju st quantity.

Your question gives me concern for the team’s understanding of TDD. TDD will give you excellent test coverage if you actually do it. (This is pretty true for any good idea — it only works if you use it.)

But TDD isn’t about unit tests. It is, however, about quality. TDD is an approach to building software that lets the design emerge as you go, and it results in highly modular and well-structured code — if you actually do it.

For someone of even moderate skill, I believe you go faster with TDD, because the design stays clean and you make fewer mistakes.

However, very few people seem to learn TDD by reading about it and thinking about it. Some do, certainly, but it’s not common in my experience. It’s possible that you’d progress better with some training or help, if you can find a way to do that.

Ron Jeffries
www.XProgramming.com
I try to Zen through it and keep my voice very mellow and low.
Inside I am screaming and have a machine gun.
Yin and Yang I figure.
-- Tom Jeffries

[Adam Sroka [e-mail] [SCRUMDEVELOPMENT]]

I think it probably varies tremendously but my experience has been that at
about 6-18 months of deliberate practice most people will be practicing TDD
competently. The way to tell is to pair them with someone experienced and
see how often they need to be reminded to write a test, or not refactor in
the red, or not violate one of the basic principles. By about 6-18 months
it will rarely, if ever, happen. The conversation will generally be about
higher level domain and design concepts by that point and the TDD rhythm
will just flow.

However, that is just the beginning of the journey for most people. Doing
TDD well means constantly evolving and changing the code. That pushes most
people's design skills past the envelope and bridges many different topics
in computer science. You need to know the language you are using pretty
well, have a pretty solid understanding of OO and/or other design
paradigms, understand a bit about automated software testing, and have a
modicum of business sense to do TDD effectively the way it is done in XP.

Some coaching, or at least some training, is probably a good idea. Training
helps clear up the vocabulary and create a basic framework for ongoing
practice. Coaching gets more into the specifics of your day-to-day
operations, but takes a while and may be costly.

Post by ***@yahoo.com.br [SCRUMDEVELOPMENT]
Hi, I have one question about TDD for new team.
I know TDD is a great tool to have deliveries with high quality, but what
should we do until everybody learns it. In your experience, how long does
it takes in average for someone produce unit tests with quality?
I've got a new project with a new team, and none of them knows TDD.
Basically, all of them have no experiences with any similar to unit
testing. They are trying to learn it, for real, but so far unit testing
they are doing is quite poor.
There are some points they test to much, other points they forget. To make
it harder, contract demands a test coverage percentage and it's been quite
hard for them to focus on quality, not just quantity.
thanks, Daniel

[Michael Jesse [e-mail] [SCRUMDEVELOPMENT]]

Any time you start something new you will always have the velocity slower
in the beginning than later on. To me, it's no different than taking a
change from a retrospective and mature it into something that is part of
the day to day operations. Training TDD is important and to get it right.
I've written unit tests since 2004, so 10 years and I've done all kinds of
bad things at the beginning.


I thought testing the things that are working would be great since now I
know it won't break. Unfortunately, those are the parts of the code that
NEVER change and therefore it wasn't important at all to test.


You then try and get to 100% code coverage, but then again you are testing
for things that never change and are probably working. Now, I'm perfectly
aware of contracts by state, federal and international agencies that demand
100% code coverage, so you need to change how you write the code so it
doesn't feel like you are fighting against testing it thoroughly. More
design patterns and follow SOLID principles.


Writing unit tests for legacy code that has strange dependencies are the
worst.


A good book for the developers to read is Working Effectively with Legacy
Code
<https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CFIQFjAA&url=http%3A%2F%2Fwww.amazon.com%2FWorking-Effectively-Legacy-Michael-Feathers%2Fdp%2F0131177052&ei=xi20U8WJIYagyATp0ID4Cg&usg=AFQjCNEq5HkN-DJbjxfJPbXQK0Bl4fbsoQ&sig2=qjr9uvazDbVxg9_H2Bt1aA&bvm=bv.70138588,d.aWw>
by Michael Feathers. It has some good ideas about how to work with changes
to existing code and how to apply test harnesses.


This will force your development team to refactor/change the code and then
make sure that the existing functionality still works. This can easily
slow down a project, but then again, you probably shouldn't have written
the code in that manner anyways.


So if it appears that your team is slow, ask several questions.




- Is it legacy code dependencies making it difficult to test?
Suggestion: Write new code with unit tests in mind and see if you can do a
swap with a new file, code assembly, or even program.
- Is it not knowing WHAT needs to be tested? Suggestion: Go back to
your requirements and make sure you have User Acceptance Testing documented
correctly. There should not be an issue in describing how it should work
between the PO, DEV and QA members. Create Design Sessions if necessary to
make sure everyone knows what is expected before ANY coding and changes are
made.
- Production Support is you bogged down. Suggestion: Various ideas for
this one. I've seen companies have a dedicated team that does nothing but
fight fires while another team fixes them. Fix the issues that are most
critical first (e.g. the system goes down often, fails to restart after a
reboot, performance slows down quickly and then stops)




In all, TDD is not something you gain experience in very quickly. It's not
like making a peanut butter sandwich for lunch. It's more like creating a
menu for an entire restaurant and making sure the delivery of each meal is
perfect each time, every day.