CS340: Adv' SW Dev' Unit Testing with JUnit

1
CS340 Adv. SW Dev.Unit Testing with JUnit

• Credits
• Pragmatic Unit Testing, by Andrew Hunt and David
  Thomas

2
Recommended Readings

• http//en.wikipedia.org/wiki/Test-driven_developme
  nt
• Chapter on JUnit and Eclipse from Eclipse Kick
  Start (handed out in lab)
• Standard tutorial on JUnithttp//junit.sourcefor
  ge.net/doc/testinfected/testing.htm
• JUnit site http//www.junit.org/(Now lots of
  info on JUnit 4. These slides use JUnit 3.)

3
Why Unit Test?

• Of course its good to do
• So is eating spinach
• Bottom line Gives you confidence your code does
  what you think it does
• Without this, where are you?
• What it doesnt do
• Right thing for customer? Not acceptance testing
• All system components work together correctly and
  well? Not integration or performance testing

4
Confidence in Your Code

• Generally, are you confident in code you write?
• If so, what justifies this?
• If your code doesnt do what you think it does,
  then why do further testing from there?
• Confidence and other benefits
• Allows you to do whats next knowing what youve
  done is OK
• Allows you to make changes
• Avoids a growing house of cards
• Documents your intentions to others
• Gives you a more satisfying experience

5
Steps when Unit Testing

• Decide how to test a method and write them
• Before (maybe while) writing code itself
• Forces you to understand what you're building
• Run the test yourself together with all other
  tests
• You run them, not someone else
• This test and all others must pass together
• Do not add features until all tests pass!

6
Unit Testing in TDD

• Motto Clean code that works. (Ron Jeffries)
• Unit testing has broader goals that just
  insuring quality
• Improve developers lives (coping, confidence)
• Support design flexibility and change
• Allow iterative development with working code
  early

7
Red/Green/Refactor

• The TDD mantra of how to code
• Red write a little test that doesnt work,
  perhaps even doesnt compile
• Green Write code to make the test work quickly
  (perhaps not the best code)
• Refactor Eliminate duplication and other
  problems that you did to just make the test work

8
JUnits Approach

• Fundamentally, tests based on methods
• Good starting point! (Not sufficient)
• JUnit provides
• A family of assert methods
• Methods you can run before/after each test and
  before/after the test-suite
• A framework and environment to make testing easy
  and rewarding
• Eclipse makes it even easier

9
Naming Conventions

• For a class named Foo, a testcase class called
  TestFoo is created
• For each method Foo.bar(), a test method called
  TestFoo.testBar() will be created
• You can have additional methods in TestFoo that
  also test the Foo.bar() method
• Normally all methods in TestFoo class that begin
  with test will be run
• Java reflection in action
• Test coded but not ready? Rename it
  pendingTestTheMethod()

10
You Have To

• Your test code must
• Set up whats needed for testing
• Create objects, allocate resources, create
  relationships, etc.
• Call the method to be tested
• Verify that the method did what you expected
• Clean up
• (Later see setUp and tearDown)

11
JUnit Asserts

• Assertion functions that work within the JUnit
  framework
• assertEquals(message, expected, actual)
• Uses the equals() method for the class of
  expected and actual
• Works on native types too, and
• When comparing doubles, use a 4th parameter as a
  tolerance

12
JUnit Asserts (2)

• assertNull ( Msg, object )
• assertNotNull ( Msg, object )
• assertSame ( Msg, expected, actual )
• assertNotSame ( Msg, expected, actual )
• Question how different that assetEquals() ?

13
JUnit Asserts (3)

• assertTrue ( Msg, boolean-condition )
• assertFalse ( Msg, boolean-condition )
• fail ( Msg )
• Used for sections of code that shouldnt be
  reached

14
Overview of a TestCase Class

• Code looks like this
• import junit.framework.
• public class TestSimple extends TestCase
• // need this constructor for suites etc. later
• public TestSimple(String name) super(name)
• public void testAdd() / code for testAdd /
  
• // Other method tests. Start with test,
  theyll be run

15
SetUp and TearDown

• Tests should be independent
• Able to run in any order
• Need to set-up something? Re-set?
• TestCase base class has two methods you can
  override protected void setUp()
  protected void tearDown()
• Use setUp for common text fixture
• Reminder called before and after each test!

16
Execution Order

• oneTimeSetUp() // need to know about suites
• setUp()
• testMethod1()
• tearDown()
• setUp()
• testMethod2()
• tearDown()
• oneTimeTearDown() // about suites

17
Exceptions and Testing

• We might want to test that an exception occurs
  when we expect it to.
• How to do this in JUnit?
• public void testForException
• try
• sortMyList(null) // should throw
  exception
• fail ( Should throw exception on null
  list)
• catch (RunTimeException e)
• assertTrue(true) // documents this is
  what we want

18
Exceptions and Testing (2)

• Should use method above to test for all expected
  exceptions
• But, what about unexpected things?
• Just define test method so that it throws
  possible exceptions
• JUnit will catch these and give you useful output
• public void testData1() throws FileNotFoundExcepti
  on
• FileInputStream in new FileInputStream(dat.t
  xt)

19
Extending TestCase Yourself

• You might need your own code for all your tests
• Some common classes, actions, your own clever
  assert-like methods
• Common approach for your project, create your
  own base-class which extends TestCase
• All your test-case classes will now extend your
  new base-class

20
Extending TestCase Yourself (2)

• Create new base-class for your project
• public class ProjectTest extends TestCase //
  here put new methods etc.
• All test-classes in your project begin
• public class TestMyClass extends ProjectTest

21
More Advanced

• Test suites
• Test composition
• Controlling what tests are run
• Read about test-suites on-line

22
Making Good Tests

• And, now we know the mechanics, but what makes
  good unit tests?
• Apply what you know about good test-cases
• Well talk about this more on this elsewhere in
  the class