公司今天提出要用TDD模式，给了两个场景： 
一、为啥一定要有一张失败的红图？ 
如果你代码全都写完了才补单测，跑出来直接就是绿灯。 这种测试很容易变成跟着现有代码“走个过场”：边界场景很容易漏测，甚至你断言本身写错了，测试都照样显示通过，根本起不到把关作用。 
先跑出报错的红截图，目的只有一个：证明你写的这个测试用例真的能发现问题、拦得住bug，而不是一个永远不会报错的“假测试”。 
二、平时开发照着这个流程来就行 
场景1：修复线上或者测试环境的Bug 

红：先根据bug复现步骤，把单元测试写出来。不改原有代码直接跑测试，必须跑失败、出现报错 → 截图保存这张红图
绿：再动手改业务代码，把Bug修好。重新跑一遍刚才的单测，测试成功通过 → 再截一张绿图

场景2：开发新功能、新接口 

红：先写单元测试，把预期的入参、返回结果、异常情况全部写好。这时业务代码先不要实现，可以先写个空方...