Homework 4 Solution

For this assignment we will continue to work on our ConnectX game, but we will not be adding any new functionality to our program. We will be creating automated test cases for our IGameBoard interface and implementations using JUnit. You do not need to create test cases for the Connect4Game class.




Requirements




You must test the following methods in a JUnit class called TestIGameBoard. Each test case should have it’s own JUnit test function.




Test the following methods:




Constructor




Create 3 distinct test cases for the constructor CheckIfFree



Create 3 distinct test cases forCheckIfFree CheckHorizWin



Create 5 distinct test cases



Create 5 distinct test cases CheckDiagWin



Create 8 distinct test cases



Note, the different diagonals are distinct CheckTie



Create 4 distinct test cases



Create 7 distinct test cases PlaceToken



Create 5 distinct test cases



Your JUnit test code must also use the Factory Method Design Pattern by having a private method that calls the constructor for your IGameBoard object and returns it. By always using the Factory Method, you will be able to easily switch between your 2 implementations while running your JUnit test cases.




You will also need an additional private helper method that will take in a 2D array of characters and return a string representation of that array. This string representation should exactly match what the toString method returns from our GameBoard classes. This will allow you to create an “expected” version of the GameBoard in a 2D array, then get the string version to compare to the actual output of your GameBoard. So your process for comparing your expected GameBoard and your actual GameBoard will look like this:




Create an empty “expected” 2D array



Call the factory method to create your empty IGameBoard object “gb”
Foreach token you need to place for your test case



Use placeToken to place it on your IGameBoard object “gb”



Place that same character in the same location in your 2D array “expected”



Call your helper method to create the expected string version of your 2D array



Call assertEquals to ensure your expected string and gb.toString() are equivalent



The Program Report




Along with your code you must submit a well formatted report with the following parts:




Requirements Analysis




Fully analyze the requirements of this program. Express all functional requirements as user stories. Remember to list all non-functional requirements of the program as well. Creating test cases is not a non-functional requirement, so these should be the same as previous assignments.




Design




Create a UML class diagram for each class and interface in the program. Also create UML Activity diagrams for every method in your Connect4Game class and every method in your GameBoard or GameBoardMem class (except the constructor). If a method is defined as a default method in the interface, you need to update it to remove any mention of the 2D array or other private data of the GameBoard class, and instead refer to primary methods. If a method is provided as a default method in the interface you only need to provide an Activity Diagram for the default method, you do not need to include the Activity for each implementation as well.




You do not need to create diagrams for your Test class that you will make for this assignment, so these diagrams are the same from the previous assignment.




Testing




In your report include a description for each test case which includes your input values, your expected output, and a reason for why you chose this test case and what makes it distinct. This can be a bulleted list or a table.




Deployment




Provide instructions about how your program can be compiled and run. Since you are required to submit a makefile with your code, this should be pretty simple. Your makefile should include targets to compile your program (default), run your program (run) compile your test cases (test) and run your test cases (make test)




Additional Requirements and Tips




You must include a makefile with your program. We should be able to run and test your program by unzipping your directory and using the make, make run, make test, make runtest commands.



If you discover any failures with your test cases, you will need to find the underlying fault and correct it.



Your UML Diagrams must be made electronically. I recommend the freely available program draw.io, but if you have another diagramming tool your prefer feel free to use that.



Hard coded values are acceptable (and necessary) for our input and expected output values



You will need to call several methods in order to set up your test case. That is fine, as long as your Assert statements are only testing one method. Remember if you run your test cases and



you have failed test cases for whatsAtPos and checkDiagWin, you want to fix whatsAtPos first, as that method is called in checkDiagWin.




You do not need to follow the entire process in your main function to test your IGameBoard class, because our input is hard coded and always follows our preconditions. This means



o You aren’t asking the user for input o You aren’t validating input




o You don’t need to call checkIfFree before placing tokens since they are hard coded and we know the column is free




o You don’t need to call checkForWin after every token placement o You aren’t printing anything to the screen




o You don’t need to follow the turn order when placing tokens.




Remember test cases should be distinct in a meaningful way. The difference between checking for a win with the exact same board, but swapping X’s and O’s is not distinct, as IGameBoard doesn’t actually care what the character is.



You do not need to use any specific method (such as path testing) to identify test cases.



Remember to think about what was challenging for you when you were writing code. What mistakes did you make in earlier attempts? Those would be good scenarios to test for.



Make sure you are using JUnit 4, not the JUnit 3 shortcut on the school unix machines.



The JUnit code for the test cases will be very similar for each method. Make sure you get one example working, then copy and paste to change the input values and expected output values.



Remember to follow the best practices we discussed for JUnit test cases. They are different than the best practices for our normal production code.



You may need to use several assert statements to check to see if everything worked correctly by checking the string representation, the return value of the method, the getter methods, and so on.



While writing JUnit code is not necessarily difficult, it is time consuming. Thinking of all the test cases and fixing any faults you find will also take some time. Avoid the temptation to put this assignment of because its “just” writing test cases.



You should not create test cases that violate the preconditions for the method being tested.



-







Submission




You will submit your program on Handin. You should have one zipped folder to submit. Inside of that folder you’ll have your package directory (which will contain your code), your report (a pdf file) and your make file. Make sure your code is your java files and not your .class files.




Note: This assignment is due on a Saturday night. Friday night would be the same time as a lab assignment is due. There is an exam on the following Monday, so I don’t want you working on the assignment late Sunday night. Please start this assignment early to give you the ability to balance this work load.




Academic Dishonesty




This is an INDIVIDUAL assignment. You should not collaborate with others on this assignment.




See the syllabus for further details on academic dishonesty.




Late Policy




Your assignment is due at 11:59 pm. Even a minute after that deadline will be considered late. Make sure you are prepared to submit earlier in the day so you are prepared to handle any last second issues with submission.




If your assignment is late, but turned in within 24 hours of the due date, you will automatically receive 25 points off. If it is more than 24 hours of the due date, but less than 48 hours of the due date, then you will receive 50 points off automatically. After 48 hours from the due date late assignments will no longer be accepted.