Unit Testing & Code Coverage
Please download and install EclEmma (link in
resources section…I recommend Option 2)
Also snarf the junit code for today’s class
Please be aware…
• There are readings posted for Thursday and
Friday
What Are Unit Tests?
• Small tests that test a particular small part of
your code separate from everything else
• Contrast with integration tests that test how
large parts of the system work together
Why Unit Test?
• They let you verify your code functions
properly under a variety of circumstances
• They protect against “regressions” – when a
feature you had previously implemented
breaks
• They improve the design of your code by
encouraging you to make the various parts of
the system independent from each other
When rules are complex, you NEED
unit testing
1. Scientific computing
2. Board game
3. Any situation where you can’t eyeball results
and know if they are correct
It is really important to decouple unit
tests from other parts of the system
If you tests break frequently for
unrelated stuff, that’s a sign you have
built you tests incorrectly
Generate as many different test cases
as you can for….
Name Parsing e.g. (parse “Mr. Michael Hewner”). We want to parse a
name string into parts. The parts we care about are:
• Title (i.e. "Mr")
• First Name (i.e. "John")
• Last Name (i.e. "Smith")
• Suffix (blank in sample case, could be Jr, II, PhD, DDS, etc)
The rules of parsing are:
• The words have the strict order – the Title, the First Name, Last Name
and the Suffix. A word can contain a hyphen.
• If the name contains only one word, it is treated as the Last Name.
• If the name contains two words and the first word is a title, the second
word is treated as the Last Name.
• If the name contains two or more words and the first word is not a
title, the first two words are treated as the First Name and the Last
Name. If the word is in the title list, it is treated as the title. If not the
Title remains empty.
There is a unit test framework for your
language – use it
• You want your unit tests to be super easy to
run – that way they will be run
• Ideally, you might do stuff like run them every
night or run them everytime somebody checks
something into source control
Use Junit to test the NameParser
(snarfable)
• Implement as many good tests as you can
• As you find bugs (there are a lot) fix the code and
rerun all your old tests
• Be sure to write some tests that verify the
exceptions are correctly thrown when bad input
is given
• Junit documentation:
• http://junit.sourceforge.net/doc/cookbook/cook
book.htm
• http://www.eclemma.org
Code Coverage Tools
• Tells you what percentage of your code is unit
tested
• Easy, and a great way to spot check to make sure
you’re not leaving some vast area untested
• Your goal is not to get to 100% coverage, but you
should be around 95% or more
if(worldMakesNoSense == true) {
throw new RuntimeException(“I have
no idea what’s going on”);
}
Run Code Coverage on Your Tests
• You’ll need to download and install EclEmma
(http://www.eclemma.org...I like installation
option 2)
• Run code coverage on your tests
• If you code coverage is not at 100%, get it
there
• Submit your code via ambient when you are
done
GUIs
• It is not usually worth it to unit test GUIs
directly (because they tend to change
frequently due to UI issues)
• BUT…what that means is you want to pull all
possible code out of the view and into the
model so it can be unit tested
Unit Tests vs. Integration Tests
No mans land of bad tests that break frequently
Sweet Spot 1:
Really simple “unit”
tests that just test
one small
subsystem away
from everything
else
Sweet Spot 2:
Large tests that test
everything end-toend and verify your
whole system does
what it’s intended
to do
Automated Testing Systems
• There are systems that will “monkey” through
and interface and press every button or every
link