Day 15 - Weekly Review 3: Project Structure Refactor

今日目标

建立可维护 Playwright 项目结构。
初步具备团队协作基础。

学习时间安排（60–120 分钟）

时间	模块	做什么
0-20 分钟	本周概念回顾	过一遍概念表，标出配置、hooks、fixture、POM 的薄弱点。
20-45 分钟	实践任务	按目标结构整理项目目录。
45-75 分钟	README 编写	写一份能让新人跑起来的 README。
75-105 分钟	自查与修复	对照“新增 50 条测试”的假设检查结构合理性。
105-120 分钟	复盘与作业	完成复盘问题，让 AI review 项目结构。

本周概念回顾

English	中文	是否已掌握
playwright.config.ts	配置文件
testDir / timeout / retries	核心配置项
baseURL / use	共享配置
projects / devices	项目矩阵
describe / beforeEach	组织与 hooks
test independence	测试独立性
fixture / base.extend	自定义夹具
Page Object Model	页面对象模型
behavior / assertion method	行为与断言方法
encapsulation	封装

实践任务

整理项目为：

playwright-learning/
  tests/
    smoke.spec.ts
    login.spec.ts
    navigation.spec.ts
  pages/
    HomePage.ts
    LoginPage.ts
  fixtures/
    test-fixtures.ts
  test-data/
    users.json
  playwright.config.ts
  README.md

README 至少包含：

项目用途。
安装方式。
运行方式。
目录结构。
测试规范。
locator 规范。
提交前检查。

自查清单

- [ ] 目录结构与上面一致（或更合理并说明理由）
- [ ] tests/pages/fixtures/test-data 职责清晰
- [ ] README 新人可照做跑通
- [ ] 新增 50 条测试不需要新开目录层级
- [ ] 重复代码已封装进 POM 或 fixture

今日产出

一个结构清晰的小型 Playwright 项目。
一份 README。

复盘问题

当前项目结构是否适合新增 50 条测试？
哪些代码已经重复，应该封装？
POM 是否让测试更易读？
Fixture 是否让测试数据更清晰？
团队协作时最需要统一哪些规范？

AI 时代扩展：让 AI review 项目结构

适用场景

把目录树和 README 交给 AI，让它站在“三个月后接手的同事”视角审查：结构是否可扩展、文档是否完整、规范是否有歧义。

可复用表达 / 提示词

这是我的 Playwright 项目目录树和 README，请以「三个月后接手的同事」视角审查：结构是否可扩展、README 是否有缺失、规范是否有歧义。

追问加练

AI 建议再拆一层目录，你用什么标准决定拆还是不拆？
README 里 AI 帮你补充了“提交前检查”，哪些检查是拍脑袋的？
团队规范文档应该由 AI 起草吗？哪些部分必须人写？

今日作业

完成项目结构重构，跑通全部测试。
完成 README 的 7 项内容。
让 AI review 结构和 README，记录采纳与拒绝的理由。

自检清单

我的项目结构与计划一致（或有充分理由的改进）。
README 让一个新人能在 15 分钟内跑通测试。
POM 和 fixture 都在正确的位置，职责清晰。
我知道新增测试该放到哪个目录、遵循什么规范。
下周进入真实场景：登录态、API、Mock、文件处理。