A framework isn't finished when it works — it's finished when someone else can
extend it without reading every file. "Maturation" is that last mile: filling
coverage gaps and writing the docs that make the project approachable.
Code for this chapter is tagged
ch-24in the repo:
https://github.com/aktibaba/playwright-qa-course — see the new
profile-and-feed/article-filtersspecs anddocs/reference/framework.md.
Rounding out coverage
We fill the obvious gaps with flows that reuse everything we've built:
- Profile — an author's article shows on their profile page.
- Global feed & tag filter — toggling the feed and clicking a tag.
- Editing — open the editor for an existing article and save a change.
- API list filters — by author, the empty case, and the personalised feed.
A couple of these reinforced a lesson worth burning in: keep assertions deterministic
under parallelism. The danger is asserting on a specific item's position in a list
that other tests are changing at the same time:
// ❌ fragile: the unfiltered feed shows only a few newest articles, and other
// tests are adding articles right now — yours may not be on the page.
await expect(page.getByRole("heading", { name: article.title })).toBeVisible();
// ✅ robust option A: assert the behaviour, not a specific item
await expect(globalFeed).toHaveClass(/active/); // the toggle worked
await expect(page.locator(".preview-link").first()).toBeVisible(); // some article rendered
// ✅ robust option B: isolate, so only YOUR data matches
const author = await registerUser(api); // a brand-new user
const article = await createArticleAs(author.token);
await page.goto(`/#/profile/${author.username}`); // their profile has exactly one article
The new createArticleAs(token, …) helper creates an article authored by a specific
user — the building block that makes an isolated profile or author-filter test possible.
Docs that make it extendable
Finally, a framework reference — one page that maps the
layers, states the rules (the dependency direction, the determinism rules), and answers
"how do I add a test / Page Object / fixture / data factory?". With the repo's README,
a newcomer can be productive in minutes instead of digging through files.
Good docs capture the decisions the code can't explain on its own: why tests import
only from @fixtures, why no test resets the database, why you never assert on a
list position. That's what keeps a maturing framework from drifting back into chaos.
Next up
Everything is in place — and the results are visible. Chapter 25 — Reporting: a
dedicated look at turning raw results into something a team acts on, including a custom
Playwright reporter. Then Chapter 26 is the grand Capstone — a full end-to-end
regression tying every technique together. Tag: ch-25.
Following along? Star the repo
and tell me what you'd put in your framework's onboarding doc.
Top comments (0)