The grade will primarily depend on the process to develop test cases.
High marks will be given to test suite that are developed following
a methodic process.
An automatic C (or less) is triggered by
• Any routine with complexity greater than 4,
• Any substantially repeated piece of code, or by
• Improperly named routines.
However, a submission that avoids these problems does not
necessarily qualify for high quality craftsmanship.
Starting with programming assignment 10, points will be deducted
if code or branch coverage is incomplete.
First, make all changes discussed during last week’s code review.
In this assignment, you will design, write, and run test cases in JUnit.
The emphasis is on a methodic and coherent process to develop and
implement test cases. You should avoid developing a test suite in a
generic and haphazard manner. Although it is very tempting to develop
test cases by error guessing, a methodic process has been discussed
in the lectures and reading assignments and should be followed
starting from this assignment. An example is given on canvas under
Modules, Labelled Test Cases, TestDevelopment.pdf.
For each method, the test cases have to exhaust the typology
described in Section 22.3 (not all categories are applicable to all
• Code coverage
• Branch coverage
• Data-ﬂow (extra credit)
• Compound boundaries
• Bad data
• Good data
First, create a separate test design document. The design document
should be modeled after the test development example in canvas.
For each method, deﬁne
• Test conditions: each with an identiﬁer, goal, notes, and
conditions (Section “Conditions” in the canvas example.)
• Tests: each with an identiﬁer, identiﬁers of the satisﬁed
conditions, and assertions (Section “Tests” in the canvas
You can omit tests for methods that are automatically generated
(such as some constructors, getters, setters, equals, toString, or
Additionally, describe at least one stress test for the whole code base
(Section “Stress Test” in the canvas example and in Code Complete).
Second, implement the tests. Add a comment to each test to cross-
reference it with the test design document. The test cases that you
have developed for assignments 6 and 7 should be included and
cross-referenced as “good data (legacy)”.
All methods must be tested individually. All protected and private
methods must be tested individually. In other words, you cannot test
a private or protected method solely by invoking the public methods
that call it. Instead, you need to write test cases that invoke the
private or protected method through a nested test hook. An example
is in the testexample repository that you cloned in assignment 7. You
cannot use reﬂection to test private and protected methods.
If you plan to skip testing of an automatically generated method, you
should have your IDE generate the method’s documentation
Your build environment (build.xml or Makeﬁle) should contain the
• “test” target should run all the test cases.
• “report” target should generate a html Junit and JaCoCo
report for the test cases.
During discussion, your leader should be able to run the tests and
display the reports.
本网站支持淘宝 支付宝 微信支付 paypal等等交易。如果不放心可以用淘宝交易！
E-mail: firstname.lastname@example.org 微信:itcsdx