Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A Brief Introduction to Test-Driven Development

This is a brief presentation I gave to the ODU ACM chapter on Test-Driven Development in February of 2012.

  • Login to see the comments

A Brief Introduction to Test-Driven Development

  1. 1. A Brief Introduction to Test- Driven Development Shawn M. Jones
  2. 2. Who am I? • Graduated ODU in 1999 with BS in Computer Science • Currently working on Master’s Degree in Computer Science • Worked for Department of Navy since 1997: – Web Development – System Administration – Information Assurance (Computer Security) – Requirements Analysis – Application Development/Build Management – Never worked in QA or IV&V
  3. 3. Sources for this Presentation • Beck, K. (2003). Test-Driven Development By Example. Boston: Addison-Wesley. • Fowler, Martin. Refactoring. • Osherove, R. (2012). “Write Maintainable Unit Tests That Will Save You Time and Tears”. MSDN Magazine. • (2012) Cunningham & Cunningham. • Personal Experience
  4. 4. What do you know about automated testing?
  5. 5. Why You Should Care About Automated Testing • Automated testing allows you to check quickly if you have changed how the code behaves. • Automated testing provides other developers an idea of how your functions/classes/libraries are intended to be used. • Without automated tests, how do you know your code actually does what you intended? How much confidence do you have in it?
  6. 6. What do you know about TDD? • TDD = Test Driven Development • What else do you know?
  7. 7. Tools for TDD • Testing framework: – JUnit (for Java) – NUnit (for .NET) – Unittest (for Python) – Roll your own, if necessary • To-Do List • Software Project
  8. 8. The Rhythm of Test-Driven Development (TDD) 1. Quickly add a test. 2. Run all tests and see the new one fail. 3. Make a little change. 4. Run all tests and see them all succeed. 5. Refactor to remove duplication.
  9. 9. The Rhythm of Test-Driven Development (TDD) Quickly add a test Run all tests and see the new one fail Make a little change Run all tests and see them all succeed Refactor to remove duplication
  10. 10. 1. Quickly add a test • Write the test before you write the code. • This is hard for most of us, because we want to solve the functionality problem now. • Think about how to best use the target code. How do you want to call that code?
  11. 11. 2. Run all tests and see the new one fail • Run the test, even if there is no target code for it yet. • Failure is the expected behavior, it provides a known good starting point. • What do you do if it passes when it shouldn’t? – There’s no target code yet, why is it passing? – Look at the test, is it a good test?
  12. 12. 3. Make a little change • Now you can write the target code to pass the test. • We’re just focusing on the target code for this existing automated test. • Anything else you can think of should be added to your to-do list.
  13. 13. 4. Run all tests and see them all succeed • Now you know that your code does what you wanted and you have a way to prove it in the future. • If the code doesn’t pass the test, go fix it and come back to this step. • Once it works, you have confidence in the code that you wrote.
  14. 14. 5. Refactor to remove duplication • Refactoring – “a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior” – Martin Fowler • Removing duplication ensures that future tests require fewer changes in the code, limiting dependency between modules (loosely coupled).
  15. 15. Why You Should Care About TDD • TDD is not really just a testing strategy, it is a design strategy. • Code with well-written tests tends to be more modular, loosely coupled, and easier to incorporate into the application. – This makes the code easier to maintain – It also makes the code more understandable to others
  16. 16. Why You Should Care About Better Code • Remember, you will have to live with your code • Six months from now you will remember far less about how it works, but you are still the expert for your code • Your coworkers will appreciate you more; they have to live with your code, too
  17. 17. Excuses for not using TDD • “No automated testing framework exists for the language/API/etc. in use” • “Our application is mostly configuration files, with no real code.” • “We’re just writing scripts, not real code” • “TDD is only for classes. My code has no classes.” • “I’m a developer, not a tester.” • “Do you want us to produce functionality or tests?” • “The existing application has no automated tests.”
  18. 18. When not to use TDD? • Research for a new language/API/framework where you will throw away all of your research code. • The language/OS has some construct that cannot be evaluated by an automated test (e.g. Console object in Java) • You don’t have the hardware for testing the given requirement.
  19. 19. Issues with TDD • Tests are additional code that must be maintained with the code • User interfaces can be tested, but change often (use patterns such as MVC in order to limit how much code ends up in the UI) • TDD requires management support; management may not believe testing is worthwhile
  20. 20. Other issues with TDD • Use of TDD may cause the organization to believe other testing (functional, user experience, etc.) is not necessary • The tests are only as good as the developer who wrote them (e.g. a developer unaware of SQL injection attacks will not check for them)
  21. 21. Questions?