Test Driven Development TDD

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).

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)

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

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

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

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

Methodology

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

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

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." (

Disadvantages of writing tests first Doesn’t work well for GUIs or multi- threaded applications Impractical for use with legacy code

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.

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

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)

Test First Give an example Write test case 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?)

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?

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

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

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

“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

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?

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

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

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

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?)

Div: Test2 What should we test?

Div: Test2 (6 new tests) What should we test? –Negative DividendDivisorBoth –0 DividendDivisorBoth

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?

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.

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 =

EWScaling Things to test for: –Magnitude of input –Range: -90 – 90 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

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

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)