sgqlc 与 pytest 结合测试的核心难点在于上下文缺失、类型校验绕过和响应误判；关键实践是用 sgqlc-codegen 同步最新 schema 并提交 Git，测试中通过 Operation 和生成类型类构造合法 query，用 op.variables 提取变量，function 级 fixture 管理 client，独立构造 Operation 避免污染。
直接用 sgqlc 写 GraphQL 请求本身没问题，但把它和 pytest 一起做自动化测试时，最容易卡住的地方不是语法，而是请求上下文缺失、类型校验绕过、以及响应结构误判——尤其当你从 requests 或 graphene.test.Client 切换过来时。
为什么不用 requests + 手写 query 字符串？
手拼 query 字符串看似自由，实际在维护中很快失控：sgqlc 的核心价值是把 GraphQL Schema 编译成 Python 类型，让 IDE 能补全字段、类型检查能提前报错、字段改名时测试直接爆红。而纯字符串方式下，字段拼错、嵌套层级少一层、参数类型传错，都得等运行到服务端才返回 "Cannot query field 'xxx' on type 'YYY'" 这类模糊错误。
- 每次改 Schema 后，必须手动同步所有字符串 query，极易遗漏
- 无法静态检查变量是否传全（比如漏了
id: $id却没定义$id） -
pytest的参数化测试里，难对齐 query 结构与输入数据的字段映射
如何正确生成并使用 sgqlc 类型代码？
关键不是“生成一次就完事”，而是把生成步骤纳入开发流程——否则团队里有人用旧 schema，有人用新 schema，测试结果不可信。
- 用
sgqlc-codegen从真实 endpoint 拉取最新 schema：sgqlc-codegen schema https://www.php.cn/link/cb6c409f88eca4470f2516488e70c61f --outfile schema.py - 生成的
schema.py必须提交进 Git，禁止只保留在本地 - 如果服务端启用了 introspection 禁用（生产环境常见），就得用
.graphql文件代替：sgqlc-codegen schema schema.graphql --outfile schema.py - 生成后立刻跑一次
pytest，确认schema.Query和schema.Mutation能 import 成功，避免后续测试全挂
测试函数里怎么构造合法 query 并断言？
别在测试里手写 Operation 实例；要用 sgqlc.operation.Operation 配合生成的类型类，让结构强制合规。
立即学习“Python免费学习笔记（深入）”；
from schema import Query
from sgqlc.operation import Operation
<p>def test_user_profile():
op = Operation(Query)
user = op.user(id=123)
user.name()
user.email()
user.posts(limit=5).title() # 自动校验 posts 字段是否接受 limit 参数</p><pre class="brush:php;toolbar:false;"># 此时 op + 变量才是完整可发请求体
query_str = str(op)
variables = op.variables
# → 然后交给 requests.post(..., json={"query": query_str, "variables": variables})
- 字段调用链（如
user.posts(...).title()）一旦写错，Python 解释器立即报AttributeError，不是等到服务端返回 - 变量必须用
op.variables提取，不能自己硬编码字典——sgqlc会自动处理Int!和String的 null 安全性 - 断言响应时，别直接比对整个 JSON：
assert data["user"]["email"] == "test@example.com"更可靠；避免因服务端加了新字段或顺序变化导致测试飘红
fixture 怎么封装才能复用又不污染？
最常踩的坑是把 session 或 client 做成 module 级 fixture，结果并发跑 pytest-xdist 时状态串了。正确做法是 scope="function" + 显式传参。
@pytest.fixture
def gql_client():
from requests import Session
s = Session()
s.headers.update({"Authorization": "Bearer test-token"})
return s
<p>def test_user_profile(gql_client):
op = Operation(Query)
op.user(id=123).name()
resp = gql_client.post(
"<a href="https://www.php.cn/link/cb6c409f88eca4470f2516488e70c61f">https://www.php.cn/link/cb6c409f88eca4470f2516488e70c61f</a>",
json={"query": str(op), "variables": op.variables}
)
assert resp.status_code == 200
data = resp.json()
assert data["data"]["user"]["name"] == "Alice"
- 不要在 fixture 里执行
post；只负责准备 client、token、base_url 等稳定依赖 - 每个测试函数内独立构造
Operation，避免 query 复用导致字段残留或变量冲突 - 如果需要共享查询逻辑（比如常用分页参数），抽成普通函数，而非 fixture —— fixture 是生命周期管理工具，不是工具函数容器
真正难的不是写通第一个请求，而是当 schema 变更频繁、团队多人协作、测试要跑在 CI 上时，保证每次生成的类型代码和实际服务一致，且错误能暴露在本地开发阶段。绕过 sgqlc-codegen 直接手写或缓存旧 schema，短期省事，长期会让测试失去可信度。
