Podcast: Play in new window | Download (Duration: 28:37 — 13.2MB) | Embed
Subscribe: Spotify | RSS | More
Vic and Jon are joined by Larry Lawhead (lawhead5@hotmail.com) and Dale Ellis (@thedigitaldale) for peaceful morning of Agile and coffee.
In this episode, our heroes discuss the following topics:
- upcoming Agile conferences
- self-help in free software
- core scrum
- TDD takes 2x as long?
Reach out to Vic (@AgileCoffee) and Jon (@WaterScrumBan) on Twitter – and use the hashtags #askAgileCoffee or #tellAgileCoffee to interact with us on an upcoming episode.
TDD takes twice the time
The first thing that needs to be considered when talking about the time it takes to implement Test Driven Development is that it is a skill that has to be learned. When learning TDD the time to benefit ratio skews toward time. Further more during the learning period any implementation will have many incorrect assumptions and thoughts.
When it was mentioned that the architect said that test breakage increases time to implement, this is a testing smell. It means that the tests are potentially larger then a unit. A change should only break tests testing what is being changed. The developer should be able to easily ascertain what tests will break before making a change.
Fortunately there are books that can help with this. Bellow I recommend 3 books that help with learning how to separate concerns and reduce problems incurred during TDD.
1. xUnit Test Patterns: Refactoring Test Code
2. Working Effectively with Legacy Code
3. Refactoring to Patterns