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 to use Git for release management, and continued training in TDD.
Remember, there are information on how to import HotCiv into AU GitLab on the 'Tools' page.
Unfortunately, I forgot to install Git in the virtual machine, so if you use that, you have to
sudo apt install gitas a first step before starting on any git stuff.
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. The score counts towards your final grade.
|Learning Goal||Assessment parameters|
|Submission||Git repository can be pulled. The release branch/tag "Release2.1" exists and represents the code release. Git repository is not public! Code must compile; 'gradle test jacocoTestReport' must pass; 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.). A work flow/branching strategy has been selected and used correctly to hotfix and release "Release2.1".|
|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 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 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 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 an vice versa; there are understandable overview comments in the code).|