http flic krpb Leo Rk TestDriven Development From

http: //flic. kr/p/b. Leo. Rk Test-Driven Development

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?

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

n sig ts en m ire ning n o i t ta De qu Re Initial Planning Plan Analysi s Iterative Development Process n e m le Imp TDD combines Test a v E it on lua ing Deployment

Running Example: Preorder Coffee with Gift Card

US and Tasks Start with Task 1

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

Next Step: Write Test Code

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

Next: Write code to make the test pass

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

Test-Driven Development Cycle

Next (Red): Test order information

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

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

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

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

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

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

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

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

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

Strategy Pattern Is One Way Order. Processor uses DBAccessor interface instead of either concrete class

Here are some example strategies

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

Mocks Example

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

Practical Tips on Mocking • Several frameworks – Mockito actually seems to be most popular • URL: http: //mockito. org/ • Maven dependency: org. mockito-all • Servlets can be unit (not integration) tested using mocks – Requires a lot of mocks (request, response, session, etc. ) – Examples: • http: //johannesbrodwall. com/2009/10/24/testing-servlets-withmockito/ • http: //stackoverflow. com/questions/5434419/how-to-test-myservlet-using-junit

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