𝟭. 𝗪𝗵𝗮𝘁 𝗜𝘀 𝗮𝗻 𝗔𝘀𝘀𝗲𝗿𝘁𝗶𝗼𝗻?

An assertion is the check you make after something happens. In a manual test you do a step, then you look at the screen and compare it with the expected result. If you click Save and the page still says the invoice is not saved, the test fails. The click is not the result.

Playwright Test writes that check with expect(). You give expect a locator, which is a description of an element, and then a matcher. A matcher is the condition you want to be true. toHaveText checks exact text. toBeVisible checks that an element is shown.

These locator checks are web-first assertions. A web-first assertion retries until the condition is true or time runs out. This project sets that limit to five seconds in playwright.config.ts.

You can reverse a matcher with not. expect(status).not.toHaveText('Invoice failed') fails when that wrong sentence is present. Use not when the result you need is the absence of a message.

𝟮. 𝗪𝗵𝘆 𝗗𝗼 𝗪𝗲 𝗡𝗲𝗲𝗱 𝗜𝘁?

Pressing the button on a coffee machine is an action. Looking in the cup to see that coffee is there is the assertion. If you only press the button, you cannot tell a full cup from an empty one.

Clicking Save invoice asks the page to save. It does not prove the save worked. A test that ends on the click can pass while the status still says "Not saved". The expected result has to be its own check.

𝟯. 𝗜𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻

Start with the check alone. The matcher requires the words "Invoice saved".

getByRole('status') finds the message a person would read after saving. expect and toHaveText form the web-first check. Playwright keeps looking until the text matches or five seconds pass.

The practical test opens the local demo, confirms the starting message, clicks, and checks the new message. goto('/assertions') uses baseURL from the Playwright config.

goto opens the page. The first toHaveText records the start, "Not saved", so a later pass cannot come from text that was already there. click is only the action. The second toHaveText is the result of that action. The script does not also check that the text is not "Invoice failed". The exact success message already answers that question.

𝟰. 𝗘𝘅𝗽𝗲𝗰𝘁𝗲𝗱 𝗥𝗲𝘀𝘂𝗹𝘁

A passing run starts at "Not saved", clicks Save invoice, and ends with "Invoice saved". A failing run means one of those texts did not match before the five-second assertion timeout.

𝟱. 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀

• click performs an action. expect() checks the result.

• A matcher such as toHaveText states the expected result.

• Web-first assertions retry until they pass or the timeout ends.

• Use not when the result is the absence of a specific message.

𝗜𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻: What is the difference between clicking Save and asserting the status text?

𝗔𝗻𝘀𝘄𝗲𝗿: The click performs the action. The assertion checks the expected result. Without that check, a test can pass when the save changed nothing the user can see.

𝟲. 𝗥𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲𝘀

• https://playwright.dev/docs/test-assertions

• https://playwright.dev/docs/api/class-locatorassertions

𝗗𝗔𝗬 𝟭𝟮 𝗢𝗙 𝟯𝟬𝗗𝗔𝗬𝗦

𝗧𝗵𝗲 𝟰 𝗘𝘀𝘀𝗲𝗻𝘁𝗶𝗮𝗹 𝗛𝗮𝗻𝗱𝗼𝘃𝗲𝗿 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝘀 𝗘𝘃𝗲𝗿𝘆 𝗙𝗿𝗲𝗲𝗹𝗮𝗻𝗰𝗲 𝗪𝗲𝗯 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿 𝗠𝘂𝘀𝘁 𝗙𝗼𝗹𝗹𝗼𝘄

Never finish a web project by just sending login credentials. A professional handover includes:

1. A customized 5-minute Loom walkthrough showing client copy edits.

2. Automated cloud backup setup.

3. Clear DNS and custom domain ownership transfer.

4. A 14-day post-launch support window. This turns one-off clients into recurring retainer contracts.

𝗦𝗮𝘃𝗲 𝘁𝗵𝗶𝘀 𝗰𝗵𝗲𝗰𝗸𝗹𝗶𝘀𝘁 𝘁𝗼 𝗲𝗹𝗲𝘃𝗮𝘁𝗲 𝘆𝗼𝘂𝗿 𝗰𝗹𝗶𝗲𝗻𝘁 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲!

This is literally one of teh best way of making a design/work handover to client. Lve this approach