DOC PREVIEW
DREXEL CS 265 - JUnit

This preview shows page 1-2-20-21 out of 21 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 21 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 21 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 21 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 21 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 21 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21JUnitA framework which provides hooks for easy testing of your Java code, as it's builtNote: The examples from these slides can be found in ~kschmidt/public_html/CS265/Labs/Java/JunitJUnit•This assumes that you've read a bit about testing; I'm not going to lecture here•The heart of this is a test case, a class which contains testsA test is a method that test methods that you've writtenThe framework is found in junit.jarOn the CS machines, currently, is located at /usr/share/java/junit.jarSome version < 4.0 as of 8/06The TestCase class•Each test case is a class you provide that extends (inherits from) TestCase•Contains:member dataspecial admin-type methods:setUp() – run before each testtearDown() – run after each testsuite() – (static), a method that, basically, lists the tests to be added to the frameworkthe testsmethods that take no argumentsoften start with or contain the string "Test" (for older versions of the framework)Example – Money class•The files for these examples can be found in:~kschmidt/public_html/CS265/Labs/Java/Junit•MoneyTest written to test class MoneyExample – extending TestCase, c'torimport junit.framework.*;public class MoneyTest extends TestCase{public MoneyTest( String name ) {super( name );}...}Example - setup•Add some Money objects to use in our tests:public class MoneyTest extends TestCase{public MoneyTest( String name ) {super( name );}private Money m12CHF;private Money m12CHF;protected void setUp() {m12CHF= new Money( 12, "CHF" );m14CHF= new Money( 14, "CHF" );}...}Adding Tests•When you implement a method, the test for that method should actually be written first•Add a corresponding "test" method to your TestCase classTakes no argumentsreturns voiduse various Assert methods to access hooks into the framework (pass/fail, logging)JUnit: Testcase & Assert•To use classes from the JUnit framework (TestCase, Assert, etc):import junit.framework.*Assert static methods•Static methods of the class Assert•All are overloaded to take an optional message (a String) as the first argumentassertTrue( boolean condition )assertFalse( boolean condition )assertEquals( expected, actual )overloaded to take any primitives, or anything derived from ObjectNote, if subtypes of Object, need to override equals()Assert methods (cont)assertNull( Object )assertNotNull( Object )assertSame( Object expected, Object actual)Checks to see that expected and actual refer to the same object (so, of course, are equal)assertNotSame( Object expected, Object actual)fail()Just dumps the testing, w/the optional msgExample – override equals()•We need to provide Money.equals():public boolean equals( Object anObject ){if( anObject instanceof Money ) {Money aMoney= (Money)anObject;returnaMoney.currency().equals( currency() )&& amount() == aMoney.amount();}return false;}Test equals•Add to MoneyTest: public void testEquals() {Money expected = new Money( 12, "CHF" );Assert.assertEquals( expected, m12CHF );Assert.assertEquals( m12CHF, m12CHF );Assert.assertNotSame( expected, m12CHF );Assert.assertFalse( m12CHF.equals( m14CHF ));Assert.assertFalse( expected.equals( m14CHF ));}Test Money.add()•Add to MoneyTest:public void testAdd() {Money expected= new Money( 26, "CHF" );Money result= m12CHF.add( m14CHF );Assert.assertEquals( expected, result );expected = new Money( 1, "CHF" );result = m12CHF.add( md13CHF );Assert.assertEquals( expected, result );result = md13CHF.add( m12CHF );Assert.assertEquals( expected, result );}Identifying tests – suite()•You've written some tests•They need to be identified to the testing framework•Override the suite() static methodCreate a TestSuite objectUse its addTest() method to add tests you want to runExample – suite()// adding each test// you can just add the tests you wantpublic static Test suite() {TestSuite suite= new TestSuite();suite.addTest( new MoneyTest( "testEquals" ));suite.addTest( new MoneyTest( "testAdd" ));return suite;}Adding all tests•You can write a suite() method that uses reflection to add all of the testXXX() methods in the TestCase class to the Suite:public static Test suite() {return new TestSuite( MoneyTest.class );}Testing your test case•As a sanity check, after writing a test or two, you might want to make a little main method for the TestCase class:public static void main( String args[] ){String[] caseName = { MoneyTest.class.getName() }; junit.textui.TestRunner.main( caseName );}This will set up and run the testsMake sure you didn't make any errors in the testing framework(Remember to add junit.jar to $CLASSPATH to run this from the command line)Hints(from Prof. Noll at Santa Clara Univ.)•Tests should be silent. Do not under any circumstances use System.out.println in any test method. Rather, use assertions. •Before you add a method to your production class, think about the pre-conditions and post-conditions for the method: what needs to be in place before the method can be called, and what is supposed to have happened after the method returns? Then, capture the pre-/post-conditions as initialization code and assertions in a unit test method: initialize the pre-conditions, call the method, assert the post-conditions. This accomplishes two things: first, it ensures that you understand what the method is supposed to do before you write it. Second, it provides a test for the method that is available as soon as the method is ready to test.*See http://www.cse.scu.edu/~jnoll/174/projects/junit.htmlHints (cont.)(from Prof. Noll at Santa Clara Univ.)•When you are tempted to put System.out.println in your production code, instead write a test method. This will help to clarify your design, and increase the coverage of your unit tests. It also prevents ``scroll blindness'', as the tests say nothing until a failure is detected. •Don't put System .out.println in your production code (see also above). If you want to do this to observe the behavior of your program, write a unit test to assert its behavior instead. If you need to print to stdou t as part of the program's functionality, pass a Prin tWriter or output stream to those methods that do printing. Then, you can easily create unit tests for those methods.Example – build.xml<target


View Full Document

DREXEL CS 265 - JUnit

Download JUnit
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view JUnit and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view JUnit 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?