CSC/ECE 517 Fall 2009/wiki1a 1 103: Difference between revisions
Jump to navigation
Jump to search
(structure) |
|||
| Line 1: | Line 1: | ||
''' Writing Effective Junit Test Cases ''' | |||
This article introduces the best practice a developer should follow in writing ''JUnit'' test cases for Java programming. | |||
== Prerequisites == | == Prerequisites == | ||
Readers are assumed to be familiar with the following terms/names and their concepts: | |||
[http://en.wikipedia.org/wiki/Unit_testing Unit Testing] | [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] | [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] | [http://en.wikipedia.org/wiki/JUnit JUnit] - A unit testing framework for programming in Java. | ||
== 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" <ref name="Wilson">[http://bradwilson.typepad.com/presentations/effective-unit-testing.pdf "effective unit testing"], Wilson & Densmore.</ref> | ||
* Documentation - Good documentation could prevent oversight, increase transparency, and facilitate knowledge transfer in the future.<ref name="UnitTestingWWW">[http://www.exforsys.com/tutorials/testing/unit-testing.html "Unit Testing: Why? What? & How?"], Wilson & Densmore.</ref> | |||
* Good coverage, | |||
: What should be covered | |||
# UI all the screen elements, spelling/font/size of all the “labels” or text (automation?) | |||
# every line of code, | |||
# every condition in case of “conditional statements” | |||
# Cyclomatic number (decision/branch/path) | |||
# Boundaries (too large, too small, overflow) | |||
# Every error message/exception handling (overflow?) | |||
# All validations are being performed (incorrect input) | |||
# All possible setup configurations | |||
* Avoid redundant tests | |||
* Easy for automation. | |||
* Efficient | |||
== | == Rules Specific to JUnit Test Cases == | ||
== References == | == References == | ||
{{Reflist}} | |||
Revision as of 00:42, 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" <ref name="Wilson">"effective unit testing", Wilson & Densmore.</ref>
- Documentation - Good documentation could prevent oversight, increase transparency, and facilitate knowledge transfer in the future.<ref name="UnitTestingWWW">"Unit Testing: Why? What? & How?", Wilson & Densmore.</ref>
- Good coverage,
- What should be covered
- UI all the screen elements, spelling/font/size of all the “labels” or text (automation?)
- every line of code,
- every condition in case of “conditional statements”
- Cyclomatic number (decision/branch/path)
- Boundaries (too large, too small, overflow)
- Every error message/exception handling (overflow?)
- All validations are being performed (incorrect input)
- All possible setup configurations
- Avoid redundant tests
- Easy for automation.
- Efficient