Transcript Testing
Testing
26-Jul-16
What testing is for
The point of testing is to determine whether software
does what it is supposed to do
Testing also helps you discover where your error are
Scenario: Your company is being sued because some
control software it wrote caused a fatal accident
In this way it can greatly facilitate debugging
Someone will be facing a long jail term
Are your JUnit tests good enough to stand up in court?
So far programmers have not been held criminally
liable for dangerously poor quality code
Sooner or later, this will change
The Extreme Programming view
“If it isn’t tested, it’s assumed not to work”
Extreme Programming also says you should write the
tests before writing the code
Reason: This helps clarify for you what the code is supposed
to do
Next you run the tests
They fail, of course, because the code hasn’t been written
Then you fix the failures, one at a time
This is helpful in another way—if you come back to the code much
later, the tests tell you exactly where to get started again
Of course, you can’t run the tests unless the methods exist—
but they can be stubs
Writing tests first in Eclipse
First, write the stubs
class Token {
public Token(String value, int type) { }
public String getValue() { return null; }
public int getType() { return 0; }
public boolean equals(Object o) { return false; }
}
Then in Eclipse, select the class and do
File New Other... Java/JUnit TestCase
Select all the methods you want to create tests for
Eclipse generates all the test stubs for you
Testing the boundaries
You should test not only the most common cases, but
the cases “around the edges,” where things are most
likely to go wrong
You’re the programmer—you should have a feel for where the
special cases are likely to be
An example
public void testHasNext() {
tokenizer = new Tokenizer("hello");
assertTrue(tokenizer.hasNext());
}
Is this a good test?
Does hasNext() ever return false?
Does it return true after you get the "hello" token?
It should, if you read the assignment!
Does it return false after you get the next token, which should be
the EOI (end of input) token?
It should do this, too
Is this a better test?
public void testHasNext() {
Tokenizer tokenizer = new Tokenizer("one two three");
assertTrue(tokenizer.hasNext());
while (tokenizer.hasNext()) {
Token token = tokenizer.next();
}
assertFalse(tokenizer.hasNext());
}
Why not?
Reminder: JUnit Assert methods
assertTrue(boolean test)
assertFalse(boolean test)
assertEquals(expected, actual)
assertSame(Object expected, Object actual)
assertNotSame(Object expected, Object actual)
assertNull(Object object)
assertNotNull(Object object)
fail()
Notice the order of expected and actual
All of these can take a String as an optional first argument
Comments
The first assignment was about using Eclipse and
JUnit
Proper testing is a significant component of your grade
The emphasis on JUnit testing will continue in the
following assignments
Your knowledge of JUnit and Eclipse will be tested on
the first quiz
The End