CSC/ECE 517 Fall 2009/wiki1a 1 103: Difference between revisions
No edit summary |
|||
Line 22: | Line 22: | ||
# Every line of code should at least be executed once. | # Every line of code should at least be executed once. | ||
# Every condition in case of “conditional statements” should be met at least 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. | # 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 | # Every error message/exception handling should be tested | ||
Line 32: | Line 32: | ||
== Cases Specific to JUnit Test Cases == | == Cases Specific to JUnit Test Cases == | ||
In theory, there shouldn't be anything special regarding to effective unit testing in JUnit. A good | 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 | *A simple test | ||
: Create a class: | : Create a class: | ||
Line 99: | Line 99: | ||
# [http://www.exforsys.com/tutorials/testing/unit-testing.html Unit Testing: Why? What? & How?] | # [http://www.exforsys.com/tutorials/testing/unit-testing.html Unit Testing: Why? What? & How?] | ||
# [http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] | # [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) |
Revision as of 21:00, 12 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 { //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); } ...
- 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)