Why Use Test Driven Development (TDD)?. Why the need to change to TDD. Talk about what TDD is. ...

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