COMP0034 代写 的第二份作业（Coursework 2）通常要求用 FastAPI 实现一套 Water Data REST API，并写一份测试批评（Test Critique）。很多人代码写得没问题，报告却拿不到分——因为不熟悉「批评」这种文体要求写什么。
交付物拆解
这类作业一般是两个部分：
- API 实现：FastAPI + SQLModel + Alembic 迁移，覆盖 10 条规定路由。
- 报告：测试策略批评 + 参考文献 + AI 使用声明 + 数据集归属。
十条路由的覆盖清单
GET /sales/ 列表（支持分页）
GET /sales/{id} 单条，不存在返回 404
GET /sales/series/{name} 按系列筛选
POST /sales/ 创建，201 + Location
PUT /sales/{id} 全量更新
PATCH /sales/{id} 部分更新
DELETE /sales/{id} 删除
GET /quality/ 水质数据
POST /quality/ 新建水质记录
GET /prices/ 价格数据
POST /prices/ 新建价格记录容易漏的是 PATCH 与 PUT 的语义区分：PUT 是整体替换（未提供的字段应回默认值），PATCH 是局部更新（未提供的字段保持不变）。用同一套逻辑实现两个路由会被扣分。
用 SQLModel 定义模型
from typing import Optional
from sqlmodel import SQLModel, Field
class SalesBase(SQLModel):
series_name: str
year: int
sales: float
class Sales(SalesBase, table=True):
id: Optional[int] = Field(default=None, primary_key=True)
class SalesUpdate(SQLModel):
series_name: Optional[str] = None
year: Optional[int] = None
sales: Optional[float] = None分离 Base / table / Update 三个模型是标准做法——它让 Pydantic 的校验规则与数据库表结构解耦，也让 PATCH 的「可选字段」语义自然成立。
测试策略：批评怎么写
「批评」（critique）不是「介绍」，它要求同时给出优势与劣势，并且劣势必须有说服力。常见的结构：
优势部分
- 测试隔离：内存 SQLite 保证每个测试从干净状态开始，失败可复现。
- 速度：TestClient 在同进程内发请求，17 个测试不到 0.3 秒。
- 路由覆盖：GET / POST / PUT / PATCH / DELETE 全覆盖，含成功路径与 404。
- 确定性断言：fixture 插入已知记录，断言可以是精确值而非近似匹配。
劣势部分（这部分才决定分数）
- 缺少集成测试：后端用内存库，前端 Flask 走真实 HTTP 客户端，两端没有同时起服务的端到端测试。列名不一致这类集成缺陷不会被发现。
- 数据库迁移未测试：Alembic 迁移脚本不在测试范围内，迁移写错要到部署时才暴露。
- 未覆盖并发：单进程 TestClient 无法验证多请求并发下的竞态。
- 外部依赖被 mock 掉：真实数据源的字段变更不会触发测试失败。
关键：每一处劣势都要接一句「影响是什么」。写「没有集成测试」只是一句描述；写「没有集成测试，因此 API 响应字段与前端读取字段不一致时不会被 CI 拦截，这类缺陷会直接进入生产」才是批评。
AI 使用声明
UCL 对生成式 AI 的使用有分级要求（Category 1–3）。这类作业通常需要明确写出：用于哪部分、属于哪个类别、是否经过人工复核。漏写或不实声明是学术诚信问题，比丢分严重得多。
常见扣分点
- PUT 与 PATCH 语义混淆。
- 404 路径未测试（只测了成功路径）。
- 批评章节只写优点，或劣势写成「时间不够所以没做」。
- 参考文献格式不统一。
- 缺少 AI 使用声明或数据集归属。
- 响应模型未声明
response_model，导致 OpenAPI 文档不完整。
代写Pro 的 COMP0034 服务
- 路由全覆盖：10 条规定路由 + 边界与错误路径。
- 测试可运行：pytest 用例随代码交付，
pytest -q直接通过。 - 批评有深度：优势与劣势各成体系，落到影响而不止于描述。
- 合规声明：AI 使用分级、参考文献、数据集归属按 UCL 要求填写。