TEST DRIVEN DEVELOPMENT
Why Use Test Driven Development (TDD)?
Agenda
Why the need to change to TDD. Talk about what TDD is. Talk about the expectations of TDD.
Why Change?
Legacy applications has constant impediments.
Agility and adaptability. Reduces defects which reduces necessary
support resources.
Netscape Navigator
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.
Netscape Navigator
Released Version 1 in 1994. Browser Wars with IE. (1995 to 1999) Lost market share control in 1997. Released Version 4 in 1998. 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
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
Maria Siniaalto (2006)
Technical Debt
Automated Testing Vs Manual Testing
What is TDD?
Test driven development is where the developer writes an automated unit test before writing the code to make that unit test pass.
Positives of TDD
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.
Negatives of TDD
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)
Immediate Feedback
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.
Seven Key Principles
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.
Seven Key Principles (cont)
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%.
Seven Key Principles (cont)
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.
Seven Key Principles (cont)
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.
3rd Party Tools
Mocking frameworks are essentially a requirement for automated unit testing. There are a few that are available for free.Teleriks’ Just MockMoq
Increase efficiency with Ncrunchwww.ncrunch.net
Regression Test Suite
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.
Software Maintenance
Conclusion
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.
Questions
Thank you and have a great day!
References: Seven Key Principles:
https://buildsecurityin.us-cert.gov/articles/knowledge/sdlc-process/secure-software-
development-life-cycle-processes