pytest、Robot Framework 与 Playwright：fixture、关键字驱动和端到端测试

这几类测试工具解决的问题不同。pytest 更偏 Python 测试框架，Robot Framework 更偏关键字驱动的验收测试，Playwright 更偏现代 Web 端到端测试。

pytest 自动发现

pytest 会自动发现：

test_*.py
*_test.py
以 test_ 开头的函数

def test_add():
    assert 1 + 2 == 3

fixture

fixture 用来准备测试前置条件，也可以做测试后的清理。

import pytest
 
@pytest.fixture
def setup_env():
    print("prepare")
    yield
    print("cleanup")

测试函数只要把 fixture 名字写进参数，pytest 就会自动注入。

def test_example(setup_env):
    assert True

fixture scope

scope 决定 fixture 生命周期：

function：每个测试函数一次
class：每个测试类一次
module：每个文件一次
session：整个测试会话一次

真实项目里，公共 fixture 通常放在 conftest.py。

Robot Framework

Robot Framework 的特点是关键字驱动，测试更接近业务语言。

*** Test Cases ***
Login With Valid User
    Open Browser To Login Page
    Login With Valid Credentials    ${USERNAME}    ${PASSWORD}
    Page Should Contain Element    id=dashboard

它适合验收测试、流程测试和让非开发人员也能读懂的自动化脚本。

Playwright

Playwright 更适合现代 Web E2E。

test("user can login", async ({ page }) => {
  await page.goto("/login");
  await page.getByLabel("Username").fill("jesse");
  await page.getByLabel("Password").fill("password");
  await page.getByRole("button", { name: "Login" }).click();
  await expect(page.getByTestId("dashboard")).toBeVisible();
});

减少 flaky 测试

不要用固定 sleep 当万能方案。

更好的方式：

等元素可见
等按钮可点击
等请求完成
等 URL 变化
通过 API/DB 准备测试数据
UI 测试只覆盖核心路径

稳定测试的本质是等待“明确条件”，不是等待“固定时间”。

延伸理解

复习这篇时，不要只记住名词，要把重点放在 pytest fixture、Robot Framework、Playwright、端到端测试和 flaky 测试治理。这类知识如果只停留在定义层面，很容易在面试或项目中答得很散。更好的理解方式是把它放进一个具体场景：谁在调用它，输入从哪里来，失败后谁负责恢复，数据或状态会不会被重复处理。

测试的目标不是追求覆盖率数字，而是用较低成本锁住关键行为和风险边界。
单元测试、集成测试和 E2E 测试应该分工明确，越靠近 UI 越要少而关键。
高质量测试要避免依赖真实时间、随机数据、网络波动和外部服务状态。

在真实项目中，可以把它当成一个判断框架：先确认输入、约束、失败场景和可观测性，再决定具体工具或写法。如果一个方案看起来很简单，要继续追问它在规模扩大、权限变化、异常恢复和团队协作下是否仍然成立。

实践检查清单

明确这个知识点在系统中的位置：是开发时约束、运行时能力、基础设施能力，还是协作流程。
写出一个最小可运行例子，并补一个失败例子；只会写 happy path 说明理解还不够稳。
记录常见误用：例如边界条件、权限假设、性能假设、同步/异步差异或环境差异。
把概念和项目经历关联起来：如果面试被追问，可以用自己的项目说明为什么这样选。
最后用一句话总结取舍：它牺牲了什么，换来了什么。

自测问题

这个主题解决的核心问题是什么？
如果不用当前方案，还有哪些替代方案？代价是什么？
最容易出错的边界条件在哪里？
如何在代码、测试或监控中验证它真的可靠？

项目化应用场景

可以把这类知识放到一个登录或订单接口里理解：单元测试验证纯函数和边界条件，集成测试验证 API 与数据库交互，E2E 测试验证用户关键路径。Mock 应该隔离外部依赖，而不是掩盖真实行为。测试越靠近 UI，成本越高、速度越慢，所以应该覆盖最关键路径，而不是把所有细节都塞进 E2E。

常见误区：

只测成功路径，不测错误路径。
Mock 过多导致测试和真实系统脱节。
E2E 测试依赖真实时间或不稳定外部服务。

目录