BugBattle version 0.5
The objectives of this lab are to introduce the jUnit testing framework and Test-Driven Development, to give you practice solving some simple design problems, and to practice creating design documentation using the VP-UML tool. To achieve these aims, you will extend BugBattle as documented in the BugBattle v0.5 Change Request.
Your lab must be submitted by e-mail to
- Your lab report in PDF format. The report should consist of
- an introduction,
- the UML design documention described below (enclosed in the PDF lab report and not in separate files),
- an explanation of your “smarter creature” strategy (see task 0.5.7 in the change request), and
- a discussion of what you learned, discovered or found difficult while completing the lab (particularly regarding your use of jUnit). Be concise!
.zipcontaining your fully javadoc commented source files (see the Eclipse survival guide for export instructions).
- You are not required to submit the VP-UML model file(s) you used to create your documentation.
Installation. Create a new Eclipse project and then download and import BugBattle version 0.4, which is the starting point for this week’s lab.
There will be several errors reported by Eclipse because the jUnit 4 framework is not on the build path for the project. To fix this, open the class
AllTest, hover the cursor over the
@RunWith directive, and choose the offered option to add jUnit 4.
BugBattle to ensure it works. Run the jUnit test suite in
AllTests (Run As > jUnit test) and ensure that 39 tests run and the bar comes up green.
Code familiarization. Generate javadoc documentation for the project in Eclipse (Project > Generate Javadoc…). Review the javadoc and the project source code until you are sure you understand it.
For help understanding the test classes see the jUnit API documentation, particularly the documentation for the
org.junit package. You may also review the notes from class.
Change request familiarization. Carefully read the complete change request document for BugBattle v0.5 before beginning the modifications.
Implementation and documentation
Implement the change request using TDD. You are asked to use a Test-Driven Development approach. We can't force you to do this (especially once you leave the lab) but it really is a much better idea to write the tests first, then the code, working in very small increments, always writing new code against a “red bar” (failing test) and implementing only until you have a “green bar”.
As you create new test classes, add them to the
AllTest test suite. Note that you can run either a single test class or the
AllTest suite, as you prefer. In practice, it's generally better to run all tests after every change — this gives you immediate warning if you break something.
Javadoc as you go. Update the javadoc for your new or modified classes, methods, and attributes as you proceed. You do not need to provide javadoc for your test classes; however, they should be completely self-explanatory. See the provided test classes for examples.
UML design documentation. Provide class and sequence diagrams documenting only what has changed in this version of BugBattle. This means that you do not need to provide a class diagram of the complete system; just class diagrams of the parts of the system that have changed. Similarly, use your judgement in determining what sequence diagrams would be useful to someone trying to learn how your code works. The diagrams are to be included in your PDF lab report and not submitted in separate files. Make sure you include a caption under each diagram and that you refer to the diagram in the body of the text. If necessary, provide explanatory text with your diagrams. You can assume that the reader will also have access to your code and javadoc comments, so don't reproduce anything that should be obvious.
- Report (including UML): 15
- Removal of free energy: 5