To run your tests, open the testing file you want to run and press the green play button in the top left of your screen.

Sometimes this may run your entire program instead of the test file. To run only the test file, right click on the file in the Package Explorer (left of your screen, by default), click Run As, and click JUnit Test.

You will be able to see which tests passed, failed, or resulted in an error.

Double-click on a failing test case in the above window to display its failure trace, which will help you debug!

As much as you might want to forget about OCaml, we don’t want all of your good test-writing skills to go to waste! Recall the syntax we used to write this test for rainfall in HW01:

let test () : bool =
    rainfall [1; 2; 3; -999] = 2
;; run_test "rainfall: -999 ends the list" test

We write run_test to indicate that we’re running a test. We provide run_test with two arguments: a string that describes the test and the test that should be run. In the test, we compare the actual result, rainfall [1; 2; 3; -999], to the expected result, 2. We’ll find the same structure in tests in Java.

Let’s look at the syntax of a test we write for you in HW06:

@Test
public void testConstructInBounds() {
    Pixel p = new Pixel(40, 50, 60);
    assertEquals(40, p.getRed());
    assertEquals(50, p.getGreen());
    assertEquals(60, p.getBlue());
}

First, annotations before every method in the class are used to indicate the purpose of the method and are designated with the @ symbol. Here, we want to use the above method to test one of the Pixel constructors, so we use @Test to indicate we want JUnit to run it as a test.

In OCaml, we run run_failing_test instead of run_test when we want to test code that should fail. In Java, you can do something very similar.

Imagine a function squareRoot defined like so:

public static double squareRoot(int x) {
    ...
}

Suppose we want squareRoot to throw an IllegalArgumentException when x is less than zero. We’ll use the assertThrows method to test that, using the following syntax:

@Test
public void testSquareRootThrowsIllArgExcNegativeInput() {
  assertThrows(IllegalArgumentException.class, () -> {
     squareRoot(-1);
  });
}

We specify the exception that we expect to be thrown, and then we write the code that should throw that exception between the brackets.

Use appropriate assert statements. In OCaml, you avoided statements like if x = true when x was a boolean value. Similarly, we want to avoid writing assertEquals when one of the two arguments is true, false, or null. Instead of writing assertEquals(x, true), write assertTrue(x).

Just like in OCaml, we highly recommend writing tests as you go before implementing each method. Writing tests before you write the code makes sure you completely understand the method: the parameters, the return value, the behavior for edge cases or invalid inputs, etc.

The first thing you should do before writing a test is read the method description. Before each method we ask you to implement, we have a description of the method detailing the parameters, what it’s supposed to return, what it’s supposed to do, and information about exceptions or invalid inputs. All of this information can be directly translated into tests.

Let’s look at the method description for the first Pixel constructor we ask you to implement:

/**
 * Create a new pixel with the provided color intensities.
 *
 * If the supplied arguments are not between 0 and 255, they are clipped:
 *
 * Negative components are set to 0.
 * Components greater than 255 are set to 255.
 *
 *
 * @param r the red component of the pixel
 * @param g the green component of the pixel
 * @param b the blue component of the pixel
 */

Just from this description, you can see you’ll want to test creating a Pixel with all valid inputs, with at least one input less than 0, and at least one input greater than 255. This can be generalized to be testing:

• Valid, non-special case inputs
• Valid special case inputs
• Invalid inputs

If your method has multiple different behaviors it could exhibit, make sure you test each of them.

Now that you know what to test, you need to learn how to test it. Our provided test, testConstructInBounds, uses getRed(), getBlue(), and getGreen() to check that the components of the Pixel were initialized correctly.

getRed(), getBlue(), and getGreen() are examples of getters. Most classes you work with will have methods referred to as getters and setters. A getter allows you to get (a copy of) some information (usually stored in a field) from an object. getRed() is a getter for the red color component of Pixel. A setter allows you to set the value of some field in an object. Setters may not always be available - some fields are meant to be private, or encapsulated, within the class. Setters might also place limits on what you can change in order to maintain internal invariants. Pixel.java does not provide setters, because a Pixel should be immutable once it is instantiated.

Getters will be one of the most commonly used tools in your Java testing toolbox.

In OCaml, we recommended “bottom up” testing, where you write and debug simpler tests before more complex tests. In OCaml, this looked like testing base and edge cases first or testing a function earlier in the homework that we’d ask you to utilize as a helper function later in the homework.

In Java, you will implement many large classes with complex behaviors, and bottom up testing will become only more important. Let’s go back to CandyBowl. It has a getter, checkCandyCount() that “gets” the count of candy left. We used checkCandyCount() in our testTake5Refill7() test, but imagine if there was an error in checkCandyCount() that caused the test to fail. We might start debugging by examining takeCandy and refillCandy since it might not occur to us to check checkCandyCount at first. If we had tested our getter first, we would be able to save time searching through multiple functions for the error. Let’s look at how we could test checkCandyCount() using no other methods and knowing the initial count is 10:

@Test
public void testCheckCandyCount() {
    assertEquals(b.checkCandyCount(),10);
}

Check out the appendix for the full code and another example getter test! You might think these tests will be short and simple, but some might require some thinking. Either way, don’t skip them! You’ll save yourself so much time and energy if you don’t have to trace through all the methods you use in a test to find why it’s failing.

Now, assuming you’ve tested the simple stuff first, how do you test the complex stuff?

Complex methods often call simpler methods as helpers. Thankfully, you’ve tested your simpler methods already, so you’ll be able to fix those smaller bugs early on before they propagate to complex methods. That lets you focus on what each complex method does overall, instead of getting lost in the weeds of its simpler method calls.

To test complex behavior, run the complex method(s). The complex methods can produce an output or change the state of your program, so you’ll now want to check that the method’s output and the program’s state matches with your expected values. The best way to test the program’s state is by using assertEquals and getters. You may want to confirm that parts of the program that should not have changed did not change.

Encapsulation is a concept that comes up multiple times in CIS 1200. For the purposes of testing, to test encapsulation is to test that you can’t change an internal value willy-nilly. Test that you can only change a value through the appropriate methods.

Consider a simple class called MyNumbers:

public class MyNumbers {
    private int[] myNumbers;

    public myNumbers(int[] x) {
        myNumbers = x;
    }

    public addNumber(int x) {
        myNumbers[0] = x;
    }

    public removeNumber() {
        myNumbers[0] = 0;
    }

    public getNumbers() {
        return myNumbers;
    }
}

In this class, we should only be able to change myNumbers by calling addNumber or removeNumber. In other words, we are encapsulating the information in myNumbers - it should only be modifiable via addNumber or removeNumber. We also have a getter, getNumbers.

If I am able to modify myNumbers without using addNumber or removeNumber, that would violate encapsulation. Clearly I can’t access myNumbers directly, because it’s a private field. Is there any other way I can modify it without using addNumber or removeNumber?

Consider the current implementation of getNumbers. The current implementation will return a pointer to the myNumbers object on the heap. If I wrote:

int[] arr = getNumbers();
arr[0] = arr[0] + 1;

This would also modify myNumbers, since arr and myNumbers are aliased and referentially equal. A better implementation would be:

public getNumbers() {
    return Arrays.copyOf(myNumbers);
}

Now, understanding that example, to test encapsulation we could write the following:

@Test
public void testGetNumbersEncapsulation() {
    int[] x = new int[2];
    x[0] = 0;
    x[1] = 1;
    MyNumbers n = new MyNumbers(x);
    int[] y = n.getNumbers();
    y[0] = 5000;
    assertEquals(n.getNumbers()[0], 0);
}

When this test passes, we can be certain that the only way to modify myNumbers is through the appropriate methods. We have preserved encapsulation.

When you create a class in Java, you should always override the equals method. To evaluate whether two objects are structurally equal, you must call equals. For example, object1.equals(object2).

By default (if you do not override equals), your classes will use reference equality for comparison when you call object1.equals(object2).

To ensure you have overridden equals and to ensure you have done so correctly, test that comparing two referentially unequal but structurally equal instances of a class returns true.

When you create a class in Java and you want to store instances of that class in a Set, you need to implement the Comparable interface. (If this doesn’t make sense right now, you can skip this until it comes up in lecture.)

The Comparable interface requires that you implement one method, compareTo(T o), where T is the type of the class implementing the Comparable interface.

Make sure to test the compareTo(T o) function thoroughly, as it is a common source of bugs when working with TreeSets or TreeMaps.

Model-View-Controller (MVC) is a way of structuring the framework of a program typically used for user interfaces. As the name suggests, it’s broken down into three parts: the model, the view, and the controller. The model contains all of the data or knowledge of the program, the view displays the model and is actually seen by the user, and the controller links the two by accepting user input, translating it to the model, then updating the view to reflect the change in the model. As a result of this structure, the model and controller can exist without the view – everything a person could do to interact with the user interface could be written in code.

Our Paint application is an example of this framework. The model can be seen most easily in paint.ml. paint.ml contains all of the data for the internal state: definitions of the types point, shape, state, etc, the current state, the deque of shapes, all of the widgets, and more.

The view is most easily seen in eventloop.ml. We didn’t ask you to write any of this code, and you might not have looked at the file, so let’s look at some of the comments for the functions in eventloop.ml:

(**
 * This function takes a `widget`, which is the "root" of the `GUI` interface. It creates the "top-level" `Gctx`,
 * and then it goes into an infinite loop.
 *
 * The loop simply repeats these steps forever:
 * - wait for a user input event
 * - clear the graphics window
 * - forward the event to the widget's event handler
 * - ask the widget to repaint itself
 *)

This file is what creates the initial window that the user sees and can interact with. If it receives user input, it passes it off to the controller and repaints itself with the updated model.

The controller is most easily seen in widget.ml. Here, we define event_listeners, value_controllers, etc that take in user input and translate it to updating the internal state of paint.ml. To put it all together, if a user clicks the thick lines checkbox in the Paint window, eventloop.ml passes this to the checkbox’s event handler which we designed in widget.ml. The checkbox widget specifies generally what happens if a MouseDown event happens inside the widget. In paint.ml, we’ve defined specifically what happens when the thick lines checkbox is clicked, so the internal state of paint.ml is updated to have thick lines when the handle of the widget occurs. Since the value of the checkbox also gets updated inside of paint.ml, when the window repaints, the checkbox widget draws the box differently in it’s repaint field (checked vs unchecked). This is then translated to the way the checkbox looks to the user.

In this example, user input to the view was translated by the controller to update the model. The updates were then translated by the controller to reflect in the view.

All of the Java homeworks have some kind of user interface and internal state, so understanding how they are designed as MVC is very important for testing. One feature of MVC is that everything designed to happen in the model and controller can happen without the view. For example, clicking on a checkbox and passing a MouseDown event to a checkbox through code are handled the same way by the controller and the model.

Let’s look at a test from widgetTest.ml for an example of this:

let gc = Gctx.top_level
let click55 = Gctx.make_test_event Gctx.MouseDown (5,5)

;; run_test "checkbox click" (fun () ->
    let w, cc = checkbox false "checkbox" in
    w.handle gc click55;
    cc.get_value())

click55 is a MouseDown event and w, cc are the widget and value controller for a checkbox. Sending click55 to the handle of w should act the same as clicking in w in the Paint window. Since this checkbox was initialized to false, and the handle of w should update the value_listener of the checkbox to be true, so cc.get_value() should now be true, causing the test to pass.

When you write tests in Java, you should be testing how the controller updates the model. Instead of testing how the user interacts with the interface, you should test that the internal state updates correctly by stimulating user events through code. For example, in ManipulateTest in HW06, the tests make sure the methods you write in SimpleManipulations and AdvancedManipulations work by comparing the result of calling each method to a hard-coded expected result.

public static PixelPicture smallSquare() {
    return new PixelPicture(new Pixel[][] {
        {Pixel.BLACK, Pixel.BLUE},
        {Pixel.RED,   Pixel.GREEN}
    });
}

@Test
public void rotateCwSmall() {
    assertEquals(
        0,
        PixelPicture.diff(
            new PixelPicture(new Pixel[][] {
                {Pixel.RED, Pixel.BLACK},
                {Pixel.GREEN,Pixel.BLUE}
            }),
            SimpleManipulations.rotateCW(smallSquare())
        ),
        "rotateCW 2x2 image"
    );
}

This test compares the result of calling SimpleManipulations.rotateCW on smallSquare() to what we expect smallSquare() to look like. In Pennstagram, this action would be performed by clicking the RotateCW button, but we can just call the method without needing to interact with the GUI.

The JUnit tests do not need the user interface at all, so the MVC framework allows you to thoroughly test the model and controller without using the view. The next section will explain when testing through the GUI is helpful, but when you write JUnit tests, you should not need to involve the GUI at all.

Think back one more time to Paint and how you tested it. We gave you some tests in widgetTest.ml, but a large part of your testing was running paint, gdemo, or lightbulb and playing around with them to make sure your code worked. Your checkbox was tested in widgetTest.ml to make sure clicking it would change the value, but your specific checkbox for thick lines was only tested by checking it and drawing some shapes.

Testing with JUnit tests will typically be more exhaustive than testing with the GUI and will make it easier to pinpoint which functions are causing an error. Playing around with the GUI is still important to ensure everything is displayed properly since some visual changes are difficult or impossible to test through JUnit tests. For example, if we wrote a program to draw out the pieces of candy left in our CandyBowl, we can write JUnit tests to ensure the internal count is updated properly, but the only way to check that we draw the right number of pieces of candy is by running the program and seeing what it looks like.

It will be important for you to figure out what parts of your code are best tested through tests and which are best tested by playing around with the GUI. Thinking of the Model-View-Controller framework might help with this! This will become more important in later Java homeworks, so keep this in mind for the future.

Happy testing :)