Re: Suggestion, advice on TDD adoption

I think the hardest part of starting with legacy code is that as novices
you will write brittle tests, and that is likely to give you bad design as
you redactor. It's really important that you go through the process of
learning what good (non fragile, non brittle) tests look like and how to
write them.

The advantage of working with legacy code however is that you have better
defined acceptance tests etc.
On Apr 6, 2016 11:29 PM, "Adam Sroka [email protected]
[testdrivendevelopment]" <[email protected]> wrote:

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