Unit 4 Test First Development 1 Copyright 2006

Test First • Many programmers have adopted this approach with near religious zeal “Test-first

The Process • Write a test that specifies a tiny bit of functionality •

The Philosophy • Tests come first • Test everything • All unit tests run

Implications • Code is written so that modules are testable in isolation. – Code

Problems – Unit Testing • Specifications are hidden in the tests • Tests should

The Improved Process • Design the interface for the component • Write a test

Extensions • Test driven development focuses on unit testing – Increments could be defined

Getting the Code Right vs. Getting the Right Code • Test first development ensures

100% • All unit tests run at 100% all the time • We can’t

Problems – Acceptance Testing • Specifications are hidden in the tests • Tests should

Automating System Tests at the GUI Level • Capture and playback tools don’t work

Slides: 12

Download presentation

Test First • Many programmers have adopted this approach with near religious zeal “Test-first design is infectious! Developers swear by it. We have yet to meet a developer who abandons test-first design after giving it an honest trial. ” Robert C. Martin 2 Copyright © 2006 Korson-Consulting

The Process • Write a test that specifies a tiny bit of functionality • Compile the test and watch it fail (you haven't built the functionality yet!) • Write only the code necessary to make the test pass • Refactor the code, ensuring that it has the simplest design possible for the functionality built to date • Repeat 3 Copyright © 2006 Korson-Consulting

Implications • Code is written so that modules are testable in isolation. – Code written without tests in mind is often highly coupled, a big hint that you have a poor object-oriented design. If you have to write tests first, you'll devise ways of minimizing dependencies in your system in order to write your tests. • The tests act as documentation. – They are the first client of your classes; they show the developer intended for the class to be used. • The system has automated tests by definition. – As your system grows, running full regression tests manually will ultimately take outrageous amounts of time. • Measurable progress is paced. – Tiny units of functionality are specified in the tests. Tiny means seconds to a few minutes. The code base progresses forward at a relatively constant rate in terms of the functionality supported. 5 Copyright © 2006 Korson-Consulting

Problems – Unit Testing • Specifications are hidden in the tests • Tests should not be the only documentation – Pre and post conditions should be explicit • Test first development should be combined with programming by contract 6 Copyright © 2006 Korson-Consulting

The Improved Process • Design the interface for the component • Write a test that specifies a tiny bit of functionality • Compile the test and watch it fail (you haven't built the functionality yet!) • Write only the code necessary to make the test pass • Refactor the code, ensuring that it has the simplest design possible for the functionality built to date • Repeat 7 Copyright © 2006 Korson-Consulting

Extensions • Test driven development focuses on unit testing – Increments could be defined by system level test cases • System level test cases, for an increment, should be created by the test team before code is written for that increment – Ideally these test cases would be approved by the stakeholders 8 Copyright © 2006 Korson-Consulting

Getting the Code Right vs. Getting the Right Code • Test first development ensures the code is doing what the developer intended it to do • Acceptance testing can now focus on determining how well the developer’s intent matches client’s expectations 9 Copyright © 2006 Korson-Consulting

100% • All unit tests run at 100% all the time • We can’t require the same for acceptance tests, because then we’d be back to big bang integration • So the rule for acceptance tests becomes – No integration is complete unless 100% of the previously passing acceptance test continue to pass. 10 Copyright © 2006 Korson-Consulting

Problems – Acceptance Testing • Specifications are hidden in the tests • Tests should not be the only documentation – Stakeholders will typically require a textual or tabular format for reviewing acceptance tests – Extreme XPers will resist having documentation outside of the executable code. 11 Copyright © 2006 Korson-Consulting

Automating System Tests at the GUI Level • Capture and playback tools don’t work well in a quasi-agile environment – The scripts they generate are not easily maintained • Choose a tool that has an API and write automated tests that call the tools interface – This can be overly time consuming compared to the risks it addresses • Create automated tests that operate just below the user interface – Sounds scary, doesn’t it 12 Copyright © 2006 Korson-Consulting