The program should now start running in the Console tab at the bottom of Eclipse. Answer the first prompt by just pressing the Enter/Return key (it has the same effect as if you typed the default value that appears in the parentheses); then answer the second prompt by typing the number in brackets that precede LinearArrayQueue (which should be option 4). The console window will display the following menu of options that you can use to call/test each queue method.

Note that this Driver tests a queue that stores String values. You must enter a single letter to test any Mutator (Command) or Accessor (Query) method. Of special note is the t command, which test the toString method by printing the value it returns. It prints a String that starts with the name of the class (here LinearArrayQueue) and its interesting state in brackets. First, it always shows two numbers separated by a slash: the first is the number of values in (the size of) the queue; the second is the length of the array storing the queue (which should always be at least as big as the size). If the size of the queue isn't zero, the toString method shows that many indexes in the array, illustrating the index and value of each. Then testing this queue implementation, the user can call toString to observe the effect of calling a mutator. Issue the t command and the Driver should print the following

which describes a queue implemented by this class. It currently stores 0 values in an array whose length is 1 (the array currently has the capacity to store just one value). Then issue the s, e, and p commands to query the state of the object. The Driver should print the following

The peek command, which returns the first value (the Driver prints this value) in a queue cannot work correctly on an empty queue. Notice what is printed instead: the thrown exception (NoSuchElementException) and the sequence of calls that led to it being thrown; if you click on the link to LinearArrayQueue.java:106 Eclipse will load the file containing this class and highlight the line that threw the exception. Thus, the Driver just ignores this command and we can continue driving the LinearArrayQueue class. Next issue the a command and add/enqueue test1 when prompted. This method returns whether or not the entered value was added to the queue (for queues, which can contain duplicate values, it always returns true; for sets, which cannot contain duplicate values, this method returns false if the added value is already in the set). Then issue the t command and note the result: toString = LinearArrayQueue[1/1:[0]=test1] which describes a queue implemented by this class, currently storing 1 values in an array whose length is 1; the index 0 stores that value: test1. Next issue the a command again and add/enqueue test2 when prompted. Then issue the t command and note the result: toString = LinearArrayQueue[2/2:[0]=test1,[1]=test2] which describes a queue implemented by this class, currently storing 2 values in an array whose length is 2 (the length of the array storing the queue was automatically doubled in size to accommodate another value); the index 0 stores that value test1 and the index 1 stores that value test2. Order is important in queues: the earlier a value is added/enqueued, the earlier it appears in the array.

Next issue the r command which should remove/dequeue the value at the front of the queue. It correctly prints remove = test1. But then issue the t command and note the result is still toString = LinearArrayQueue[2/2:[0]=test2,[1]=test2].

This result is incorrect because test2 now appears in BOTH array locations (it was shifted one to the left, but still appears at the end of the array). In fact, if you issue the r command again, it prints remove = test2 and likewise the t command will still print both test2 values in the queue. If you issue the x command (which is void and returns -and the Driver prints- no result), the queue will be emptied; notice that the t command will print toString = LinearArrayQueue[0/2:] which now describes a queue implemented by this class, currently storing 0 values in an array whose length is 2 (the length of the array is not reduced).

You can examine the code in this class by double-clicking the icon and/or name TestQueue.java. Each interface has its own JUnit test, reflecting the semantics (meaning) of what the methods in a class implementing the interface do. It is good to be able to read and understand this code (and you will get more experience doing so during the quarter) because it can be useful to add debugging code to it: typically printing the state of variables at the time a test/assertion failed. Mostly JUnit code intersperses calls to the methods of the class being tested with assertions about what the results of those method-calls should be: a test method fails when any assertions in it fail. If you have not already done so, follow the instructions described above to start running the JUnit test in the Console tab at the bottom of Eclipse. Answer the first prompt by just pressing the Enter/Return key (it is as if you typed the default value that appears in the parentheses); then answer the second prompt by typing the number in brackets that precede LinearArrayQueue (which should be option 2); finally, answer the last prompt by also just pressing the Enter/Return key (it is as if you typed the default value that appears in the parentheses). A tab labelled JUnit will obscure the tab labelled Package Explorer in the leftmost window in Eclipse. In fact, the JUnit tab will split in half, with the bottom pane labelled Failure Trace. The large scale speed tests take some time to complete, but even so, very quickly all the tests will appear, some marked with a green check (passed) and some marked with a Blue S (failed). The green progress bar changes to red because not all tests were passed; above the progress bar it shows 14 tests run and 7 tests failed (we'll discuss the 0 test errors below: errors and failures are indicate two different problems with the code being tested). The result of running the JUnit test is illustrated below.

It is possible that incorrect code will result in an infinite loop in a JUnit test; you will see that test as active, with the tests after it neither marked Green nor Blue. In such a case, you would have to manually stop the program as described above (clicking the Red Square in the Console window). In the graphic above, the Red Square is greyed-out, because the JUnit test has already terminated. You have a choice of either commenting out the @Test annotation at the beginning of the problematic test (so JUnit won't run this test) or keeping the test and immediately debugging the code that is causing it to loop infinitely. If you choose the former, remember to reactivate the test eventually. To investigate a failed test further, we can click on any of the test names labelled with the Blue X; for now, click on remove (second from the bottom). By doing so, information appears in the bottom pane explaining the failure in more detail. To read this information, you will probably need to widen the leftmost window, containing the JUnit tab.

The first line in the Failure Trace pane tells us that there was a problem regarding the length of the arrays: the actual length of the array representing the queue was 5 when it should have been 4 Double clicking the next line in the Failure Trace pane shows us the line in the TestQueue program that discovered the problem: the failed assertion is on line 109. (there were originally 5 values in the queue, but after executing the remove method on this line there should be 4). This relates to the same problem discovered in the Driver: the remove method does not actually remove the value from the queue, so instead of a correct size of 4, it is one bigger. To see this problem more clearly, put the statement System.out.println("When testing "+testing+", Queue before move is " + q); right before the first assertEquals in the testRemove method (the one that is succeeding) and put a similar statement right after that assertEquals -before the assertArrayEquals that is failing. Run the JUnit test and notice that this code executes a few times, but the queues are always the same before and after calling q.remove(). That is why the asserArrayEquals fails.

By placing output statements in a JUnit test, we can more closely examine information about the state of the queue that is failing the test. In fact, all the test failures relate to this single bug: remember that sometimes fixing one bug will cause many failed tests to pass. As stated above, this "bug" is in the remove method in the LinearArrayQueue class (see lines 82-83). Restore the code objectCount-- (uncomment it) to fix the error.

  throw new ClassNotFoundException(name);

Then click the right-pointing green arrow (to the right of the Debug tab in the upper-left window) again. You will be prompted in the console window for the basic information needed to start the Driver. Issue the a command and the String test1. At that point the Debugger should stop at line 64, highlighted by a green line (this line is about to be executed). If we disclose the this variable in the Variables tab it should display the following information

Notice that the modCount and objectCount instance variables are both 0, the one element in the q array stores null (refernce to no String). Notice also that the parameter variable e refers to the String "test1". Now, step over/execute each of the statements in this method, watching how each statement changes the instance variables in the disclosed this. When the last line (return statement) is about to be executed, the Variables tab should display the following information.

At this point click the right-pointing green arrow again and issue the a command and the String test2. Now, step over/execute each of the statements in this method, watching how each statement changes the instance variables in the disclosed this. When the last line (return statement) is about to be executed, the the Variables tab should display the following information.

Note the new values for modCount, objectCount, and q (whose length has been doubled to 2). At this point click the right-pointing green arrow again and issue the r command. The Debugger should stop at line 76, highlighted by a green line (this line is about to be executed). The Variables tab it should display the following information

Now, step over/execute each of the statements in this method, watching how each statement changes the instance variables in the disclosed this. When the last line (return statement) is about to be executed, the the Variables tab should display the following information.