如何在下一个项目开始前推动写单元测试？

[luoway]

• 团队鼓励快速迭代，忽略写单元测试
• 部门内写了测试的项目团队没推荐过写测试有啥帮助，没写测试的出了 bug 及时修复也不追究
• 我们总说“单元测试以后有空再补”，想补的时候发现，有些代码要写单元测试还得改项目代码。结果不了了之

仿佛犯罪成本低，守法成本高，大家就不关心写不写测试

下个项目不小，个人期望 TDD，奈何是个小兵
估计不提出来的话，会像往常一样继续 BDD

[wuwenzhx]

规定提交 patch 的时候没有单元测试代码覆盖自己 patch 的就不给 merged

[luoway]

@wuwenzhx 没有规定

[fy]

先搭建持续集成，PR 必须过测试和 lint，很快就都习惯了

[luoway]

@fy 这个是整个部门的动态，小兵没法干预

[majinjing3]

build 系统里面，判断单元测试代码覆盖率，降低了代码覆盖了的 build 统统失败，不接受
严格管理好 build 系统

[majinjing3]

和 3 楼差不多一个意思，不过更严格，毕竟人家不写测试咋办呢，lint 也好糊弄的

[jimi2018]

先给他们做个培训，然后大家就有一致认知了，在行动就好办了，推荐个教程给你：

http://xc.hubwiz.com/course/5911d52ab343f27b0ae1b895?affid=20180319v2ex

[paragon]

只看覆盖率本身也是有野路子可以摸鱼的~

[pelloz]

你首先应该做的是提升自己在团队内的地位再去考虑如何帮团队做改进，要不然你这么多想法没人会鸟你。关于如何提升在团队的地位，这是另外的问题，不过可以给你几个建议：
1.变成老板，谁不搞 TDD 谁滚蛋
2.变成团队技术负责人，TDD 没搞好你负全责，技术团队全部听你的
3.自己默默搞 TDD 并且出成果，打他们脸

你必须有付出并且能够承担责任才能做出改变

[luoway]

@pelloz 是这个理

不过 TDD 短期不会出成果的，毕竟我们连 bug 率都不做统计汇报

[pelloz]

@luoway 我个人的意见是当你觉得必须改变环境才能让自己进步，而自己又没有能力改变当前的环境的时候，你可以试着做一些准备，然后换一个你喜欢的环境。比如国内 TDD 做得比较好的应该就是 ThougthWorks，要不你去他们家试试？他们家似乎比较欢迎懂敏捷开发和 TDD 的人

[jadec0der]

看老板。

你在 CI 里加一个 coverage 下限，当 coverage 不足以通过 build 的时候。老板 /项目经理如果愿意多花点时间补全测试 TDD 就能继续搞下去，不过更大的可能是他们选择把 coverage 删掉赶工期。

[jadec0der]

@jimi2018 这都能 299 ？我服

[ZSeptember]

关注，看大神意见。

[carlclone]

你是不是对 BDD 有什么误解, BDD 基本上就是 TDD

[houshengzi]

一直都想推动单元测试，奈何学得不深，团队也没有这个氛围。只好作罢

有没有大神能提供相关资料的

[aristotll]

@carlclone #15 我也正觉得奇怪呢

[akira]

单元测试这种东西是不可能补的....

[jswh]

现有系统重构的时候，对重构的部分加测试

[jameslan]

@pelloz 一个人做出 tdd 去打脸？你是说别人写了代码楼主去补 testcase ？

[frozenthrone]

小兵还是换地方实在

[jimi2018]

@jadec0der 深入一下我觉得还是值的，符合实战，涉及东西也多。

[luoway]

@carlclone
@aristotll
BDD （ Behavior/Business Driven Development ），我的理解是它只要求达成目标就行，不关心代码质量。

[exonuclease]

现在的项目没单元测试没用 ts 还特别大 每次发版本都提心吊胆的 也没人提 哎

[Vvfan]

让老板加钱

[luoway]

@exonuclease 我的下个项目也很大，不预先考虑的话将来维护和交接也会这么困难