Informatics 122 Winter 2013
Project #4: Right in the Middle (Implementation)
Due dates and times
Monday, February 25, 11:59pm
This project is to be done individually
Implementing and adjusting your design
Now that you've completed a preliminary design from Project #3 and received feedback on it, it's time to complete an implementation of the program. Unlike your previous implementation, where you were required to maintain someone else's design as-is, this time you'll be implementing your own design, and you are permitted to make any adjustments you'd like to your design, though you will be required to justify them in a separate document. I expect that most of you will need to make at least a few changes, especially as the realities of writing unit tests show you where your design isn't sufficiently decoupled.
As before, you'll be required to use Git or EGit while you work, and will be including your entire Git repository to us as part of your submittal for this project.
Unit tests and test coverage
One major requirement in your implementation phase is that you must write unit tests using JUnit. (Note that there are other unit test frameworks available for Java, but we will standardize on JUnit for this course, since it is built into Eclipse.) You will not be permitted to put the unit tests off until the end of your implementation phase, for the simple reason that your design can be profoundly affected by the need to write these tests; it would be disastrous to discover, at the end of your implementation, that you have a complete program with an untestable design. So, as part of your development, you will be required to add unit tests whenever you feel you've completed any part of the public functionality of a class. While we won't be checking this with a fine-tooth comb, we will be looking at your Git repositories to verify that you made an honest attempt at writing your unit tests as you went along.
Furthermore, you will be required to achieve 100% code coverage in your unit tests, except for the layer of functionality that actually communicates with external resource (i.e., it must be possible to run all of your unit tests without an Internet connection, without a particular file being present on the file system, etc.). Isolate this part of your functionality as well as possible, and keep an open mind about just how little functionality that can actually be.
The need to get your code coverage metric up will no doubt affect your design in profound ways, requiring you to decouple your classes more than you might otherwise need to do, and to use techniques like dependency injection to avoid hard-coding dependencies into your classes. (For example, a class where you want to write output to the console will instead need to write to a more general PrintWriter, so that the program can write to System.out while the unit tests write to a StringWriter.)
Installing and using the EclEmma plug-in
There is an easy-to-use code coverage plug-in for Eclipse called EclEmma, which we saw in a lecture example. We will be using this tool when we grade your work, as a means of assessing code coverage, and we recommend that you use it as you work on your implementation and unit tests.
It's important to realize what it is you'd like to measure. Your goal is to achieve as close to 100% code coverage as possible, not counting the actual unit test code itself; in other words, you want to know how much of your actual code is exercised by running your unit tests. One very useful way to measure this is to make sure your unit tests are in separate packages from the code under test; so, for example, if you were testing code in a package inf122.example, you might write the unit tests in a package inf122.example.test.
Measuring code coverage is as simple as running all of your unit tests under a "coverage mode" in Eclipse with EclEmma; the result will be a coverage report, as well as highlights throughout your code demonstrating what has been covered and what hasn't.
Installation instructions for the EclEmma Java Code Coverage plug-in for Eclipse are available on the EclEmma web site at this link. A thorough set of usage instructions are available in the User Guide on the EclEmma web site at this link. It is best to get this plug-in set up and running before you proceed with your implementation; it took me only a few minutes to install the plug-in, write a quick dummy example (a short class and a few JUnit tests) and run my first code coverage report.
Basic design and implementation goals
In the Project #3 write-up, some basic design goals were listed, which gave you an idea of the things you should have been thinking about as you worked through your design. The list below is a similar, but slightly broader list, of things you'll want to be thinking about now that you're working on your implementation, part of which is assessing the quality of your own design and making modifications to it.
Deliverables
You'll need to submit three deliverables for this project.
Follow this link for a discussion of how to submit files via Checkmate. Be aware that we'll be holding you to all of the rules specified in that document, including the one that says that you're responsible for submitting the version of your files that you want graded.