CSC/ECE 517 Fall 2009/wiki1a 1 103: Difference between revisions
(Writing Effective JUnit Test Cases) |
No edit summary |
||
(12 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
Writing Effective JUnit Test Cases | ''' Writing Effective Junit Test Cases ''' | ||
This article introduces the best practice a developer should follow in writing ''JUnit'' test cases for Java programming. | |||
== Prerequisites == | |||
Readers are assumed to be familiar with the following terms/names and their concepts: | |||
[http://en.wikipedia.org/wiki/Unit_testing Unit Testing] - A verification process run by a developer on the smallest testable parts of an application. | |||
[http://en.wikipedia.org/wiki/Test_case Test case] - A process generates a set of conditions and variables by which a developer can tell if a piece of software works correctly. | |||
[http://en.wikipedia.org/wiki/JUnit JUnit] - A unit testing framework for programming in Java. | |||
== Criteria For Effective Unit Testing == | |||
* Design - It's "Hard to design testable code". "However, testable code often is better designed" [http://bradwilson.typepad.com/presentations/effective-unit-testing.pdf [1]] | |||
* Documentation - Good documentation could prevent oversight, increase transparency, and facilitate knowledge transfer in the future.[http://www.exforsys.com/tutorials/testing/unit-testing.html [2]] | |||
* Good coverage, | |||
: What should be covered in each run of the test: | |||
# UI - All screen elements, spelling, fonts, and sizes of all the “labels” or text. May not be applicable to JUnit since automation may be improbable here. | |||
# Every line of code should at least be executed once. | |||
# Every condition in case of “conditional statements” should be met at least once. | |||
# Every path of all possible ones should be gone through at least once. | |||
# Boundaries - The input parameters should be tested with conditions at the lower and/or upper limits such as too large or too small. Overflow condition should also be tested. | |||
# Every error message/exception handling should be tested | |||
# All validations are being performed, correctly. | |||
# All possible setup configurations should be tested. | |||
* Avoid redundant tests which may give wrong impression of the scale of the bugs and fixes. | |||
* Easy for automation, which should be implied by JUnit. | |||
== Cases Specific to JUnit Test Cases == | |||
In theory, there shouldn't be anything special regarding to effective unit testing in JUnit compared to any other testing framework. A couple of good resources for designing tests specific in JUnit is the [http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ], and the book "Pragmatic Unit Testing in Java with JUnit". | |||
*A simple test | |||
: Create a class: | |||
<pre> | |||
package myPackageToBeTested; | |||
import org.junit.*; | |||
import static org.junit.Assert.*; | |||
import java.util.*; | |||
public class SimpleTest { | |||
//constructor | |||
public SimpleTest(String name) { | |||
super(name); | |||
} | |||
//a test method (annotated with @Test) using asserts: | |||
@Test | |||
public void test1plus1() { | |||
assertEquals("1+1=2", 2, 1+1); | |||
} | |||
} | |||
</pre> | |||
* A test suite | |||
: Add a suite() method to the above ''simple test'' example to include all of your test methods: | |||
<pre> | |||
//... | |||
public static junit.framework.Test suite() { | |||
return new junit.framework.JUnit4TestAdapter(SimpleTest.class); | |||
} | |||
//... | |||
//or | |||
//... | |||
public static Test suite() { | |||
TestSuite suite = new TestSuite(); | |||
suite.addTest( | |||
new SimpleTest("ShortTest")); | |||
return suite; | |||
} | |||
//... | |||
</pre> | |||
* A test template | |||
: This sample test template contains setUp() and tearDown() methods to initialize and release the object(s) being tested | |||
<pre> | |||
import org.junit.*; | |||
import static org.junit.Assert.*; | |||
public class TemplateTest { | |||
// Sets up the test fixture. | |||
@Before | |||
public void setUp() { | |||
} | |||
//Tears down the test fixture. | |||
@After | |||
public void tearDown() { | |||
} | |||
//a test method (annotated with @Test) using asserts: | |||
@Test | |||
public void test1plus1() { | |||
assertEquals("1+1=2", 2, 1+1); | |||
} | |||
public static junit.framework.Test suite() { | |||
return new junit.framework.JUnit4TestAdapter(TemplateTest.class); | |||
} | |||
} | |||
</pre> | |||
== References == | |||
# [http://bradwilson.typepad.com/presentations/effective-unit-testing.pdf effective unit testing] | |||
# [http://www.exforsys.com/tutorials/testing/unit-testing.html Unit Testing: Why? What? & How?] | |||
# [http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] | |||
# White Box Testing Techniques - NCSU:CSC 510 Software Engineering (Lecture 8) | |||
# Pragmatic Unit Testing in Java with JUnit (ISBN:9780974514017) |
Latest revision as of 18:49, 14 September 2009
Writing Effective Junit Test Cases
This article introduces the best practice a developer should follow in writing JUnit test cases for Java programming.
Prerequisites
Readers are assumed to be familiar with the following terms/names and their concepts:
Unit Testing - A verification process run by a developer on the smallest testable parts of an application.
Test case - A process generates a set of conditions and variables by which a developer can tell if a piece of software works correctly.
JUnit - A unit testing framework for programming in Java.
Criteria For Effective Unit Testing
- Design - It's "Hard to design testable code". "However, testable code often is better designed" [1]
- Documentation - Good documentation could prevent oversight, increase transparency, and facilitate knowledge transfer in the future.[2]
- Good coverage,
- What should be covered in each run of the test:
- UI - All screen elements, spelling, fonts, and sizes of all the “labels” or text. May not be applicable to JUnit since automation may be improbable here.
- Every line of code should at least be executed once.
- Every condition in case of “conditional statements” should be met at least once.
- Every path of all possible ones should be gone through at least once.
- Boundaries - The input parameters should be tested with conditions at the lower and/or upper limits such as too large or too small. Overflow condition should also be tested.
- Every error message/exception handling should be tested
- All validations are being performed, correctly.
- All possible setup configurations should be tested.
- Avoid redundant tests which may give wrong impression of the scale of the bugs and fixes.
- Easy for automation, which should be implied by JUnit.
Cases Specific to JUnit Test Cases
In theory, there shouldn't be anything special regarding to effective unit testing in JUnit compared to any other testing framework. A couple of good resources for designing tests specific in JUnit is the JUnit FAQ, and the book "Pragmatic Unit Testing in Java with JUnit".
- A simple test
- Create a class:
package myPackageToBeTested; import org.junit.*; import static org.junit.Assert.*; import java.util.*; public class SimpleTest { //constructor public SimpleTest(String name) { super(name); } //a test method (annotated with @Test) using asserts: @Test public void test1plus1() { assertEquals("1+1=2", 2, 1+1); } }
- A test suite
- Add a suite() method to the above simple test example to include all of your test methods:
//... public static junit.framework.Test suite() { return new junit.framework.JUnit4TestAdapter(SimpleTest.class); } //... //or //... public static Test suite() { TestSuite suite = new TestSuite(); suite.addTest( new SimpleTest("ShortTest")); return suite; } //...
- A test template
- This sample test template contains setUp() and tearDown() methods to initialize and release the object(s) being tested
import org.junit.*; import static org.junit.Assert.*; public class TemplateTest { // Sets up the test fixture. @Before public void setUp() { } //Tears down the test fixture. @After public void tearDown() { } //a test method (annotated with @Test) using asserts: @Test public void test1plus1() { assertEquals("1+1=2", 2, 1+1); } public static junit.framework.Test suite() { return new junit.framework.JUnit4TestAdapter(TemplateTest.class); } }
References
- effective unit testing
- Unit Testing: Why? What? & How?
- JUnit FAQ
- White Box Testing Techniques - NCSU:CSC 510 Software Engineering (Lecture 8)
- Pragmatic Unit Testing in Java with JUnit (ISBN:9780974514017)