1 / 8

Test-Driven Development

Test-Driven Development. CSE301 University of Sunderland Dr. Giles Oatley. Sources. Fowler, 2000, Refactoring: Improving the Design of Existing Code, Addison-Wesley. http://www.amazon.com/exec/obidos/tg/detail/-/0321109295/103-4060125-0311065

zuriel
Download Presentation

Test-Driven Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Test-Driven Development CSE301 University of Sunderland Dr. Giles Oatley

  2. Sources • Fowler, 2000, Refactoring: Improving the Design of Existing Code, Addison-Wesley. • http://www.amazon.com/exec/obidos/tg/detail/-/0321109295/103-4060125-0311065 • http://www.amazon.com/exec/obidos/ASIN/0130648841/103-4060125-0311065 • http://www.refactoring.com/catalog/ • http://www.win.ua.ac.be/~lore/refactoringProject/index.php • Extensive discussions on the comp.object newsgroup.

  3. Topics • Test-Driven Development • JUnit • Refactoring • Principles • Bad Smells in Code • A Catalog of Refactorings

  4. Test-Driven Development • The test-driven development is the method of software development where tests specify interfaces of implementation and all code must have passed the tests. (Wikipedia)

  5. Test-Driven Development Roughly: 1. Write a test for a bit of functionality. 2. Show that it fails. 3. Write the code to make the test pass. Additionally. 1. Do not write production code until there is a failing test. 2. Write the simplest possible production code to get the test to pass. 3. Do not write more tests when we have a failing test. 4. Do not add to a failing test.

  6. Further Comments • If you watched someone doing TDD you would see them oscillating between test code and production code once every minute or so. • During each oscillation the programmer would add a few lines to his test code, thus making it fail (or not compile) and then add just a few lines to his production code in order to make the test pass (or compile). • Each oscillation is so simple that it's not worth taking. • Each oscillation is so simple that the risk of error is close to zero. • If you walk into a room of people working this way, and chose anyone at random, a minute ago all his code would have been working.

  7. Working with JUnit IMPORTANT TUTORIAL WORK • Eclipse version (at least) 3.0. • Download and install the examples. • Create a JUnit project. Read the test examples provided for ideas. • Open the properties for your project. Go to Project References and select the JUnit project. • Create an AllTests class for your project to run your test suite. • Create appropriate unit test classes and insert them in your test suite.

  8. Eclipse and TDD • Work through the Eclipse-JUnit tutorial at: http://www.onjava.com/pub/a/onjava/2004/02/04/juie.html

More Related