William "dethstrobe" Johnson

Your test clicks a button. Playwright says the click worked. Nothing happens. The test fails, you rerun it, and it passes. Classic.

If your app is server-rendered React, the button was on the page and clickable before React hydrated and attached its onClick. Playwright clicked a button that didn't do anything yet. So I pulled the helpers I've been using to deal with this into a package: @test2doc/playwright-utils.

Test2Doc has always turned Playwright tests into documentation. That's great if your app lives in a browser. Less great if your users want a mobile app and think mobile websites are lame. (They're not lame, FYI. They're super dope.)

So I built @test2doc/maestro: a CLI that turns Maestro flows into docs for Docusaurus, complete with annotated screenshots, for your Android, iOS, and web apps. It's a v0 preview, so please try to break it.

The best documentation is always up to date. The best way to keep docs up to date is to make them executable.

I've spent six months building Test2Doc—turning Playwright tests into documentation—and writing a tutorial that puts it into practice. Here are the patterns I discovered for writing tests that read like user guides.

As foretold in the prophecy billions of years ago at the dawn of time, I said I was working on a tutorial to help teach TDD with Playwright, RedwoodSDK, and how to generate documentation with Test2Doc for Docusaurus.

And I did. The tutorial is complete and covers all the basic CRUD operations, best practices around testing, refactoring, and deploying to Cloudflare.

Test Driven Development (TDD): you've heard of it, maybe tried it, possibly given up on it. The theory sounds great, but how do you actually do it on a real project? That's what my new tutorial tackles, using RedwoodSDK and Playwright to test and generate documentation using Test2Doc!

A common problem in automated tests is that selectors, the way in which you select an element on a page, can change over time as development implements new features or requirements.

The API has been stable for a few weeks now and I just finished a redesign of test2doc.com (you might be reading it on there now).

So let's talk about some of the fun new stuff you'll see with v1.

So, I’ve been working through the Redwood SDK fullstack tutorial. I thought it would be an interesting and moderately complicated app to write Playwright tests for, and a great way to dogfood test2doc. Well, I’ve found many issues.

Finding issues while dogfooding is obviously wonderful as it shows test2doc working in a real world example and real world pain points. And then I figure out how to mitigate and improve the experience.

Ever wished your documentation could write itself? What if every time you wrote a test, you automatically got beautiful, up-to-date docs with screenshots?

That's exactly what Test2Doc does - a Playwright reporter that automatically generates Docusaurus documentation from your tests - and with the latest release, we've hit MVP with three game-changing features that turn your Playwright tests into living documentation.

https://www.npmjs.com/package/@test2doc/playwright/v/0.0.2

Just for clarification, this is a work in progress. This is just the proof of concept right now, but it is possible to play with it. There will be breaking changes coming in the near future was I attempt to improve the markdown and best practices around how to write tests.