Wal*_*ter 117 language-agnostic tdd unit-testing
我的公司对我们的代码进行单元测试是相当新的.我已经阅读了一段时间关于TDD和单元测试的信息并且确信它们的价值.我试图让我们的团队相信TDD值得学习和改变我们的编程思路,但这是一场斗争.这让我想到了我的问题.
TDD社区中有很多人非常虔诚地写测试然后编写代码(我和他们一起),但对于一个正在与TDD斗争的团队来说,妥协仍然会带来额外的好处吗？
编写代码后,我可能成功让团队编写单元测试(可能是检查代码的要求),我的假设是编写单元测试仍然有价值.
将陷入困境的团队带入TDD的最佳方式是什么？如果失败的话,即使代码写完之后仍然值得编写单元测试吗？
编辑
我从这里得到的是,在编码过程中的某个地方开始进行单元测试非常重要.对于那些接受概念的团队成员,开始更多地转向TDD并首先进行测试.感谢大家的投入.
跟进
我们最近开始了一个新的小项目,并且团队的一小部分使用了TDD,其余的在代码之后编写了单元测试.在我们完成了项目的编码部分之后,那些编写单元测试代码后,他们惊讶地看到TDD编码器已经完成并且代码更加可靠.这是赢得怀疑论者的好方法.我们仍然有很多成长的痛苦,但意志之战似乎已经结束.感谢所有提供建议的人!
Jus*_*ner 76
如果团队正在实施TDD,但他们之前没有创建任何单元测试......那么在编写代码后创建单元测试就可以启动它们.甚至在代码之后编写的单元测试总比没有单元测试好!
一旦他们精通单元测试(以及随附的所有内容),那么你可以先让他们创建测试......然后再编码.
Kal*_*see 27
代码编写完成后仍然值得编写单元测试.只是有时它往往更难,因为你的代码不是为了测试而设计的,你可能会过于复杂.
我认为将团队纳入TDD的一种良好务实的方法是在过渡期或可能是长期内提供"在开发期间测试"的替代方法.应该鼓励他们使用看起来很自然的TDD代码段.但是,在代码部分似乎很难接近测试优先或使用由非敏捷A&D流程预先确定的对象时,开发人员可以选择编写一小部分代码,然后编写测试来覆盖代码,并重复此过程.在编写代码之后立即编写单元测试某些代码比完全不编写任何单元测试更好.
Asb*_*erg 16
在我看来,最好是在"代码优先,测试后"和100%完成的库中获得50%的测试覆盖率,而不是100%的测试覆盖率和50%完成的TDD库.过了一段时间,你的开发人员希望能够为public他们编写的所有代码编写测试,这对他们来说是有趣的和有教育意义的,所以TDD会潜入他们的开发程序.
Aar*_*lla 12
我只是在日历上看到这一点:"每一条规则,最大限度地执行,变得荒谬甚至危险." 所以我的建议是不要虔诚于此.您的团队中的每个成员都必须在测试时感觉"正确"之间取得平衡.通过这种方式,团队中的每个成员都将获得最高效率(而不是说,思考"为什么我必须编写这种标准测试？").
所以有些测试总比没有好,代码之后的测试比代码优于之后的测试和测试要好.但每一步都有其自身的优点,你不应该对甚至小步骤不屑一顾.
Die*_*ias 12
TDD是关于设计的!因此,如果您使用它,您将确保拥有可测试的代码设计,从而更容易编写测试.如果你在编写代码后编写测试,它们仍然很有价值,但恕我直言,你将浪费时间,因为你可能没有可测试的设计.
我可以给你一个建议说服你的团队采用TDD的建议是使用Mary Linn和Linda Rising所描述的一些技术:引入新想法的模式
如果他们刚接触测试,那么IMO就会开始测试已经编写好的代码并慢慢毕业,先编写测试代码.当有人试图学习TDD和新的单元测试时,我发现很难做一个完整的180并改变我的思维方式在代码之前编写测试,所以我采取的方法是50-50混合; 当我确切地知道代码的样子时,我会编写代码,然后编写一个测试来验证它.对于我不完全确定的情况,我将从测试开始,然后向后工作.
还要记住,编写测试来验证代码没有错,而不是编写代码来满足测试.如果您的团队不想使用TDD路线,请不要强行使用它.
编写代码后,我可能成功让团队编写单元测试(可能是检查代码的要求),我的假设是编写单元测试仍然有价值.
毫无疑问,单元测试代码中存在价值(无论何时编写测试),并且我在"完成定义"中包含"代码经过单元测试".只要他们测试,人们可以使用TDD或不使用TDD.
关于版本控制,我喜欢使用" 开发分支 "和单元测试策略(即代码编译和构建,所有单元测试都通过).功能完成后,它们将从开发分支发布到主干.换句话说,主干分支是" 完成分支 "(主干上没有垃圾!)并且具有可 交付的策略(可以在任何时间释放),这是更严格的并且包括比"单元测试"更多的东西.
| 归档时间： |
|
| 查看次数： |
9262 次 |
| 最近记录： |