Iteration 1: Test-Driven Development I

Deadline

At 23.59 on the day that your class has agreed with the TA.

Any late hand-in must be agreed with your TA; failing to do so will allow the TA to reject evaluating your hand-in.

Workload Estimate

High

Learning Goals

Training in test-driven development (TDD), using AlphaStone as case.

Prerequisites

Carefully read FRS § 37.1 and 37.2. Regarding 'Provided Code' base your development upon the starter HotStone code in the ZIP file from the link in the Iteration 0 page.

Exercises

Test-Driven Development Part I

Based upon the skeleton code develop much (50% - 70%) of the AlphaStone variant's behaviour using the test-driven development process. (You will continue the development of AlphaStone in the next mandatory iteration, and it is actually recommended to leave features out so you have work to do next week.)

In this exercise, the learning objective is practicing the TDD process: the rhythm, the principles, and the values of taking small steps, keep focus, and speed. Do not design ahead in anticipation of future requirements (in the later learning iterations), but remember simplicity. Please consult sidebar 35.1 in FRS on how to organize your team work. To get you going, the following incomplete test list is given as inspiration:

Given an initialized game, Then Findus is player in turn
When Findus ends its turn, Then it is Peddersen in turn
When game starts Then Findus should have three cards in hand, Tres at index 0, Dos at index 1, and Uno at index 2.
Given Card Dos Then it has attributes (2,2,2)
Given a game When Findus plays Uno at index 0, Then it is allowed (Status.OK), and Then minion Uno appears at index 0 on the player's own field.
When Peddersen plays Dos, Then the mana available is two less.
When Findus plays a card, Then Peddersen still has 3 cards in his hand.
etc.

Hint: The specification may contain ambiguities (as any real world specification will). You may resolve them by talking to your "customer": the course instructor. Alternatively you may decide on an appropriate interpretation with your team mates. It is perfectly fine to adopt an interpretation of 'least-effort'...

Deliveries:

Create an approximately 6-12 minutes long screencast with audio narration, outlining one or a few interesting TDD iteration(s) from your AlphaStone development. The screencast must be structured with
1. Intro: State your names and group name
2. Shortly outline what you achieved in the last TDD iteration of AlphaStone, briefly showing the test list items and associated code.
3. State the purpose of this iteration
4. Do the iteration, and follow and refer to TDD principles applied and the 5 steps of the rhythm as you go. (Say out loud: "Now we quickly add a test", add the test and explain what it does as you code it - if you "fake it" then say that, if you "triangulate" then say that, etc.; mention that you now "run test and see it fail", etc.)
5. Conclude
Deliver the code as a ZIP that extracts correctly, and runs all JUnit test cases with code coverage 'out-of-the-box.' If the TA cannot just a) unzip and b) run 'gradle test jacocoTestReport' then the hand-in is rejected!
Deliver your test list (as text/pdf/word if electronic; take a picture of it if on paper.)
Deliver your product backlog (*) of functional AlphaStone requirements (as text/pdf/word) that you did not manage to get done in this iteration.

(*) A product backlog is a list of pending work items that will be handled in the next iteration. See FRS §5.11.

Screencasting advice

I introduced screencasts instead of written reports for two reasons:

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.
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

Zip the code/checking into your Git repository before each iteration.
Do a TDD iteration. If it 'feels good to be screencasted', then rewind the code using unzip/git.
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.
Do not retake the screencast endlessly! The point is demonstrating that you are learning the process, not that the screencast itself is 'polished perfect'.

Code advice and hints

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 AlphaStone game product! Report missing features in the backlog, and get them done in the next iteration.

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.

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 evident (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.). JUnit Test cases are formulated using the Given-When-Then template. 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 AlphaStone 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.