The tests in the gui package in the <> source folder should compile now. The StudentEditorTest is complete. You will be completing the StudentViewerTest.

1. Run the tests using <

   Test">> and then let go of the mouse. Seriously --- take your hand off the mouse.

   You should see the AssertJ robot start clicking and typing. That is why you needed to let go of the mouse --- if you jiggled it while the robot was doing its thing you might cause it to miss what it was aiming at.

   We did once watch a student accidentally bump the right mouse button causing the mouse pointer to move over the NetBeans projects pane along with a right-click at the wrong moment and the AssertJ robot managed to select the Delete option in the NetBeans project menu. Luckily it didn't also click the <

   > button to confirm the deletion, but there was some sweating/swearing while we waited for the tests to complete.

   Having said that, the robot is pretty reliable. The above scenario was a complete fluke --- the robot was looking for a <

   > button on the dialog at the exact moment that the student bumped the mouse, and instead found and clicked on the <> option in the menu that appeared. Even if you do bump the mouse, the chances of it doing something scary to your computer are very slim. The worst that will usually happen is that a test will fail, or the mouse pointer will get stuck and you need to stop the test.

2. You will likely see some red warnings in the output pane. They are warnings relating to changes to the Java reflection API in newer versions of Java causing potential incompatibilities with some of the libraries we are using. You can ignore them.

3. Take a look at the gui.StudentEditorTest class.

   There is a lot going on in there. It is heavily commented, so you should be able to see what is happening.

   StudentDAO is a DAO interface.

   The @BeforeEach method is creating a mock DAO object using Mockito. Since the DAO needs to provide majors to display in the majors combo box the setUp method creates a getMajors stub that returns some hard-coded majors.

   Lines 29--33 are configuring the AssertJ robot. You can slow the robot down further by increasing the delay on line 32. This allows you to see exactly what the robot is doing which is sometimes handy if it isn't doing what you want it to. When you are happy that the tests work you can reduce the delay to speed up the tests --- don't make the delay less than 10 or the robot will be trying to click on things before the GUI has finished initialising them.

   The testSave method is using AssertJ to interact with the dialog.

   Let's take a closer look at the save test (testSave method).

   Lines 56--60 are creating the dialog and setting up the interaction between the dialog and AssertJ.

   Line 63 tells AssertJ to display the dialog and then also verify that the dialog actually appears. This will catch any errors in the dialog's constructor that cause it to not be displayed.

   Line 67 tells to robot to click on the dialog. This is needed since if you are using multiple monitors and/or virtual desktops then the keyboard focus doesn't always automatically switch to the new dialog. This ensures that the dialog is focused.

   Lines 70--72 instruct the robot to enter values into the text fields and combobox.

   Line 75 instructs the robot to click the <

   > button. At this point the btnSaveActionPerformed handler is executed so new student object should be created and stored in the DAO.

   From that point on the test hands over to Mockito to check the interaction between the dialog and the mock DAO.

   Line 78 sets up a Mockito captor object to grab hold of the student domain object that was created and passed to the DAO via the save method.

   Line 81 uses Mockito to check that the DAO save method was called and captures the student object that is passed to that method. If the save method has not been called at this point then test will fail.

   Line 84 gets a reference to the captured student object from the captor.

   Lines 87--89 use Hamcrest to check that the student object's fields contain the new values that were entered into the GUI by the robot.

We are using four different testing libraries for testing the GUIs. Here is a quick summary of the role of each library:

• JUnit is used to define the test methods (@Test, @BeforeEach, @AfterEach), run the tests, and report the results.

• AssertJ Swing is used to drive the robot (enterText(), selectItem(), ...) and verify that the components are displaying what we expect them to display (require...())

• Mockito is used to mock the DAO (mock(), when(...).thenReturn(...)), verify that the DAO methods were called by the GUI (verify()), and also get hold of the object that was passed to the DAO methods (capture()).

• Hamcrest is used to verify that the details of the saved student matched was was entered into the GUI (assertThat()).