21
TEST DRIVEN DEVELOPMENT Why Use Test Driven Development (TDD)?

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

Embed Size (px)

Citation preview

Page 1: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

TEST DRIVEN DEVELOPMENT

Why Use Test Driven Development (TDD)?

Page 2: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

Agenda

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

Page 3: Why Use Test Driven Development (TDD)?.  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.

Page 4: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

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.

Page 5: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

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.

Page 6: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

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)

Page 7: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

Technical Debt

Page 8: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

Automated Testing Vs Manual Testing

Page 9: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

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.

Page 10: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

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.

Page 11: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

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)

Page 12: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

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.

Page 13: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

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.

Page 14: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

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%.

Page 15: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

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.

Page 16: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

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.

Page 17: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

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

Page 18: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

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.

Page 19: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

Software Maintenance

Page 20: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

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.

Page 21: Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD

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