A Brief Introduction to Test-Driven Development

1. A Brief Introduction to Test-Driven Development Shawn M. Jones

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. Sources for this Presentation • Beck, K. (2003). Test-Driven Development By Example. Boston: Addison-Wesley. • Fowler, Martin. Refactoring. http://martinfowler.com/refactoring/ • Osherove, R. (2012). “Write Maintainable Unit Tests That Will Save You Time and Tears”. MSDN Magazine.http://msdn.microsoft.com/en-us/magazine/cc163665.aspx • (2012) Cunningham & Cunningham.http://c2.com/cgi/wiki?TestDrivenDevelopment • Personal Experience

4. What do you know about automated testing?

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. What do you know about TDD? • TDD = Test Driven Development • What else do you know?

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. 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. • Refactorto remove duplication.

9. The Rhythm of Test-Driven Development (TDD)

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Questions?