1
The correct answers to the quiz were: 1) Test First Development 2) True. Risk-averse means “against” risk or opposed to risk. By using TDD risk of new bugs being introduced is reduced, therefore TDD is risk-averse. 3) Which Agile Manifesto values are supported by TDD? Responding to change over following a plan: By having proper tests in place, any changes requested can be accommodated much easier and therefore allows a team to be more responsive to changes. Working software over comprehensive documentation: Making use of TDD ensures working software. Some authors even see the test cases that are written as a form of documentation and therefore TDD supports both sides of this value. July Issue 4 , Welcome to this week’s issue of The Lean Pig! This week’s newsletter will look at TDD in a bit more detail. The possible challenges involved as well as possible ways to overcome them will be discussed. Read on to find out more! Did you Know? Scott Ambler has released a new agile survey “State of the IT Union”. Go check it out! In last week’s newsletter the concept of Test-driven development (TDD) was introduced. TDD involves much more than just writing tests for any code written. It involves taking a step back and investigating what you are doing, as well as why. Implementing TDD can be a very challenging process as it involves a different way of thinking. In order to overcome these challenges teams need to understand how TDD supports the Agile Manifesto. TDD supports two of the Agile Manifesto values, namely “Working software over comprehensive documentation” and “Responding to change over following a plan” (you probably recognize this from the quiz of last week!). TDD is more a tool or a process supporting development rather than people and the communications and interactions between them. Therefore it doesn’t support the value “Individuals and interactions over processes and tools”. This certainly doesn’t mean TDD is against agile! Practices that work in one environment won’t necessarily work in another. It is also clear to see that the value “Customer collaboration over contract negotiation” doesn’t involve TDD. The deadline for this week’s quiz is COB next week Wednesday 1 August. Correct answers can be emailed to me. The answer to the question will be revealed in the newsletter of next week. 1) Name 3 challenges faced when implementing TDD. 2) Test cases written using TDD can be used as specifications. True / False 3) Why is it not unusual to see the TDD approach collapse after the 3rd iteration? Thanks for reading this week’s newsletter! Enjoy your weekend! One important benefit of TDD is that it ensures working software. Therefore it supports the value “Working software over comprehensive documentation”. Some resources even mention that the test cases written during TDD can be used as documentation, and thus it can even support the right hand side of the manifesto value! TDD assists teams to respond to change faster while reducing the risk of introducing new defects and therefore supports the value “Responding to change over following a plan”. Once teams can open their eyes to this bigger picture, it will be much easier to understand and overcome the challenges involved in TDD adoption. The previous issue of the Lean Pig touched briefly on some TDD challenges, including the steep learning curve for teams unfamiliar with TDD, as well as possible resistance to change. Apart from these issues mentioned, a few other challenges have also been identified by authors like Scott Allen, James Shore, Greg Lucas and Scott Bain. The two biggest challenges identified by these authors are that teams might slow down their rate of development and be less productive due to the learning curve as well as time taken to create tests for all legacy code. Without management buy-in this can cause TDD to develop a bad reputation and be rejected completely without thought. Another problem with TDD mentioned by Scott Allen lies in the description of the methodology: According to Allen this is the wrong way to motivate people aiming for success. Due to our natural feeling of opposition against failure, we then tend to change words to have a more disguised meaning such as “deferred success” or “issues”, rather than the true meaning. Our brains process these “gentler” words in a much more positive light, as opposed to focus on the word “failure”. According to both Scott Bain and Greg Lucas, the way that TDD forces teams to think differently about the order in which to complete tasks (test first before code), can leave them feeling that it doesn’t make business sense. The larger the size and the higher the rate of complexity of a system, the harder it is to create tests that take all factors into account. In situations where developers need to write tests for an existing code base, it becomes even harder if the developers know their code very well, seeing that they are unable to create all-inclusive tests. Scott Bain also mentions another challenge that carries significant weight, namely that it is not uncommon for a TDD approach in a team to cave in after the third iteration. This happens for various reasons including that the tests are difficult to change, writing a test takes too long, and keeping multiple tests in sync is challenging. This can also relate back to the “just quickly” mentality mentioned in the previous issue of the Lean Pig. All of the authors discussed here also recommend ways in which these challenges can be overcome. Scott Bain indicates that the tests written by teams should not be seen as tests, but rather as specifications. By writing test cases in Test-first development we are replacing the traditional form of specifications with automated ones. Looking at it from this angle one can see that it is not double work being done then. To overcome the steep learning curve, developers can also be provided with training opportunities to increase their knowledge on the topic. When development time increases and productivity rates drop due to TDD, it is important to manage different parties’ expectations in terms of TDD. Initially when adopting TDD, development time will increase, but teams will spend much less time debugging code when something goes wrong. In terms of TDD for existing code, Greg Lucas makes the recommendation to teams to not write tests for the existing code, unless a bug was discovered or if new features need to be added to existing code. Another technique recommended by James Shore is to include testing time when estimating tasks to give developers a little more breathing room for testing. Also never try to implement TDD alone as an individual in a team, but rather make sure that the entire team agrees to implement it together! In this article we’ve seen that deciding to implement TDD is not just a quick and easy task to do, but involves patience, cooperation and team work to be able to benefit from it optimally and reap the rewards in the long run. Also please not that TDD does not just apply to coding environments, but can be used in database development as well! Refer to this article for more information… everything agile Compiled by Christelle Yiu, Senior Software Engineer, Entelect
