Re: Suggestion, advice on TDD adoption

On Wed, Apr 6, 2016 at 4:53 AM, [email protected]
[testdrivendevelopment] <[email protected]> wrote:

>
>
> HI,
>
> We have recently started using TDD. We have gone through the training,
> learned some of the TDD good practices/challenges, using junit, mockito
> tools/framework etc. Since its an early start to the journey, I would be
> glad to hear some practical advice from folks here, some of the DOs and
> Dont's, tips and tricks etc. We are going to have a bumpy ride, especially
> with exisitng code, so it will really help if we can hear from experinced
> people.
>
>
>
Al makes a good point, although I wouldn’t say, “orders of magnitude more
difficult.”

You are going to spend a lot of time writing tests for code that already
exists and then having to break that code in order to make it testable.
This is not exactly TDD. In fact, it is the problem that TDD was designed
to solve.

It is good advice to spend a little time test-driving new code to get your
feet wet, especially for programmers who are less experienced overall.

Additionally,

1. Focus on getting something wrapped in a test and then refactoring under
test until you have a good solid OO design within the boundary of the test.
It will feel like you are refactoring way too much at first, but pushing
all the way to the boundary is the only chance you have to make the design
better rather than just not worse.

2. Get in the habit of treating every test failure in integration as an
emergency. Don’t succumb to the temptation to treat intermittent failures
as normal. It will undermine the culture of quality and rapid feedback that
you are trying to build.

3. It is really hard to overstate the value of pair programming and
continuous integration in this context. These practices are very
synergistic, and you will get better results faster if you do them
together.