返回知识库

工程与栈 · 工程协作

测试Test

测试先写固定输入和用户能看见的期望,再跑实现;对不上就红灯并留下对照,用来拦住回归。

先认出这一行用例,再看期望对不对

下面就是花店价格测试:默认期望和实际都是 ¥1,299。改坏千分位,红灯也写在同一行上。

花店用例 · formatPrice(1299)通过 · ¥1,299

期望 ¥1,299 · 实际 ¥1,299

绿勾。改坏千分位会被这一行拦住。

通过 · ¥1,299通过结果长在用例行上。

原因:测试先写用户能看见的期望,再跑实现。下一步:点「改坏千分位」,看红灯会不会写在这一行上。

知识点:测试抓的是可见结果

用例行上的期望和实际已经演示了差异,这里只命名四条。

  • 测试先写固定输入和期望输出,再跑实现。
  • 对的是用户能看见的结果,不是私有内部函数。
  • 失败要留下期望和实际,方便改。
  • 离开后要盯:红灯禁止合并;分层跑 unit、集成和端到端。

什么时候用、怎么用

行为会再被改到、怕回归时写测试;它替代不了 lint,也不替代人手点一遍新品。

  • 信号:改完价格格式旧用例红了、PR 没有自动检查、失败只说「错了」。
  • 适用:金额、登录、权限这些能说清期望的行为。
  • 不适用:还在探索的草稿界面——先稳定期望再写。
  • 最短路径:写期望 → 跑一次 → 改坏实现看它红 → 改回看它绿。

正反例:同一条价格用例

目标都是显示 ¥1,299,只改实现。

正例千分位还在

期望和实际对齐。结果长在用例行上。

反例改坏千分位还合并

实际变成 ¥1299。失败写在对照上。

快速自测

改完 formatPrice,测试红了:期望 ¥1,299,实际 ¥1299。这说明什么?

继续查证

术语的技术定义和行为以这些一手或权威资料为准。

下一步学

和本知识点经常一起出现的概念。