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.