Autowini WEB Integration Project: Playwright E2E Tests + Claude Code Automation

In my previous post, I added Vitest and set up a unit testing environment for utility functions.

That let me finish verifying the util functions used across the project.

But as I ran the actual project, there were a few things I felt were lacking.

I had to check browsers other than Chrome by hand, and unit tests alone made it hard to verify how the actual UI behaves.

I had used Storybook to verify UI before, in the Autowini Keycloak theme project.

This time, though, I needed tests that go beyond checking components and can verify user flows in a real browser environment.

I was looking for a tool that supports cross-browser testing, can check real UI behavior, and is relatively easy to adopt.

With those requirements in mind, I decided to try Playwright in this project, since I had heard it is widely used in real-world work.

How I introduced the tests

I wrote the initial test code with Claude Code.

I had it generate Playwright tests based on the existing code, and since the syntax is not very different from Vitest, I got used to it quickly.

At first I built the basic tests by asking it to "write test code based on the current code," and later I expanded this into a rule-based setup so that tests could build up naturally over time.

Test file structure

The E2E tests currently live under the e2e/ directory, split up by page (domain).

• *.spec.ts for each page
• Shared data: fixtures/
• Shared logic and mocking: helpers/

I kept the existing domain-based structure as is and split the test code along the same lines.

Automating tests with Claude Code

To keep test code consistent, I defined rules in CLAUDE.md and set up an automated flow.

CLAUDE.md

1
2
3
4
5
6
7
8When adding or changing a page or domain feature, you must add Playwright tests in the `e2e/` folder.

- Test file location: `e2e/<domain-name>.spec.ts`
- Mock API responses with `page.route()`, without depending on the real backend
- Return `[]` as the response body for the `recommended-keywords` endpoint
- See `e2e/helpers/mockApi.ts` for the shared mock helpers
- Verify translation keys against the actual locale values
- When verifying URL parameters, check the constant values (`sorting`)

With this setup, I configured Claude Code to analyze the existing code and generate Playwright tests automatically during feature development.

As a result, I could turn testing from a "writing" task into a process of reviewing and running.

Cross-browser test screen

Individual UI test screen

Takeaways

This time I wrote tests based on the existing codebase, but for newly developed features going forward, I have set things up so that Claude Code generates the tests automatically based on the rules defined in CLAUDE.md.

I also plan to extend this so tests are verified against planning documents and requirements, so I think we can gradually expect positive effects on QA automation and development efficiency.