1 / 13

Test-driven development (TDD)

Test-driven development (TDD). Why TDD.

veronica-norman
Download Presentation

Test-driven development (TDD)

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 (TDD)

  2. Why TDD • The point of TDD is to drive out the functionality the software actually needs, rather than what the programmer thinks it probably ought to have. The way it does this seems at first counterintuitive, if not downright silly, but it not only makes sense, it also quickly becomes a natural and elegant way to develop software.

  3. Start with the test • We start by writing some client code as though the code we want to develop already existed and had been written purely to make our life as easy as it could possibly be. • This is a tremendously liberating thing to do: by writing a model client for our code, in the form of a test, we can define programmatically the most suitable API for our needs. • In addition, we assert the behavior we want.

  4. The test fails • The next stage is to write the minimum amount of code to get the test compiling. That's all, just a clean compile, so you can run the test (which at this stage will fail).

  5. Write only enough • Now, and only now, you write the application code to satisfy the test. • The final piece of the puzzle is to refactor the code so it's as simple as it can be. • This then becomes your development rhythm: write a test, write some code, refactor.

  6. Test – then Code • Writing the test before you write the code focuses the mind - and the development process - on delivering only what is absolutely necessary. • In the large, this means that the system you develop does exactly what it needs to do and no more. • This in turn means that it is easy to modify to make it do more things in the future as they are driven out by more tests.

  7. Guidelines for test first design • The name of the test should describe the requirement of the code • Only write the simplest possible code to get the test to pass, if you know this code to be incomplete, write another test that demonstrates what else the code needs to do • If a test seems too large, see if you can break it down into smaller tests • If you seem to be writing a lot of code for one little test, see if there are other related tests you could write first, that would not require as much code • Test the goal of the code, not the implementation • One test/code/simplify cycle at a time. Do not write a bunch of tests, and try to get them working all at once • Keep writing tests that could show if your code is broken, until you run out of things that could possibly break

  8. Guidelines (cont) • If you are unsure about a piece of code, add a test you think might break it • A test is one specific case, for which there is a known answer • If all of the tests succeed, but the program doesn't work, add a test • Tests should be as small as possible, before testing a requirement that depends on multiple things working, write a test for each thing it depends • Tests should not take longer than a day to get working, typical test/code/simplify cycles take around 10 minutes • Do not fix a bug until you have written a test that demonstrates the bug

  9. JUnit.org • JUnit is an open source Java testing framework used to write and run repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks. • JUnit features include: • Assertions for testing expected results • Test fixtures for sharing common test data • Test suites for easily organizing and running tests • Graphical and textual test runners • The official JUnit home page is http://junit.org.

  10. The goal

  11. Installation of JUnit • Below are the installation steps for installing JUnit: • unzip the junit.zip file • addjunit.jar to the CLASSPATH. For example: set classpath=%classpath%;INSTALL_DIR\junit3\junit.jar • test the installation by using either the batch or the graphical TestRunner tool to run the tests that come with this release. All the tests should pass OK. Notice: that the tests are not contained in the junit.jar but in the installation directory directly. Therefore make sure that the installation directory is on the class path • for the batch TestRunner type:     java junit.textui.TestRunner junit.samples.AllTests • for the graphical TestRunner type:     java junit.awtui.TestRunner junit.samples.AllTests • for the Swing based graphical TestRunner type:     java junit.swingui.TestRunner junit.samples.AllTests • Important: don't install the junit.jar into the extension directory of your JDK installation. If you do so the test class on the files system will not be found.

  12. How do you write testing code? • Create an instance of TestCase: • Create a constructor which accepts a String as a parameter and passes it to the superclass. • Override the method runTest() • When you want to check a value, call assertTrue() and pass a boolean that is true if the test succeeds

  13. More Information • Test Driven.Com • JUnit CookBook • JUnit Test Infected: Programmers Love Writing Tests • From the JUnit site • Frequently asked questions

More Related