I've published three new posts on Test Automation TV's free practice site. Two are hands-on Playwright tutorials and one is about careers. Every code example runs against the practice site, so you can copy the tests and run them without setting anything up.
1. Playwright API Testing for Beginners: The request Fixture
If your UI tests feel slow or flaky, API tests are a good place to start. They run in milliseconds and check things the UI often hides. The post shows how to:
- Send GET, POST and PUT calls with no browser, using Playwright's built-in
requestfixture - Assert on exact status codes and JSON bodies, not only
toBeOK()
- Log in with a session cookie, or with Basic Auth (and why
send: 'always'matters) - Test the unhappy paths: 401, 403 and 404
- Combine API and UI: create data through the API and check it on the page, or log in through the API and skip the login form
Here is the smallest useful example from the post:
test('accepts a valid email address', async ({ request }) => {
const response = await request.post('/api/validate-email', {
data: { email: 'ada@example.com' },
});
expect(response).toBeOK();
expect(await response.json()).toEqual({ message: 'Valid email address', valid: true });
});2. Testing Rate Limits and 429s in Playwright
This one builds on the first post, so read them in order. Rate limits work perfectly until the day they don't, and the post covers both sides:
- The server side: prove that the sixth request returns a 429 with a valid
Retry-Afterheader, then prove the limit lifts afterwards - The client side: check that the page shows a countdown and disables its buttons while it waits
- A pattern worth stealing: fake the 429 with
page.route()and fast-forward time withpage.clock, so a 30-second wait finishes in about two seconds. It works for any slow or hard-to-trigger response, such as timeouts, expired sessions and maintenance pages. - Flakiness traps: parallel workers sharing one quota, and limiters that count per server process
There's a dedicated page to practise on: Rate limit & 429 practice page.
3. Laid Off as an SDET? 10 Career Paths Beyond Driving an Uber
Less code, more career. Layoffs have hit a lot of people in QA, and SDET skills transfer further than most of us realise: real programming, systems thinking, CI/CD, debugging under pressure and an instinct for what can go wrong.
The post walks through ten paths:
- Performance engineer
- QA automation engineer, aimed at a new industry
- AI test engineer
- DevOps engineer
- Data engineer
- Security engineer
- Product manager
- Release engineer
- Build engineer
- Technical support engineer
For each one it names the specific skill gap you'd need to close. It ends with a 30-day plan: shortlist two paths, close the biggest gap, build one public proof project, reposition your CV and LinkedIn, then reach out to people already doing the job.
Try it yourself
The quickest way to learn this is to run it. Write one API test from the first post against the practice REST API, then try the fake-429 test from the second. If you get stuck, ask in the free student Discord.
These posts are part of the free companion site for my Playwright TypeScript course on Udemy, which covers E2E, API, AI and MCP testing in depth.
Happy testing!
