1. Test-Driven Development
Test-Driven Development

2. From a testing perspective, why might this scenario end badly?
Initial Plan: Implement software, then test at end
Implementation takes 6 months longer than expected
Finally, it’s time to test
System is huge, so testing job is HUGE
Pressure to ship causes skimping on testing
Defects discovered this late are costly to fix
But how to test earlier?

3. Test-Driven Development (TDD)
Idea: Test First!
Write unit tests before functional code
Typically blackbox tests

4. Iterative Development Process
Planning
Requirements
Analysis
Design
Implementation
Deployment
Testing
Evaluation
Initial Planning
TDD combines

5. Running Example: Preorder Coffee with Gift Card

6. US and Tasks
Start with Task 1

7. Further Break Down the Task
Represent order info
Represent gift card info
Represent receipt info
*Although these might have been tasks, they’re very small, so it made more sense to combine them into a larger task

8. Next Step: Write Test Code

9. Rule #1: Your test should fail before you implement any code
Establishes a measure of success
Promotes programming incrementally

10. Next: Write code to make the test pass

11. Rule #2: Implement the simplest code possible to make the test pass
Also helps to promote incremental programming
By focusing on small bits of code
Helps resist urge to add unwanted extras

12. Test-Driven Development Cycle

13. Next (Red): Test order information

14. In writing the test, you design the class interface — just enough interface!

15. Next (Green): Implement the interface you designed for the test

16. If in the process of building up classes, you realize your design could be improved, then REFACTOR! … and continue going around and around …

17. As you go, you expand upon the systems capabilities
You might do a test for each of these cases:
A gift card with more than enough to cover the cost of the order
A gift card without enough to cover the cost of the order An invalid gift card number
A gift card with exactly the right amount
A gift card that hasn’t been activated
A gift card that’s expired

18. Despite cons, TDD is a widely advocated practice
Pros/Cons of TDD
Pros:
Yields lots of test cases
More tests leads to increased confidence
Cons:
False sense of confidence?
Non-TDD folks may not understand why writing so many tests and not functionality
Despite cons, TDD is a widely advocated practice

19. Problem: How do you write a unit test for this?
DB-type I/O makes unit tests slow and complex

20. Here’s what we need for the system
Actual DB I/O

21. But here’s what we need for unit testing
Simulated (“fake”) DB I/O

22. How might you make the actual and the test DB utilities interchangeable?

23. Strategy Pattern Is One Way
OrderProcessor uses DBAccessor interface instead of either concrete class

24. Here are some example strategies

25. Another Way: Mocks Stand-ins for real objects
Especially good if faced with creating lots of concrete strategies
Requires framework (similar to JUnit)

26. Mocks Example

27. This may seem like a lot of code, but compared to a bunch of classes…
Mocks Example
Record Mode
This may seem like a lot of code, but compared to a bunch of classes…

28. Practical Tips on Mocking
Several frameworks
Mockito actually seems to be most popular
URL:
Maven dependency: org.mockito mockito-all
Servlets can be unit (not integration) tested using mocks
Requires a lot of mocks (request, response, session, etc.)
Examples:

29. What’s next? Productivity report due in one week (Tue)
1.5 days of work per team member
Exam 2 on next Thu