JUnit: A Comprehensive Guide for Writing Unit Tests in Java, Slides of Computer Science

Download JUnit: A Comprehensive Guide for Writing Unit Tests in Java and more Slides Computer Science in PDF only on Docsity!

JUnit, Revisited

JUnit

• JUnit is a framework for writing unit tests
  • A unit test is a test of a single class
    • A test case is a single test of a single method
    • A test suite is a collection of test cases
• Unit testing is particularly important when software

requirements change frequently

• Code often has to be refactored to incorporate the changes
• Unit testing helps ensure that the refactored code continues to work
• JUnit helps the programmer:
• define and execute tests and test suites
• formalize requirements and clarify architecture
• write and debug code
• integrate code and always be ready to release a working version

Test classes in BlueJ

The class to

be tested

The class

to test it

The menu you

get when you

right-click the

test class

Use these

to create

tests

Use these

to run tests

Creating a test class in BlueJ

• If you have an existing class, right-click on it and

choose Create Test Class

• If your class is named MyClass, the new test class will be named MyClassTest

• To create the test class first, just choose New

Class... and give the test class the name of a

future class, with ‘Test’ appended

• Later, after you create the class to be tested,you can right-click it and choose Create Test Class - BlueJ will complain that the class already exists, but it will

also correctly associate the test class with the class to be

tested

Implementing the tearDown() method

• In most cases, the tearDown() method

doesn’t need to do anything

• The next time you run setUp(), your objects will be replaced, and the old objects will be available for garbage collection
• It doesn’t hurt to set to null the objects you created in setUp()
• Like the finally clause in a try-catch-finally statement, tearDown() is where you would release system resources (such as streams) that might not otherwise be released

Recording test cases

• An easy way to create a test method is to right-click a compiled test

class and choose Create Test Method...

• Enter the name of the method you want to test; you don’t have to say “test” - BlueJ will capitalize your method name and prefix it with test
• If you wish, you can copy Test Fixture To Object Bench
• Use BlueJ to make calls to the method
  • After each call, BlueJ will tell you its result, and ask you to type in the result you expected - The result can be equal to, the same as, not the same as, null, not null, or equal to (double or float)
  • You can even create a new object to use as a result
• When you are done click the End button (under Recording)
• Review the results!
• This is a new feature in BlueJ, and sometimes it produces bad syntax
• A comma in your expected result will confuse BlueJ 1.3.

assert X methods

• static void assertTrue(boolean test )
• static void assertFalse(boolean test )
• assertEquals( expected , actual )
• assertSame(Object expected , Object actual )
• assertNotSame(Object expected , Object actual )
• assertNull(Object object )
• assertNotNull(Object object )
• fail()
• All the above may take an optional String message as the

first argument, for example,

static void assertTrue(String message , boolean test )

Example: Counter class

• For the sake of example, we will create and test a trivial

“counter” class

• The constructor will create a counter and set it to zero
• The increment method will add one to the counter and return the new value
• The decrement method will subtract one from the counter and return the new value
• We write the test methods before we write the code
• This has the advantages described earlier
• Depending on the JUnit tool we use, we may have to create the class first, and we may have to populate it with stubs (methods with empty bodies)
• Don’t be alarmed if, in this simple example, the JUnit tests are

more code than the class itself

The Counter class itself

public class Counter { int count = 0;

public int increment() { return ++count; }

public int decrement() { return --count; }

public int getCount() { return count; } }

• Is JUnit testing overkill for this little class?
• The Extreme Programming view is: If it isn’t tested, assume it doesn’t work
• You are not likely to have many classes this trivial in a real program, so writing JUnit tests for those few trivial classes is no big deal
• Often even XP programmers don’t bother writing tests for simple getter methods such as getCount()
• We only used assertTrue in this example, but there are additional assert methods

Viewing test results

If you run a single test, and it is successful, you just get a

message in the status line

Failed tests

Unexpected errors and exceptions

The GUI problem

• The whole point of JUnit is to make testing easy

• You click a button, and all your tests “just happen”

• To test a GUI, you have to sit there and interact with

the GUI-- not good!

• You can “automate” GUI use by “faking” events

• Here’s a starter method for creating your own events:
  • public void fakeAction(Component c) {

getToolkit().getSystemEventQueue().postEvent(

new ActionEvent(c,

ActionEvent.ACTION_PERFORMED, "")); }

• You can explore the Java API to discover how to create other kinds of events

The printing problem

• If a method does output to the screen or to a file, you want to

make sure the output is correct

• Again, you want to set this up once, and forever after have it all done automatically
• How can you capture output?
• Rather than always printing on System.out, you can do your printing on an arbitrary PrintStream
• The PrintStream can be passed into methods as a parameter
• Alternatively, you can redefine System.out to use a different PrintStream with System.setOut( PrintStream )
• A Java PipedOutputStream can be connected directly to a PipedInputStream; this might be helpful
• Whatever you do, you would like to minimize the effect on the

program you are trying to test