CompSci 308 Spring 2025 |
Advanced Software Design and Implementation |
More than the act of testing, the act of designing tests is one of the best bug preventers known. — Boris Beizer
Build and test your planned Cellular Automata simulator. Working together as a team, collaborate to create a basic implementation of the given project specifications, incorporating packages that clearly separate the Model (which has no dependencies on OpenJFX) from the View (which uses OpenJFX to display and interact with the Model's data). Unlike other classes where tests are provided for you to "grade" your work, in the real world you need to develop your own tests as you go to get in the habit of creating easily repeatable ways to validate your confidence in your code.
You are encouraged to start simply in order to verify your understanding of the project's essential algorithms with the initial simulations.
Along the way, test and refactor your code to help it serve as a well-designed foundation for the more diverse functionality changes to be revealed in the next part. As a reminder, in addition to the Design Specification from the first project, you are expected to consistently adhere to DESIGN-07 through DESIGN-12 for this part:
Specifically, the core classes submitted for this part should use abstractions so new features are created by addition rather than changing existing code and encapsulate implementation details so that the other classes will not be dependent on them (minimally, the Model's grid data structure, the View's display of the grid, and the file format details).
As a reminder, your commit messages must reference the Issue and Functional or Design Requirement ID represented by your code changes following this format.
We strongly suggest using the course's suggested GIT workflow for teams to make working in a team easier. So that the entire team can make progress, all team members need to integrate each other's work regularly (push
their own changes that others depend on and pull
others changes to stay current with the project's design) rather than having marathon merge or redesign sessions because everyone's code has drifted from a common design.
Inevitably, conflicts will occur and they should be used as opportunities to think about and collaborate on how best to resolve distinct changes to the same piece of code.
While you are welcome to use GIT tag
s anytime during your project to annotate an important commit, you must tag the commit your team feels is the finished version for this deliverable as Basic
.
When creating tests for your code, the ZOMBIES acronym serves as a good guide, as well as considering “negative” testing, the kinds of input errors might occur, beyond basic checks of positive functionality. Your tests should be written in separate classes and methods that follow these naming standards to show what you are intending to test.
For this part, you will focus on testing the Model and configuration (not the View yet) in two ways by creating:
Line
test coverage of your concrete classes)Exact details about the number and types of tests are given in the Functional and Design Requirements.
While you are not required to practice TDD strictly (always writing a test before writing any code), you are expected to create tests frequently during the coding process rather than waiting until the end. As a reminder, in addition to helping regularize your programming session, it provides a host of other benefits and even more! No matter what you decide, to demonstrate you are regularly attempting to test your code, all GIT commits that add new features or fix bugs (i.e., not refactoring) must include at least one new or updated test.
As a side note, the Game of Life simulation is a common exercise given for practicing TDD since it is interesting but not too difficult. To give you a sense of what this process is like, here is one person's log of completing such an exercise. The code's design is not something to emulate, just the process (although the comment at the end is worth noting given the project's Model-View separation goals).
We will check that each person regularly commits test files rather than waiting to do it until the end.