CompSci 308
Spring 2024
Advanced Software Design and Implementation

SLogo : Test Implementation

More than the act of testing, the act of designing tests is one of the best bug preventers known. — Boris Beizer

Working together as a team, collaborate to create a minimal Java implementation of your APIs that is well tested using JUnit tests including TestFX for simulating GUI actions (DESIGN-18).

You are encouraged to start simply, incorporating packages, and use your APIs as early as possible to solidify their goals on the project's essential algorithms (DESIGN-17). During this part, you may change your APIs without penalty, but later changes will incur either a time, documentation, or grade penalty. Note, it is important to ensure you remove all Static Code Analysis Issues regarding your API before moving on to the next part of the project.

In the folder doc/plan/api_revised, write updated descriptions of your three APIs based on your attempts to use them to code part of the basic project requirements.


Create the most simple version of the project APIs to get the frontend and backend working together without violating any Design Requirements (i.e., do not start with a "fix it later" mindset):


We strongly suggest using the course's suggested GIT workflow for teams to manage this process. Use merge conflicts as opportunities to think about and collaborate on how best to resolve distinct changes to the same piece of code. We will be looking for deliberate attempts to regularly:

If you are comfortable using the GIT command line, you can consider using a visual GIT tool to better see your changes and manage how your branches are organized, such as IntelliJ's GIT Toolbox plugin, the GitKraken standalone app, or the Tower standalone app (free for students).


Create test classes with JUnit test methods (code annotated with @Test and checked with one or more assertions) that attempt to demonstrate your code works as intended by setting up specific interesting situations. Additionally, use TestFX to simulate common user "actions" that are checked with common JUnit assertions to verify the UI responds appropriately (including changing languages and styles).

Make well named tests that test both "happy" and "sad" possible code paths (here are many, many, many examples in case you are having trouble thinking of possible negative tests), such as:

To give you a sense of what the TDD process is like, here is one person's log of completing the Game of Life (a common exercise for practicing TDD since it is interesting but not too difficult). Focus on the process shown, since the code's design is not something to emulate (although the comment at the end is worth noting given our discussion about dependencies and your project's MVC goals).

To demonstrate that you are following good testing practices, aim to include new or updated tests with each Merge Request to main that adds new features or fixes bugs.