Iteration 1: Test-Driven Development I

Deadline

Always at 23.59 on the same day as your TA session (Except if another deadline has been agreed with the TA). Consult the deadline for your class on the delivery plan.

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.

Kata

Spend the first 15-20 minutes of the class in plenum discussing...

When doing TDD the One Step Test principle is important: the next test you pick from the Test List should not be too complex ("I have no idea how to do it") nor should be too simple ("This is obvious/already implemented") but should teach you something and move development forward = add new production code.

Consider the following few potential items on a test list (picked partially from the list below), and discuss what constitutes good 'one step tests' for the first, the second, on so on, iterations of the TDD rhythm:

Given an initialized game, Then Findus' Hero has Mana 3 and Health 21.
When Findus ends its turn, Then it is Peddersen in turn
Given Peddersen has played Uno, and Findus has played Tres, When Findus attacks Uno with Tres, Then Uno is removed from Peddersen's field and Findus' Tres is on Findus' field with health 2.
Given an initialized game, When Findus' Hero uses hero power then the hero has Mana 1 and is no longer able to use power.
Given an initialized game, Then Findus is player in turn
Given an initialized game, then Dos is at index 1 in Findus' hand.
Given Findus has played Tres, Then Dos cannot be played And NOT_ENOUGH_MANA is returned.
Given Findus's Hero has used power in first turn, when it is again Findus' turn, then Hero is again able to use power.

Discuss and argue for

Propose/discuss plausible orderings or 'paths' for picking test cases to develop ("ala pick #1 and then #3 and then #2...") to stick to the 'one step test' principle.
Are there 'one step tests' paths that are equally valid to start out with ("ala path 1 = #1 then #3 then #2 is just as good a starting point as as path 2 = #4 then #7 then #6)?
Proprose a sequencing that is a "bad path" to take, and argue why.
Propose a sequence that could result in a lot of Fake-it till you make it code piling up in the production code without any real triangulation happening (Bærbak's note: which is really bad and must be avoided! - Argue why.)

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, Then it is allowed (Status.OK), and Then minion Uno appears at index 0 on the 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 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.). 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).