Iteration 2: Test-Driven Development II and Git

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.

Learning Goals

Learning to use Git for release management, and continued training in TDD.

Exercises

GitLab SCM

Put AlphaStone under software configuration management control using Git and AU GitLab as repository/"origin" hosting.

Be sure to create a feature branch, named iteration2, (and optionally, an associated GitLab Merge Request,) and make your AlphaStone (continued) TDD work happen there.

Ensure that your repository is private and that your TA is granted clone/read access ('Reporter', not only 'Guest') so they can pull your repository.

Note: Quite a lot of software engineering trickery is involved, and a lot can go wrong. Remember, that specific and detailed screencast guides are available - find the links on Weekplan 2.

TDD Part II

Continue your TDD and finish (or nearly finish) your AlphaStone implementation. (None or a few, minor, features on the backlog.) Take small steps, commit often :)

Release your AlphaStone by merging the merge request back into the main branch.

Deliveries:

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 2 Grade sheet to evaluate your submission.

Learning Goal Assessment parameters
Submission Git repository can be pulled. Git repository is not public! Required artifacts (screencasts, backlog, repository link) must all be present. The quality of screencast (video, audio) is OK.
Git and Work flow Repository is set up correctly. Repository is clean of derived artifacts (class-files, test output, etc.). The feature branch iteration2 exists (optionally, with associated merge request). Final release is merged into main branch.
Git Log Commit log shows relevant activity by all group members. Commit log messages express the actual work task carried out for each commit.
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 up (and referred to). Commits in Git are made often (reflecting TDD iterations or similar small chunks of self-contained and focused work tasks).
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.). The production code is 'well' covered by test code (JaCoCo coverage is 'green' for production code (some yellow lines allowed for branches)).
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 an vice versa; there are understandable overview comments in the code.