Transcript Test-driven development (TDD)

Test-driven development
(TDD)
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.
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.
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).
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.
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.
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
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
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.
The goal
Installation of JUnit
•
•
•
•
Below are the installation steps for installing JUnit:
unzip the junit.zip file
add junit.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.
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
More Information
• Test Driven.Com
• JUnit CookBook
• JUnit Test Infected: Programmers Love
Writing Tests
• From the JUnit site
– Frequently asked questions