[ ] Verify that you have read the corrigenda/hints section of the MP1 description and that you have understood and addressed the remarks there.
[ ] Ensure that there are no unexpected import
statements. You should only be using the standard Java libraries and JUnit 5. Remove any other import
statements.
[ ] Verify that your submission will compile. One approach is to push all your work to GitHub, and then clone the GitHub repository in a separate directory (not the one that you were working with). Clone the repository from the command line and then run gradle test
. (This assumes that you have gradle set up to run from the command line.) Gradle should build your project and run all your tests. If there are failures here then your submission will definitely fail on the testing machines. Doing so provides some confidence that you have not accidentally relied on some IntelliJ IDEA feature that you should not be relying on.
[ ] Ensure that your code conforms to the style guide. You can make your life simple by using the Checkstyle-IDEA plugin and the style rules for CPEN 221 that are encoded in the following files:
You can see a video like this one to understand how to use Checkstyle with IntelliJ IDEA. If you set things up correctly then you can reformat your code using these rules from the Code → Reformat menu option (or using the alt-cmd-L keyboard shortcut on macOS or whatever the shortcut maybe for your OS).
[ ] Verify that you have acceptable code coverage through your tests. Instead of relying only on IntelliJ IDEA, you may want to use a tool like JaCoCo, which can be integrated with gradle to obtain test coverage. (We use JaCoCo to determine the coverage from the tests you have written.) You are responsible for code coverage for the code you write and not for all the code that was provided as well, although you will cover some of the provided code in your tests. We do provide some slack for code coverage but you should document the parts of the code that were not covered with reasons (e.g., not covering GUI code because it was provided to you and you did not use it).
[ ] Ensure that you have written specifications clearly for all methods.
[ ] Ensure that there is a contribution statement from everyone on the team.
[ ] Remove all TODO comments for the work that you have completed.