1. Black-box Testing

Your task is to derive test cases for a number of methods using their specifications. Analyse the specifications in order to divide the set of possible inputs into different situations. Then write a set of test cases for each method, which covers the different cases well. For each test case, give a comment which describes what situation it tests. In a report file, you must explain and motivate why you divided the test cases in the way you did. You must show how you defined the input space, and how you partitioned it.

The assignment is about a class called WorkSchedule. The purpose of the class is to manage the schedule for the employees of a company. The time is divided in units of 1 hour and the hours are simply identified by integers (Note that this is an unrealistic simplification). For each hour, the schedule stores the number employees which is needed at that time. It could for instance be that during week-days the need is that 5 employees work at the same time, but less during nights and weekend. For each hour the schedule also stores the names of the employees who have been assigned to work at that hour.

The methods of the class are:

  public WorkSchedule(int size) { ... }
  public Hour readSchedule(int time) { ... }
  public void setRequiredNumber(int nemployee, int starttime, int endtime) { ... }
  public boolean addWorkingPeriod(String employee, int starttime, int endtime) { ... }
  public String[] workingEmployees(int starttime, int endtime) { ... }
  public int nextIncomplete(int currenttime) { ... }

• WorkSchedule(size) creates a schedule which contains the hours 0,1,2,...,size - 1 where for each hour the number of needed employees is set to zero and there are no employees assigned to it
  
• readSchedule(time) gives back the an object of the following type:
  

    public class Hour {
      int requiredNumber;
      String[] workingEmployees;
    }
  

  requiredNumber is the required number of employees working at hour time.
  workingEmployees is the names of the employees who have so far been assigned to work at hour time.
• seqRequiredNumber(nemployee, starttime, endtime) sets the number of required working employees to nemployee for all hours in the interval starttime to endtime.
• addWorkingPeriod(employee, starttime, endtime) schedules employee to work during the hours from starttime to endtime.
• workingEmployees(starttime, endtime) returns a list of all employees working at some point during the interval starttime to endtime.
• nextIncomplete returns the closest time starting from currenttime for which the required amount of employees has not yet been scheduled.

The constructor (WorkSchedule) and the method readSchedule are trusted to be correct and do not need to be tested. Note that readSchedule can be used to examine the state of a class instance.

A compiled implementation of the class can be found in the following Java archive:

WorkSchedule.jar

You are supposed to run your test cases on the methods in the .jar-file. Note that some methods may be correctly implemented, and some may contain bugs.

a.
Derive test cases for setRequiredNumber using the specification:

specification for seqRequiredNumber
requires: starttime >= 0, endtime < size, starttime <= endtime, nemployee >= 0
ensures: For i between starttime and endtime, the requiredNumber of hour i equals nemployee.
         For all other i the schedule is unchanged.

b.
Derive test cases for addWorkingPeriod using the specification:

specification for addWorkingPeriod
requires: employee is a non-null string
ensures:  if starttime < 0 or endtime >= size or starttime > endtime then
           returns false and the schedule is unchanged
          otherwise
           if for any hour in the interval starttime to endtime the length of workingEmployees is equal to requiredNumber then
             returns false and the schedule is unchanged
           otherwise
             if for any hour in the interval starttime to endtime there is a string in workingEmployees which equal employee then
               returns false and the schedule is unchanged
             otherwise
               returns true,
               for i between starttime and endtime, workingEmployees contain a string equal to employee and
               the rest of the schedule is unchanged

c.
Derive test cases for workingEmployees using the specification:

specification for workingEmployees
requires: starttime >= 0 and endtime < size
ensures:  if starttime <= endtime then
           returns an array with distinct strings
           a string appears in the return array if and only if it appears the workingEmployees of at least one hour in the interval starttime to endtime
          otherwise
           returns an empty array
          and in either case the schedule is unchanged

d.
Derive test cases for nextIncomplete using the specification:

specification for nextIncomplete
requires: currenttime >= 0 and currenttime < size
ensures:  if there is an hour in the interval currenttime to size - 1 such that the length of workingEmplyees is less that requiredNumber then
           returns the time of the hour closest to currenttime such that the length of workingEmplyees is less that requiredNumber
          otherwise
           returns -1
          in either case the schedule is unchanged

2. White-box Testing

For the assignments in part 2 you will be using the source code of the methods. For each method you should first derive a suite of test cases which together have full statement coverage of the source code. Then you should write additional test cases (if any are needed) which together with the ones already there have full branch coverage of the code. The test cases should be executable with JUnit just like in part 1 of the lab. If any of the test cases for a method fails, try to find the bug and correct the source code.

Keep in mind that you may need a method, A, to set up the test of another method, B. If the method A has a bug it can be very tricky to test method B. Wherever possible you can first fix the bug in a method and then do the tests that use it in the setup (or test oracle). Also keep in mind that a bug in the implementation may imply that full statement or branch coverage is not possible. This it in itself an indication of the bug's existence. In such case, it's enough if you have full coverage after fixing the bug.

The assignment is about the class Set.

Set represents sets of integers. The elements of a set are stored in an ArrayList. They are sorted and without duplicates to speed up some operations. Two methods might need an explanation:
s1.section(s2) remove from s1 any element which is equal to an element in s2.
s.containsArithTriple() returns true if there are three elements, x, y and z, in s such that y - x = z - y.

Note that you can use toArray to easily examine the state of a class instance.

a.
Use statement and branch coverage to derive test cases for insert.

b.
Use statement and branch coverage to derive test cases for member.

c.
Use statement and branch coverage to derive test cases for section.

d.
Use statement and branch coverage to derive test cases for containsArithTriple.

e.
If you find any bugs, try to correct them in the implementation. Also keep in mind that it might be your specification that is incorrect. Make a new version of Set.java which passes all your tests.

Reporting Upload an archive LAB1.zip (or rar, tar.gz, tar as you wish) using the Fire report system. The archive must have the following structure: LAB2.zip | |-ex1 | |- <your_1st_test_class>.java | |- ... | |- <your_nth_test_class>.class | \- WorkScheduleTestSuite.java | |-ex2 | |- <your_1st_Set_test_class>.java | |- ... | |- <your_mth_Set_test_class>.class | |- SetTestSuite.java | \- Set.java | \-report.txt ex1, ex2 are directories ex2/Set.java is your implementation of class Set.java ex1/WorkScheduleTestSuite.java is the test suite class for Exercise 1. It looks like the following replacing the contents within angle brackets < > with your own class names in the same directory: import org.junit.runner.RunWith; import org.junit.runners.Suite; @RunWith(Suite.class) @Suite.SuiteClasses({ <your_1st_test_class>.class, ... <your_nth_test_class>.class }) public class WorkScheduleTestSuite { // nothing goes here } Executing with JUnit the WorkScheduleTestSuite class makes JUnit run the test cases contained in the classes specified inside the @Suite.SuiteClasses annotation arguments. ex2/SetTestSuite.java is the test suite class for Exercise 2. It looks like the following replacing the contents within angle brackets < > with your own class names in the same directory: import org.junit.runner.RunWith; import org.junit.runners.Suite; @RunWith(Suite.class) @Suite.SuiteClasses({ <your_1st_Set_test_class>.class, ... <your_mth_Set_test_class>.class }) public class SetTestSuite { // nothing goes here } Executing with JUnit the SetTestSuite class makes JUnit run the test cases contained in the classes specified inside the @Suite.SuiteClasses annotation arguments. ex1/<your_1st to nth_test_class>.java are all classes implementing test cases for exercise 1 (replacing the contents within angle brackets < > with your own class names) ex2/<your_1st to mth_Set_test_class>.java are all classes implementing test cases for exercise 2 (replacing the contents within angle brackets < > with your own class names) report.txt is the report file (where you have to motivate how you engineered the test) Remark: No need to be more complex than this; avoid package declarations, avoid to add unnecessary files such as hidden files or folders produced by your text editor, for instance. Submission deadline is: Friday, November 16 2012 23:59 Deadline for passing the lab is: Wednesday, November 28 2012