[TDD] Suggestion, advice on TDD adoption

On Wed, Apr 6, 2016 at 4:53 AM, poojawandile@... [testdrivendevelopment] <testdrivendevelopment@...> 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.?

#35647

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 adam.sroka@... [testdrivendevelopment]" <testdrivendevelopment@...> wrote:

Show quoted text

?

On Wed, Apr 6, 2016 at 4:53 AM, poojawandile@... [testdrivendevelopment] <testdrivendevelopment@...> 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.?

#35648

On Wed, Apr 6, 2016 at 1:40 PM, Avi Kessner akessner@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:

?

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.

Keeping the tests informative (i.e. fail only for the right reason and do so quickly) requires deliberate effort either way. It is mostly impossible to write tests that aren’t brittle around code that is. That is why I suggest strongly that you keep refactoring until you have a “good OO design.” Defining that is a little bit complicated and probably belongs in its own thread.?

If you write brittle tests around brittle code and then say, “Okay, it’s covered. Now we’re done,” then you either know less about design than you need to or you are in denial (It could definitely also be both.)?

The advantage of working with legacy code however is that you have better defined acceptance tests etc.

It depends how legacy your legacy code is. I have encountered systems where the requirements were defined in a document no one had read and what the code did was not what the document said. I have encountered other systems where the only requirement was that the system keep doing whatever it was that it did, and no current employee knew what that was.?

开云体育

[TDD] Suggestion, advice on TDD adoption