SWEA 2025 Weekplan 2

The learning goals for Week 36 are:

Mon: (at 9.15) Mandatory Hints. Motivation for SCM. Wed: Release and Branching Strategies, Git. Build Management, Gradle.

Literature:

• [FRS, 2023] Mandatory: Chapter 33.
• [FRS, 2023] Mandatory: Chapter 6.
• [Driessen, 2010] Optional: Full paper (A successful Git branching model)

Slides:

• W2-1a SCM Motivation (powerpoint) // (PDF)
• W2-1b SCM Version (powerpoint) // (PDF) // Associated Screencast
• W2-1c SCM Collaboration (powerpoint) // (PDF) // Associated Screencast
• W2-1d SCM Examples (powerpoint) // (PDF) // Associated Screencast
• W2-2 Git (powerpoint) // (PDF)
• W2-3 Release Management (powerpoint) // (PDF)
• W2-4 Build Management (powerpoint) // (PDF)
• W2-5 Mandatory Hints (powerpoint) // (PDF)

Notes for this weekplan:

From now on, the monday lecture is one lesson only, from 9.15 to 10.00, unless explicitly stated.

The monday lecture will start with a TDD motivation and 'mandatory hints' section so all classes can benefit before handing in.

Most of the 'concepts-and-terms-slides' for Software Configuration Management (SCM) are screencasts that will NOT be repeated in the Auditorium (those with an additional 'Associated Screencast' link above) but only summerized in 2½ slides. Instead I will Wednesday focus our time on showing how git and github flow is used in the mandatory project to handle a 'continuous integration' release management strategy.

As a supplement/alternative to these lessons on Git and Release Management/GitHub Flow, the following screencasts provides specific guidance to their usage in the mandatory project:

1. Importing HotStone into AU GitLab (10½ min)
2. Cloning HotStone from AU GitLab (3 min)
3. GitHubFlow: Create and Merge Iteration Branch (12 min)

Unfortunately, some buttons you see in the screencast has moved a bit, but you should be able to finde the 'Invite members' and 'Code' buttons on the pages. (Also I use the ReadMe file in the screencasts which unfortunately is missing in the E25 HotStone release. Never-the-less the ideas are the same.)

There is some confusion around regarding the 'GitHub Flow' name, as it is not tied to GitHub. We just use the "model for how to handle releases and development branches" it defines on our AU GitLab server (as it is fully supported). To make things even worse, there is also a more complex model named "GitLab Flow" which is also not tied to neither GitLab nor GitHub. Sigh.

Note that the 'continuous delivery' release management model / GitHub Flow model has unfortunately not made it into the current release of chapter 33 - refer to the slides instead.

Kata

Spend the first 15-20 minutes of the TØ/Lab 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 mandatory's Iteration 1 list), and discuss what constitutes good 'one step tests' for the first, the second, on so on, iterations of the TDD rhythm:

1. Given an initialized game, Then Findus' Hero has Mana 3 and Health 21.
2. When Findus ends its turn, Then it is Peddersen in turn
3. 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.
4. Given an initialized game, When Findus' Hero uses hero power then the hero has Mana 1 and is no longer able to use power.
5. Given an initialized game, Then Findus is player in turn
6. Given an initialized game, then Dos is at index 1 in Findus' hand.
7. Given Findus has played Tres, Then Dos cannot be played And NOT_ENOUGH_MANA is returned.
8. 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

1. 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.
2. 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)?"
3. Proprose a sequencing that is a "bad path" to take, and argue why.
4. 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.)

Optional Exercises:

These are optional exercises. Be sure to solve the mandatory project first, and only if you have a lot of spare time, try having a look at the exercises below.

(6.5) 6.6 6.7 (6.8)