CSC 309 Milestone 5

Completed Design, Implementation, and Testing
Final Presentation

• Code Reviews: 11:59PM Wednesday 3 June
• Final Project: on or before 11:59PM Thursday 11 June

Design and Implementation:

1. Project design and implementation completed, per the specs and any released SCOs.

2. Completed design documentation, per the design/implementation conventions.

Testing:

1. For each team member, write class test plans for two more model or process classes, in addition to the two classes for which tests were written in Milestone 4. This means each team member will have a total of four class test plans by the delivery of the final project. Note: if one or more team members has fewer than four classes, we will adjust deliverable requirements accordingly.

2. For each team member, unit tests for four more model or process methods, in addition to the eight methods for which tests were written in Milestone 4. This means each team member will have a total of twelve unit tests by the delivery of the final project.

3. Perform code reviews.

   1. Code reviews involve the inspection by colleagues of one another's code.

   2. Each team member will review the code of another fellow team member. It can be helpful if the code being reviewed is related to that being done by the reviewer, but that is not required.

   3. The review is performed for each class, and for each method within each class.

   4. The following are the specific standards that must be met for each class:

      1. follows the 309 design and implementation conventions

      2. compiles and executes properly, where "properly" means it uses actual model data as described above

   5. The following are the specific standards that must be met for each method:

      1. follows the 309 design and implementation conventions, in particular the javadoc commenting and 50-line rule

      2. for the six methods chosen by the team member, the pre- and postconditions are provided and compile with the JML checker

   6. The code review report takes the following form:

      Class X: Review Remarks
      Method X.m₁: Review Remarks

      . . .

      Method X.m_n: Review Remarks
      
      Class Y: Review Remarks
      Method Y.m₁: Review Remarks

      . . .

      Method Y.m_n: Review Remarks

      where Review Remarks are either the description "Meets all standards" or an itemized description of the standards that are not met.

4. For each team member, write one or more acceptance test plans containing twelve significant test cases. See the acceptance test handout for details on the format of an acceptance test plan.

Administration:

1. Updated HOW-TO-RUN.html

2. Updated HOW-TO-RUN-TESTS.html.

3. Updated work-breakdown.html that defines clearly the duties for each team member, in all aspects of the project

Presentation:

1. For the week 10 lab, each team will present project results

2. Organize your presentations along the following lines:

   1. Focus the discussion on a demonstration of the most interesting features of your product.

   2. Also discuss any particularly noteworthy aspects of project design, implementation, and testing.

3. The Week 10 presentation schedule is as follows:
   
   

   Day	Time	Team
   Mon	3:10 - 3:34	Token CSC
   	3:36 - 4:00	Team 1
   Wed	3:10 - 3:34	Team 0
   	3:36 - 4:00	DJ Cars
   Fri	3:10 - 3:34	FBRD
   	3:36 - 4:00	Node

Code-Level Testing:

To recap from previous milestones, the specific deliverables for code testing are the following:

1. class-level test plans, as javadoc comments for the testing classes

2. preconditions and postconditions, as javadoc comments for the methods being tested

3. unit tests plans, as javadoc comments for the testing methods

4. unit test implementation, in the bodies of the testing methods

5. test execution, using the testing framework chosen by your team

As noted in previous milestone writeups, the class and unit testing work of each team member should ideally be for the classes assigned to that member in the team's work breakdown. In some cases, it may be appropriate or necessary to have a team member write specifications and tests for the work designed and implemented by another member. We will continue to clarify the specifics of such cases in our lab meetings.

The requirements of four classes and twelve unit-testing methods per team member may be reduced in some cases, for example when the specification and testing of some methods is particularly complex. Alternatively, there can be double testing, where unit tests are written independently by two separate team members. Again, we will clarify details in our lab meetings.

Code Coverage:

Each team member is responsible for 100% branch coverage on the twelve methods for which the team member writes unit tests. Note well that this does not mean 100% coverage for the entire project, only on the methods for which unit tests are written.

The coverage tool you use must be stated in HOW-TO-RUN-TESTS.

Acceptance Testing:

The specific deliverables for acceptance testing are the following:

1. Per team member, a subdirectory under your- project/testing/acceptance that corresponds to an area of user- level functionality to be tested.

2. One or more HTML files per team member, containing the acceptance test plan(s) and record(s) for which that team member is responsible.

An "area of user-level functionality" is defined as a cohesive collection of user commands that perform some particular task. These trace all the way back the requirements, where user-level functionality was originally organized into coherent parts of the HCI. The most typical areas of functionality in 309 projects are menus, tool bars, or other well-delineated components of the UI.

Note that the assignment of twelve acceptance test cases per team member is an entirely practical matter, given the limited time available in a class. For a production-quality project, the number of test cases would be based on testing principles comparable to those for unit testing, including the systematic testing of input constraints, and ranges of user input data.

For 309, your limited form of acceptance testing will be evaluated in terms of how "significant" your test cases are, where criteria for significance are:

1. The user command(s) you test do something useful.

2. The inputs you provide test a reasonable range of user input data.

Testing Coverage:

You must achieve 100% branch coverage for all unit tested code. Methods for which you do not write unit tests, if any, are not included in the testing coverage requirement.