CSC/ECE 517 Fall 2009/wiki1a 1 103: Difference between revisions
Jump to navigation
Jump to search
| 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" <ref | * Design - It's "Hard to design testable code". "However, testable code often is better designed" <ref>[http://bradwilson.typepad.com/presentations/effective-unit-testing.pdf]</ref> | ||
* Documentation - Good documentation could prevent oversight, increase transparency, and facilitate knowledge transfer in the future.<ref | * Documentation - Good documentation could prevent oversight, increase transparency, and facilitate knowledge transfer in the future.<ref>[http://www.exforsys.com/tutorials/testing/unit-testing.html]</ref> | ||
* Good coverage, | * Good coverage, | ||
: What should be covered | : What should be covered | ||
| Line 28: | Line 28: | ||
# All possible setup configurations | # All possible setup configurations | ||
* Avoid redundant tests | * Avoid redundant tests | ||
* Easy for automation. | * Easy for automation. | ||
* Efficient | * Efficient | ||
Revision as of 01:00, 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>[1]</ref>
- Documentation - Good documentation could prevent oversight, increase transparency, and facilitate knowledge transfer in the future.<ref>[2]</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