Iteration 1: Test-Driven Development I


Always at 23.59 on the same day as your TA session. (Except Monday classes)

Consult the deadline for your class on the delivery plan.

Learning Goals

Training in TDD.


Solve FRS 36.1 sub question 1 - that is, develop much (50% - 70%) of AlphaCiv using Test-Driven Development (TDD). (You will continue the development of AlphaCiv in the next mandatory iteration, and it is actually recommended to leave features out so you have work to do next week.)

Deliveries: Sub question FRS 36.1 sub question 2 ('write a report') is replaced by the following requirements:

Screencasting advice

I introduced screencasts instead of written reports for two reasons

  1. TDD is a process - it unfolds over time! Screencasts capture the time dimension which a report cannot. So - it is the better medium for showing what you do.
  2. I hypothesized that capturing a 10 minute screencast would be significantly less time consuming than writing a detailed report.

Regarding the last point, some students fall into a trap of over-doing the screencast (negative feedback in evaluation mention things like spending 4 hours to create a storyboard for the screencast, solve all exercises to ensure they are correct, make a manuscript, rehearse the manuscript, and then make the screencast).

I advice you to create well structured but not polished screencasts. So

  1. Zip the code/checking into your Git repository before each iteration.
  2. Do a TDD iteration. If it 'feels good to be screencasted', then rewind the code using unzip/git.
  3. Structure the screencast as outlined above in the exercise description. You may have the PDF of the TDD principles open so you can point your mouse to a relevant TDD step or principle as you go along, and similar with a text file with your test list. You may also subtitle the screencast but that is probably pretty time consuming work.
  4. Do not retake the screencast endlessly! The point is demonstrating that you are learning the process, not that the screencast itself is 'polished perfect'.

I have made an example, that you may find inspiration from: Demo of TDD Iteration Screencast (in Danish). Note how you can use the mouse to highlight theory (process, principles, test list items, etc.) while you speak, aaaand that minor "weird events" are OK (like when my "take a break - Henrik" app pops up in the middle of things).

Code advice and hints

Note: AlphaCiv is 'trivial but not simple' in the sense that it contains no hard programming problems to solve, but rather quite a lot of 'rye-bread-programming' in which you need to sweep/loop over the game world data structure. If your code a sweep algorithm skills are rusty, have a look at my W1-5 Sweep slides.

And remember, it is perfectly OK not to implement all functional requirements as long as you ensure your TDD process is as good as possible and that your code is "clean code that works". This is an exercise to train your TDD programming skills, not an industry job to produce an AlphaCiv game product! Report missing features in the backlog, and get them done in the next iteration.

You may find the AlphaCiv Game World image below helpful.

Also, unit production requires units to be placed on empty tiles around the city, starting from the tile just north of the city, continuing clockwise to find an empty place. It is a fun little TDD exercise on its own right (a typical 'Child Test'), but if you get overwhelmed, you may take the short cut, and use my 8 neighborhood iterator which allows you to write code like

for (Position p : Utility.get8neighborhoodOf(new Position(3,4))) {
  // use p

That is, the above for loop will loop over the 8 tile positions around (3,4) in the way AlphaCiv specifies: North, and then clockwise. It will of course not iterate over invalid tile positions., copy it to your production code tree in package 'hotciv.utility'.

My TDD of it is available in

Evaluation criteria

Your submission is evaluated against the learning goals and adherence to the submission guidelines. The grading is explained in Grading Guidelines. The TAs will use the Iteration 1 Grade sheet to evaluate your submission. The score counts towards your final grade.

Learning Goal Assessment parameters
Submission Code must compile; 'gradle test jacocoTestReport' must pass; required artifacts (screencasts, backlog, test list) must all be present. The quality of screencast (video, audio) is OK.
TDD Process Code is written 'test-first'; TDD Rhythm is followed (and referred to in screencast); TDD Principles are applied (and referred to); TDD values are used (and referred to); code is cleaned (or referring to future clean ups).
Test Code The test code is simple (no complex constructs, basically only assignments, simple private method calls, very basic for loop). The test code reflects using the TDD principles (Isolated Test, Evident Test, Evident Data, etc.). The production code is 'well' covered by test code (JaCoCo coverage is 'green' for most production code (some yellow lines allowed for branch statements)).
Production Code Missing features are described in the backlog! There is no Fake-it code (or it is adequately described in the backlog). The covered AlphaCiv requirements are correctly implemented ('simplest interpretation' is fine in case of ambiguities; minor deviations acceptable). The production code has been 'cleaned up' to avoid duplicated code. The production code follows guide lines from Barnes and Koelling (No side-effects/mutation in accessor methods; source code follows Java conventions; identifiers/names make sense for the abstractions they model; no use of 'magic constants'); no test code has been put in the 'src' tree and vice versa; there are understandable overview comments in the code).