Standardize Series 4 sections: remove Summary, rename Key Patterns to Key Design Decisions

Author: workcontrolgit

blogs/series-4-playwright-testing/4.2-playwright-page-object-model.md

@@ -616,19 +616,6 @@ All pagination, search, permission checks, form submission, and success verifica
 
 ---
 
-## 🎓 Summary
-
-The Page Object Model prevents selector duplication by centralizing locators and interactions in classes rather than scattering them across test files.
-
-**The two-level hierarchy in AngularNetTutorial:**
-
-* **`BaseListPage`** — navigation, row access (with header-skip), search, pagination, CRUD clicks, permission checks
-* **`BaseFormPage`** — form waiting, submit, cancel, validation detection, dropdown helper, three-fallback success verification
-* **`EmployeeListPage`** — extends `BaseListPage`, adds readable aliases like `getEmployeeCount()` and `clickEmployee()`
-* **`EmployeeFormPage`** — extends `BaseFormPage`, adds `formControlName`-based locators and `fillForm()`
-
-The result: tests read like user stories. Selectors live in one place. New entities get full test infrastructure by extending two classes.
-
 ## 🌟 Why This Matters
 
 The Page Object Model is the most impactful investment you can make in a test suite's long-term maintainability. A selector change in a component template is a one-file update in the Page Object — not a search-and-replace across twenty test files. The `BaseListPage` / `BaseFormPage` hierarchy means common actions like "click edit", "verify table has rows", and "submit form" are written once and inherited everywhere.

blogs/series-4-playwright-testing/4.3-playwright-role-based-testing.md

@@ -544,7 +544,7 @@ This workflow test also validates **data relationships** — the employee is cre
 
 ---
 
-## 💡 Key Patterns
+## 🔑 Key Design Decisions
 
 **Test RBAC at two layers independently.** Template directives hide buttons. Route guards block navigation. A bug in either layer is a security issue. Test both: "is the button visible?" and "does direct URL navigation get blocked?"
 
@@ -558,17 +558,6 @@ This workflow test also validates **data relationships** — the employee is cre
 
 ---
 
-## 🎓 Summary
-
-Testing RBAC with Playwright means going beyond "can the user log in?" and verifying the entire permission surface:
-
-* **What buttons are visible** — using `isVisible()` to assert presence and absence
-* **What routes are accessible** — using direct URL navigation to bypass the UI
-* **That switching users clears the previous role** — using the cross-role test
-* **That workflow tasks work end-to-end** — using multi-step workflow tests
-
-The three-role structure in AngularNetTutorial (Employee, Manager, HRAdmin) maps cleanly to three `test.describe` blocks, each with its own `beforeEach` login. The cross-role test ties them together by asserting the permission hierarchy in a single browser session.
-
 ## 🌟 Why This Matters
 
 Role-based access control is one of the hardest things to test with confidence. Unit tests can verify that a guard function returns `false` — but only E2E tests can verify that the right buttons appear for the right users, that direct URL navigation is blocked, and that switching users mid-session actually clears the previous role. The three-`describe`-block pattern makes this systematic.

blogs/series-4-playwright-testing/4.4-playwright-jwt-token-testing.md

@@ -520,7 +520,7 @@ Before doing so, consider these design implications:
 
 ---
 
-## 💡 Key Patterns
+## 🔑 Key Design Decisions
 
 **Decode without a library.** `Buffer.from(parts[1], 'base64').toString()` gives you the raw JSON. `JSON.parse()` gives you the claims object. No `jsonwebtoken`, `jwt-decode`, or other dependencies required.
 
@@ -534,19 +534,6 @@ Before doing so, consider these design implications:
 
 ---
 
-## 🎓 Summary
-
-JWT token testing with Playwright fills the gap between "login works" and "the API will accept this token with the right permissions":
-
-* **Two extraction methods** — `getStoredToken()` (browser storage, fast) and `getTokenFromProfile()` (Profile page, robust)
-* **One-liner decode** — `JSON.parse(Buffer.from(parts[1], 'base64').toString())`
-* **Claims to verify** — `sub`, `exp > now`, `iss`, `aud`, `role`, `scope`
-* **Role verification** — each role gets different claims; assert all three
-* **Tamper detection** — swap the signature, expect 401 from the API
-* **Direct API calls** — use the extracted token with `request.get()` for API-layer testing
-
-When IdentityServer configuration changes, these tests tell you before the UI does.
-
 ## 🌟 Why This Matters
 
 JWT token testing fills the gap between "login works" and "the API will accept this token with the right permissions." When IdentityServer configuration changes — a missing `role` claim, a wrong audience, an expired token lifetime — these tests catch it before the Angular UI does. The `payload.exp > now` assertion alone prevents an entire class of silent authentication failures.

blogs/series-4-playwright-testing/4.5-playwright-api-testing.md

@@ -655,7 +655,7 @@ These tests verify that the API accepts pagination and search parameters without
 
 ---
 
-## 💡 Key Patterns
+## 🔑 Key Design Decisions
 
 **`test.beforeAll` for token, `test.afterEach` for cleanup.** Token acquisition is slow — do it once per suite. Record cleanup is per-test — do it after every test, even failing ones.
 
@@ -681,21 +681,6 @@ This simple test catches a common misconfiguration: the API returning HTML error
 
 ---
 
-## 🎓 Summary
-
-Playwright's `request` fixture turns E2E tests into a full API test suite:
-
-* **`getTokenForRole()`** — spins up a temporary headless browser, completes the OIDC flow, returns a real token
-* **`test.beforeAll`** — acquires the token once per suite with a timeout safety net
-* **`test.afterEach`** — deletes records created during the test
-* **Full CRUD** — GET list, GET by ID, POST create, PUT update, DELETE with verify-by-404
-* **Error cases** — 400 invalid data, 404 not found, 401/403 wrong role
-* **Response shape flexibility** — `data.data || data.items || data` normalization
-* **Cache behavior** — `X-Cache-Status` headers, cache invalidation on write, concurrent request consistency
-* **Pagination and search** — query parameter pass-through
-
-The `request` fixture completes the test pyramid: unit tests at the bottom, API tests in the middle, and full E2E UI tests at the top — all within the same Playwright project.
-
 ## 🌟 Why This Matters
 
 Playwright's `request` fixture turns an E2E test suite into a full API test suite — without a second testing framework. The `getTokenForRole()` pattern (headless browser for OIDC token acquisition, then bare HTTP client for API calls) solves the hardest problem in OAuth-protected API testing: getting a real token programmatically when PKCE is the only allowed grant.