update content

Author: rieckpil

labs/lab-7/README.md

@@ -2,16 +2,16 @@
 
 ## Learning Objectives
 
-- Configure JUnit 5 parallel test execution via `junit-platform.properties`
-- Understand the difference between JUnit 5 thread-level parallelism and Maven Surefire `forkCount` process-level forking
+- Configure JUnit 6 parallel test execution via `junit-platform.properties`
+- Understand the difference between JUnit 6 thread-level parallelism and Maven Surefire `forkCount` process-level forking
 - Identify and fix test isolation issues caused by shared database state
 - Apply `@Transactional` and UUID-based unique data as complementary isolation strategies
 
 ## Key Concepts
 
-### JUnit 5 Parallel Execution
+### JUnit 6 Parallel Execution
 
-JUnit 5 supports running tests in parallel at both the class level and the method level. Configuration lives in `src/test/resources/junit-platform.properties`.
+JUnit 6 supports running tests in parallel at both the class level and the method level. Configuration lives in `src/test/resources/junit-platform.properties`.
 
 There are two independent axes of parallelism:
 
@@ -71,12 +71,12 @@ src/test/resources/
 
 ### Exercise 1: Configure and Observe Parallel Test Execution
 
-Understand JUnit 5 parallel execution configuration and observe its effect on thread allocation.
+Understand JUnit 6 parallel execution configuration and observe its effect on thread allocation.
 
 **Tasks:**
 1. Open `src/test/resources/junit-platform.properties` and review the current settings
 2. Open `Exercise1ParallelExecutionTest.java` — the test methods print the current thread name
-3. Run `mvn test` and observe which threads each test class runs on in the console output
+3. Run `mvn test` or within IntelliJ and observe which threads each test class runs on in the console output
 4. Try different parallelism strategies by modifying `junit-platform.properties`:
    - Classes concurrent, methods `same_thread` (current default)
    - Both classes and methods `concurrent`

labs/lab-7/src/test/java/pragmatech/digital/workshops/lab7/exercises/Exercise1ParallelExecutionTest.java

@@ -9,6 +9,7 @@
  * <ol>
  *   <li>Check the junit-platform.properties file in src/test/resources</li>
  *   <li>Run all tests and observe parallel execution in the log output</li>
+ *   <li>Consult <a href="https://docs.junit.org/6.0.3/writing-tests/parallel-execution.html">JUnit Docs</a></li>
  *   <li>Experiment with different parallelism strategies:
  *     <ul>
  *       <li>a) Classes concurrent, methods same_thread (default - current setting)</li>

labs/lab-7/src/test/java/pragmatech/digital/workshops/lab7/exercises/Exercise2TestIsolationTest.java

@@ -19,7 +19,6 @@
  *
  * <p>Tasks:
  * <ol>
- *   <li>Identify tests that fail when run in parallel (shared database state)</li>
  *   <li>Apply isolation strategies:
  *     <ul>
  *       <li>a) Use @Transactional for automatic rollback after each test</li>

slides/assets/newsletter-signup-qr.png

@@ -46,7 +46,7 @@ Philip Riecks - [PragmaTech GmbH](https://pragmatech.digital/) - [@rieckpil](htt
 - 9:00 - 10:30: **Integration Testing Continued - Verify the Entire Application**
 - 10:30 - 11:00: **Coffee Break & Time for Exercises**
 - 11:00 - 12:30: **Understanding Spring TestContext Context Caching for fast Tests**
-- 12:30 - 13:30: **Lunch**
+- 12:30 - 13:30: **Lunch & Time for Exercises**
 - 13:30 - 15:00: **Strategies for Fast and Reproducible Spring Boot Test Suites**
 - 15:00 - 15:30: **Coffee Break & Time for Exercises**
 - 15:30 - 16:30: **General Spring Boot Testing Tips & Tricks and Q&A**
@@ -461,4 +461,5 @@ pragmatech.digital.workshops.lab5.experiment.customizer.SharedInfrastructureCust
 - Navigate to the `labs/lab-5` folder and complete the tasks in the `README`
 - **Exercise 1**: Implement an integration test with `MockMvc` (MOCK environment, `@Transactional`)
 - **Exercise 2**: Implement the same scenario with `WebTestClient` (RANDOM_PORT, manual cleanup)
+- **Exercise 3** (Optional): Implement the exercise from lab 4 to learn how to use WireMock
 - Time boxed: until the end of the coffee break

slides/assets/tsbad-cover.png

@@ -45,7 +45,7 @@ Philip Riecks - [PragmaTech GmbH](https://pragmatech.digital/) - [@rieckpil](htt
 
 **Goal**: Reduce build time by running tests concurrently
 
-Two independent mechanisms — they work at different levels:
+Two independent mechanisms - they work at different levels:
 
 | Mechanism | Level | Isolation |
 |---|---|---|
@@ -70,9 +70,9 @@ Splits tests across multiple **separate JVM processes**:
 </plugin>
 ```
 
-- `forkCount=1` — default: one JVM for all tests
-- `forkCount=2` — two JVMs running in parallel
-- `forkCount=1C` — one JVM per available CPU core (dynamic)
+- `forkCount=1` - default: one JVM for all tests
+- `forkCount=2` - two JVMs running in parallel
+- `forkCount=1C` - one JVM per available CPU core (dynamic)
 
 > **Maven Failsafe** works the same way for `*IT.java` integration tests.
 
@@ -266,9 +266,7 @@ class BookIT {
 
 ---
 
-## Optimize Containers Time
-
-### Correct Usage of Testcontainers
+# Correct Usage of Testcontainers
 
 ---
 
@@ -402,9 +400,7 @@ testcontainers.reuse.enable=true
 
 ## Tip 1: Hide Test Output, Show on Failure
 
-By default, all test output floods the console. 
-
-Redirect it to files:
+By default, all test output floods the console. We can redirect it to files:
 
 ```xml
 <plugin>
@@ -417,6 +413,14 @@ Redirect it to files:
 </plugin>
 ```
 
+```yaml
+# as a last step on GitHub actions
+- name: Log test output on failure
+  if: failure() || cancelled()
+  run: find . -type f -path "*test-reports/*-output.txt" -exec tail -n +1 {} +
+
+```
+
 ---
 
 ## Tip 2: Rerun Flaky Tests Automatically
@@ -533,6 +537,90 @@ Separate CI-specific settings from the default developer experience:
 
 ---
 
+## GHA Workflow Design: Start Pragmatic
+
+One file, one workflow - perfectly fine for most projects:
+
+```yaml
+# .github/workflows/build.yml
+name: Build
+on: [push, pull_request]
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    timeout-minutes: 20
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-java@v4
+        with: { java-version: '21', distribution: 'temurin', cache: maven }
+      - run: ./mvnw verify
+```
+
+**Start here.** Measure total build time. Only split when you have a concrete reason (too slow, unrelated failure domains, different schedules).
+
+---
+
+## GHA Workflow Design: When to Split
+
+Once the single workflow grows unwieldy, extract by **concern and cadence**:
+
+```text
+.github/workflows/
+  build.yml          ← on: push/PR — compile + unit + integration tests
+  coding-standards.yml ← on: push/PR — Checkstyle, SpotBugs, ArchUnit
+  nightly.yml        ← on: schedule — slow E2E, mutation tests, full matrix
+  deploy.yml         ← on: push to main — build image + deploy to staging
+```
+
+Separate workflows run **in parallel** automatically - no extra config needed.
+
+---
+
+## Off-topic: pre-commit — Catch Issues Before You Push
+
+[pre-commit](https://pre-commit.com) runs checks automatically on `git commit`, before code ever reaches CI:
+
+```yaml
+repos:
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    hooks:
+      - id: check-yaml
+      - id: end-of-file-fixer
+      - id: trailing-whitespace
+  - repo: https://github.com/ejba/pre-commit-maven
+    hooks:
+      - id: maven
+        args: ['-f pom.xml spotless:apply']
+``` 
+
+Style violations and formatting errors fail **locally in milliseconds** - not 5 minutes into a CI run. Less noise in PRs, faster feedback loop.
+
+
+---
+
+## Best Practice 0: Never Go Stale
+
+**Deploy or run at least once a week** - even if nobody pushed code.
+
+```yaml
+# .github/workflows/nightly.yml
+name: Nightly Verification
+on:
+  schedule:
+    - cron: '0 3 * * 1'   # Every Monday at 03:00 UTC
+  workflow_dispatch:       # Allow manual trigger
+
+jobs:
+  verify:
+    runs-on: ubuntu-latest
+```
+
+Stale pipelines break silently: secrets expire, base images get security patches, dependency resolution drifts. A weekly run catches this **before** it blocks a real release.
+
+---
+
+
 ## Best Practice 1: Always Set a Job Timeout
 
 Hanging Testcontainers or infinite loops block CI slots for hours without a timeout:

slides/lab-5.md

@@ -82,7 +82,7 @@ class OutputCaptureTest {
 
 ---
 
-# Mutation Testing with PIT
+## Mutation Testing with PIT
 
 **The problem:** 100% line coverage ≠ good tests. Weak assertions can still pass.
 
@@ -99,15 +99,13 @@ void shouldReturnFee() {
 ```bash
 cd labs/lab-8
 ./mvnw pitest:mutationCoverage
-# Opens target/pit-reports/index.html
+# Open target/pit-reports/index.html
 ```
 
-> **A mutation is "killed"** when at least one test fails because of the mutation.
-> **A surviving mutant** exposes a gap in your test suite.
 
 ---
 
-## PIT in Action — `LateReturnFeeCalculator`
+## PIT in Action - `LateReturnFeeCalculator`
 
 ```java
 // Production code with multiple fee tiers
@@ -125,7 +123,8 @@ public BigDecimal calculateFee(Book book, LocalDate borrowedDate) {
 
 **PIT mutates conditionals** (`<= 7` → `< 7`, `<= 14` → `< 14`) — boundary tests are essential.
 
-**Pro tip:** Use `Clock` injection instead of `LocalDate.now()` for deterministic tests.
+> **A mutation is "killed"** when at least one test fails because of the mutation.
+> **A surviving mutant** exposes a gap in your test suite.
 
 ---
 
@@ -194,21 +193,14 @@ class RecordApplicationEventsTest {
 
 ## `ApplicationContextRunner`
 
-Test **auto-configuration and conditional beans** without starting a full Spring Boot context.
+Test **auto-configuration and conditional beans** without starting a full context.
 
 ```java
 class ApplicationContextRunnerTest {
 
   private final ApplicationContextRunner contextRunner = new ApplicationContextRunner()
     .withUserConfiguration(ConditionalBookImportConfig.class); // ← Minimal slice
 
-  @Test
-  void shouldNotHaveBookImportBeanWhenPropertyIsAbsent() {
-    contextRunner.run(context ->
-      assertThat(context).doesNotHaveBean("bookImportEnabled")
-    );
-  }
-
   @Test
   void shouldHaveBookImportBeanWhenPropertyIsEnabled() {
     contextRunner
@@ -220,7 +212,7 @@ class ApplicationContextRunnerTest {
 }
 ```
 
-**Runs in milliseconds** — ideal for testing `@ConditionalOnProperty`, `@ConditionalOnClass`, `@ConditionalOnMissingBean`.
+**Runs in milliseconds** - ideal for testing `@ConditionalOnProperty`, `@ConditionalOnClass`, `@ConditionalOnMissingBean`.
 
 ---
 
@@ -253,7 +245,7 @@ class ApplicationContextRunnerTest {
 
 ---
 
-## ArchUnit — Code Examples
+## ArchUnit - Code Examples
 
 ```java
 @AnalyzeClasses(
@@ -535,7 +527,7 @@ log.info("Book created");
 **Good observability checklist:**
 - Structured JSON logs (Logback + `logstash-logback-encoder`) shipped to a central store
 - Dashboards scoped to **error rate**, **p99 latency**, and **business KPIs** - not CPU graphs
-- Runbooks linked directly from alert notifications
+- [Runbooks](https://github.com/stratospheric-dev/stratospheric/tree/main/docs/runbooks) linked directly from alert notifications
 
 ---
 
@@ -556,13 +548,6 @@ commit → CI (tests pass) → build image → push to registry
 
 ---
 
-**Rollback triggers to Monitor**
-- Health check endpoint (`/actuator/health`) returns non-200 for > 60 s after deploy
-- Error rate spikes above baseline within the first 5 minutes
-- P99 latency exceeds SLO threshold post-deploy
-
----
-
 ## Blue/Green & A/B Deployments
 
 **Blue/green** eliminates downtime and provides instant rollback: run two identical environments, flip the load balancer, keep the old environment warm.
@@ -600,7 +585,9 @@ Requires feature-flag or traffic-splitting infrastructure (Nginx, Istio, AWS ALB
 ## Feature Flags: Decouple Deployment from Release
 
 **Deployment** = shipping code to production. 
-**Release** = making a feature visible to users. Feature flags let you do both independently.
+**Release** = making a feature visible to users. 
+
+Feature flags let you do both independently.
 
 ```java
 if (featureFlags.isEnabled("new-book-search", userId)) {
@@ -728,6 +715,23 @@ The goal is not zero failures - it is **fast, automatic recovery** when failures
 
 ---
 
+## Don't Leave Empty-Handed
+
+![bg h:720 w:450 right:33%](assets/tsbad-cover.png)
+
+
+- Get the complementary **Testing Spring Boot Applications Demystified** for free
+
+- 120+ Pages with practical hands-on advice to ship code with confidence
+
+- Get the eBook by joining our [newsletter](https://rieckpil.de/free-spring-boot-testing-book/) and receive further Spring Boot testing-related tips & tricks
+
+![center h:200 w:200](assets/newsletter-signup-qr.png)
+
+---
+
+<!-- paginate: false -->
+
 ## Joyful Testing!
 
 Workshop materials are on [GitHub](https://github.com/PragmaTech-GmbH/digdir-workshop/).