Revised 6 May

1. Determine the testing framework your team will use.

   1. Your team can use JUnit , TestNG , or some other comparable framework. Note that if you're using Java for project development, Junit4 is the default framework, since that's what Spest generates. Junit4 tests are compatible with TestNG, so you can use that framework with Spest-generated tests.

      As a team, you need to work out how precisely your team will implement and deploy the tests. We will discuss in labs during weeks 5 and 6.

   2. For reference, there Makefile-based framework described in the 309 notes and examples. Typcially test generation is mangaged at by an IDE. If you use the Makefile scheme, confirm that the testing directory infrastructure is properly set up, and define the Makefile targets for each team member.

   3. The requirements for any testing framework are these:
      • It must support method/function-level unit testing.
      • It must support class-level inter-method testing.
      • It must support (sub)system-level integration testing.
      • It must support regression testing.

2. Determine the code coverage tool your team will use.

   1. For Java, I like Cobertura, there's also JaCoCo, and others.

   2. For Python, there's coverage 3.7.1 which appears to be the standard these days.

   3. The requirements for any code coverage tool are these:
      • it must run in conjunction with the testing framework your team has chosen to use
      • it must report both line coverage and decision coverage ¹ in the report that it generates

3. Update the integration test plan for the entire team, based on the evolution of the design and development of the project. Put the plan here:

   testing/implementation/source/java/your- tool/integration-test-plan.html

4. Complete the class test plans for all model and process classes assigned to each each individual team member.

5. Complete Spest specs for all methods in all model and process classes assigned to each individual team member.

6. For the Java teams, use Spest to generate unit tests for all the project methods.

7. For the non-Java teams, write unit tests for four to six methods per team member, with the exact number of methods to be determined in lab meetings of weeks 6 and 7 .

8. Run the coverage tool on your unit testing results and see what they look like. Almost certainly you'll not achieve 100% coverage yet.

1. Model class data representations and method implementation.

   1. Continue to refine data representations for all model and process classes, i.e., the definition of class data fields that define how class data are represented.

   2. Approximately 75% of model/process class methods must be operationally implemented.

      1. This percentage will vary based on the complexity of the methods for individual team members.

      2. We will determine specific team member responsibilities in lab meetings.

   3. As necessary, continue to use testing stubs to support model/process classes, where underlying process classes are not yet completed.

   4. All packages, classes, methods, and data fields must have javadoc-visible descriptions, as described in the design and implementation conventions.

   5. The javadoc-generated .html files for the classes must be in the design/javadoc directory.

2. Continued work on view classes.

   1. Approximately 75% of view classes must be operational, in conjunction with the 75% of the operational model/process classes.

      1. This percentage will vary based on the complexity of the methods for individual team members.

      2. We will determine specific team member responsibilities in lab meetings.

   2. As necessary, provide hand-built model/process testing data, where underlying process classes are not yet completed.

   3. All classes, methods, and data fields must have javadoc-visible descriptions, as described in the design and implementation conventions.

3. Enhanced package-level and class-level design documentation.

   1. As discussed in Notes Week 7, provide additional high-level design documentation for packages and major classes.

   2. Such documentation includes, but is not limited to,

      1. UML package diagrams

      2. UML class diagrams

      3. function diagrams

   3. There are no general requirements for using design diagrams; your formal milestone evaluations will include specific individual requirements for design documentation.

1. Provide a HOW-TO-RUN-TESTS.html file in the project administration directory.

   1. If you use the you use the Makefile-based testing framework described in the notes and examples, then the description of how to run tests is given in terms of the make target(s) to execute; if you use the 309 makefile template specifically, then HOW-TO-RUN-TESTS can be as simple as "Type make in the project testing directory."

   2. If you use some other testing framework, then HOW-TO-RUN-TESTS must describe clearly and precisely how to execute the tests, and how to view the results.

2. Provide a m4-duties.html file that itemizes the Milestone 4 work for each team member, in the same table format as for Milestone 3.

   1. the parts of the project that produce validated execution results

   2. the class for which the test plan is written

   3. the methods for which the preconditions, postconditions, and test plans are written

3. Update the HOW-TO-RUN.html file to reflect the updates and modifications you have made for these latest milestones.

4. Update work-breakdown.html as necessary. (The work-breakdown file defines overall project responsibilities. The m4-duties file defines the specific work for Milestone 4. For example, work- breakdown can say that team member X is working on all of the classes in a particular package. The m4-duties file will say which particular classes and methods are the focus of work for Milestone 4.)

5. Prepare for the team design reviews to be held in lab during the 6th week.

   1. During week 7, each team will present their design in a 24-minute technical review.

   2. You may use any media you choose, including powerpoint slides, whiteboard, and operational demos.

   3. Organize your presentations along the following lines:

      1. focus the discussion on the major interesting model and view classes

      2. use UML and function diagrams to present the design

      3. provide at least one operational demo of an interesting piece of functionality

   4. The presentation schedule is as follows:
      
      

      Day	Time	Team
      Wed 13 May	2:10-2:35	Token CSC
      	2:35-3:00	DJ Cars
      	3:10-3:35	Fire Breathers
      Fri 15 May	2:10-2:35	Node
      	2:35-3:00	Team 0
      	3:10-3:35	Team 1

Footnotes:

¹ The term "branch coverage" is used in the documentation of some Java coverage tools, notably Cobertura. As used there, it is equivalent to the term "decision coverage" as described in Lecture Notes 8. In any case, your chosen coverage tool must require that the Boolean logic of all if-else conditional expressions is fully exercised, not simply that both branches of an if-else statement are taken.