Test Driven Development TDD

Size: px

Start display at page:

Download "Test Driven Development TDD"

Jonah Caldwell
5 years ago
Views:

1 Test Driven Development TDD

2 Testing Testing can never demonstrate the absence of errors in software, only their presence Edsger W. Dijkstra (but it is very good at the latter).

3 Testing If it's worth building, it's worth testing. If it's not worth testing, why are you wasting your time working on it? ( html)

4 TDD Test-first or test-driven development has origins in extreme Programming (XP) It is one part of XP that can be extracted and used on its own

5 extreme Programming Is a methodology for software development Focuses on the customer Has rules for: Planning Designing Coding Testing

6 TDD is also embraced by: Rational Unified Process (RUP) Agile Unified Process (AUP) Open Unified Process (Open UP) Scrum (agile methods)

7 TDD Is NOT a testing methodology It IS a development methodology Does not replace QA or thorough testing

8 Methodology

9 TDD Tests Are only part of the development process Not intended to aggressively find bugs They re weak A programmer taking a TDD approach refuses to write a new function until there is first a test that fails because that function isn t present

10 What are the purposes of a test? Does the code work? What do we mean by work? Make sure that changes don t break anything that is already working Documents features Measure of completeness

11 Advantages of writing tests first Quick results: Developers can see the effect of design decisions within minutes. Flexibility: Changes are easy because of the short distance between commits. Automatic catalog of regression tests: If something developed six months ago suddenly breaks under today's code, it is known immediately. Good, clean code that works: As the mantra of JUnit testing proclaims, "If the light is green, the code is clean." (

12 Disadvantages of writing tests first Doesn t work well for GUIs or multithreaded applications Impractical for use with legacy code

13 Effect or Side-effect? Documentation/specification This group of tests you have written becomes part of your documentation. They are a list of behaviors that you have shown work. List of tests might not be exhaustive but does document what HAS been tested.

14 Documentation Design specification? Tests are not sufficient but definitely an important part Requirements documentation? Not part of requirements Acceptance testing helps with requirements documentation

15 Good Unit Tests Run fast (they have short setups, run times, and break downs). Run in isolation (you should be able to reorder them). Use data that makes them easy to read and to understand. Use real data (e.g. copies of production data) when they need to. Represent one step towards your overall goal. (Kent Beck creator extreme Programming)

16 Give an example Write test case Test First Write code just enough to pass the test Run test (fail) Repeat (goto write code ) (pass) Refactor code or write new test (how do we decide which to do?)

17 Writing a test What should the code do? How can you tell if it does it? What does reasonable input look like? What does UNreasonable input look like? What about side effects? How do we test for them?

18 Side-effects? Good code should not have side effects Your methods (functions) should do one thing only TDD won t test of side-effects

19 What should your code do? What are the input parameters? What is the expected result?

20 How do you know if it works? Write a test to see if it works as expected Run the test. Rewrite the code.

21 as expected What do you expect it to do? What about bad inputs? Out of range values Uninitialized values? (pointers) Assertions vs error-handling code

22 Error handling code Conditions you expect to occur Consider how much this particular piece of code is protected from bad input in use Is it a private method? Should it be?

23 Assertions assert() These are used during development in your CODE, not your tests. Use for conditions you expect NEVER to occur.

24 Consider (an extremely simple example) A function to divide one number by another Test1: r = div(4,3); Run Test1: r = 1 What did we learn? r = div(num,den);

25 Div: Test1 What did we learn? Div returns an INT Is that what we want?

26 Div: Test1 (again) We ve changed to code to return float. (This is the only change we make! Why?) r = div(4, 3); r = ; Pass: refactor or new test? (how do we decide?)

27 Div: Test2 What should we test?

28 Div: Test2 (6 new tests) What should we test? Negative 0 Dividend Divisor Both Dividend Divisor Both

29 Div: Test2 How about divide by 0? r = div(4, 3); r = div(5.0, 0.0); (notice that I still run test 1) Should divide by zero be handled by an assertion or by error handling code?

30 What have we accomplished? We have refined the definition of div We have tests that we know our code passes We ve documented some of the behavior of div When something fails in the future, we have a list of tests. We can look to see if there are new tests that need to be written.

31 Example: Calculate EW Ratio We can approximate the ratio of the distance between elevations EW as compared to NS as cos(latitude) Requirement: Integer where 1 unit = 1/1000 arc second per unit Example: N = (40* * )*1000 =

32 EWScaling Things to test for: Magnitude of input Range: degrees Latitudes above 90 and below -90 What behavior should it have? The tests should reflect your DEFINITION of the behavior and should help you refine the definition

33 Tests Ratio = EWScaling(0); // 1.0 Ratio = EWScaling(90*3600*1000); // 0.0 Ratio = EWScaling(60*3600*1000); // 0.5

34 To employ TDD You design organically, with the running code providing feedback between decisions. You write your own tests because you can't wait 20 times per day for someone else to write them for you. Your development environment must provide rapid response to small changes (e.g you need a fast compiler and regression test suite). Your designs must consist of highly cohesive, loosely coupled components (e.g. your design is highly normalized) to make testing easier (this also makes evolution and maintenance of your system easier too). (Beck)

Object Oriented Software Design - I

Object Oriented Software Design - I Unit Testing Giuseppe Lipari http://retis.sssup.it/~lipari Scuola Superiore Sant Anna Pisa November 28, 2011 G. Lipari (Scuola Superiore Sant Anna) Unit Testing November