Why Use Test Driven Development (TDD)?

 Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD.

 Legacy applications has constant impediments.  Agility and adaptability.  Reduces defects which reduces necessary support resources.

 Did NOT over- engineer.  Not here to write code; you’re here to ship products.  Automated unit tests sounds great in principle; but we need to cut things out. Customers don’t care if there are no automated unit tests.

 Released Version 1 in  Browser Wars with IE. (1995 to 1999)  Lost market share control in  Released Version 4 in  Became unstable; random crashes, buggy, and slow.  Acquired by AOL on March 17, 1999 for $4.2 Billion.  Attempted to fix, but the code base became so horrible that they decided to do a complete code re-write… from scratch.  Mozilla Firefox is the result.

 Case studies have shown that TDD decreases defect density between 40% to 90%.  However, there was an increase in development time but only by 15% to 35%.  TDD improves code quality and structure making future changes easier.  IBM, Microsoft, and North Carolina State University Case Study IBM, Microsoft, and North Carolina State University Case Study  Maria Siniaalto (2006)

 Test driven development is where the developer writes an automated unit test before writing the code to make that unit test pass.

 You get immediate feedback if your code works or doesn’t work.  You will have a suite of regression tests.  You will have clear use cases in how the methods should be called.  Forces you to know your requirements before you begin writing the code.

 Hard to write tests correctly.  If not done correctly (as in tests are too tightly coupled to implementation) then those tests need to be changed frequently.  Can’t write unit tests with badly structured code. (As in no layers)

 Save time by not in constant debug mode and stepping in and out of code.  Visual feedback that all changes have not broken existing parts of the application without having to debug all of the possible parts.

 Expect requirements to change. Changing requirements are managed by adopting an incremental approach and paying increased attention to design to accommodate change. Apply more rigor, rather than less, to avoid costly and unnecessary rework.  Know why you’re testing. Recognize that there are two distinct forms of testing, one to build correct software (debugging) and another to show that the software built is correct (verification). These two forms of testing require two very different approaches.

 Elimate errors before testing. Better yet, deploy techniques that make it difficult to introduce errors in the first place. Testing is the second most expensive way of finding errors in the first place. The most expensive way is to let your customers find them for you.  Write software that is easy to verify. If you don’t, verification and validation (including testing) can take up to 60% of the total effort. Coding typically takes only 10%. Even doubling the effort on coding will be worthwhile if it reduces the burden of verification by as little as 20%.

 Develop incrementally. Make very small changes, incrementally. After each change, verify that the updated system behaves according to its updated specification. Making small changes makes the software much easier to verify.  Some aspects of software development are just plain hard. There is no silver bullet. Don’t expect any tool or method to make everything easy. The best tools and methods take care of the easy problems, allowing you to focus on the difficult problems.

 Software is not useful by itself. The executable software is only part of the picture. It is of no use without user manuals, business processes, design documentation, well-commented source code, and test cases. These should be produced as an intrinsic part of the development, not added at the end. In particular, recognize that design documentation serves two distinct purposes:  To allow the developers to get from a set of requirements to an implementation. Much of this type of documentation outlives its usefulness after implementation.  To allow the maintainers to understand how the implementation satisfies the requirements. A document aimed at maintainers is much shorter, cheaper to produce and more useful than a traditional design document.

Mocking frameworks are essentially a requirement for automated unit testing. There are a few that are available for free. Teleriks’ Just Mock Moq Increase efficiency with Ncrunch

 Not afraid to make changes.  Not worried about breaking existing code.  Loss of code ownership by an individual since anyone can participate in making changes without breaking existing features.

 It’s hard and it takes patience because the learning curve is steep.  There will be more hurdles and obstacles.  Technical debt will eventually fade away and customers will notice the difference in quality and efficiency.  You’ll get 40% to 90% less phone calls at midnight.

Thank you and have a great day! References: Seven Key Principles: cert.gov/articles/knowledge/sdlc- process/secure-software-development-life-cycle- processes