CSC/ECE 517 Fall 2009/wiki1a 1 103: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
Line 15: | Line 15: | ||
== Criteria For Effective Unit Testing == | == Criteria For Effective Unit Testing == | ||
* Design - It's "Hard to design testable code". "However, testable code often is better designed" | * 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. | * 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, | * Good coverage, | ||
: What should be covered | : What should be covered in each run of the test: | ||
# UI | # 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. | ||
# Cyclomatic number | # Cyclomatic number, or the number of all possible paths should be through at least once. | ||
# Boundaries | # 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 | # Every error message/exception handling should be tested | ||
# All validations are being performed | # All validations are being performed, correctly. | ||
# All possible setup configurations | # All possible setup configurations should be tested. | ||
* Avoid redundant tests | * Avoid redundant tests which may give wrong impression of the scale of the bugs and fixes. | ||
* Easy for automation. | * 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. A good resource for designing tests in JUnit is the [http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ]. | |||
*A simple test | |||
: Create a class: | |||
<pre> | |||
package junitfaq; | |||
import org.junit.*; | |||
import static org.junit.Assert.*; | |||
import java.util.*; | |||
public class SimpleTest { | |||
//a test method (annotated with @Test) using asserts: | |||
@Test | |||
public void test1plus1() { | |||
assertTrue("1+1=2", 1+1, 2); | |||
} | |||
} | |||
</pre> | |||
* A test suite | |||
: Add a suite() method to the above example: | |||
<pre> | |||
public static junit.framework.Test suite() { | |||
return new junit.framework.JUnit4TestAdapter(SimpleTest.class); | |||
} | |||
</pre> | |||
== References == | == 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] |
Revision as of 02:25, 9 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.
- Cyclomatic number, or the number of all possible paths should be 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. A good resource for designing tests in JUnit is the JUnit FAQ.
- A simple test
- Create a class:
package junitfaq; import org.junit.*; import static org.junit.Assert.*; import java.util.*; public class SimpleTest { //a test method (annotated with @Test) using asserts: @Test public void test1plus1() { assertTrue("1+1=2", 1+1, 2); } }
- A test suite
- Add a suite() method to the above example:
public static junit.framework.Test suite() { return new junit.framework.JUnit4TestAdapter(SimpleTest.class); }