强制开发人员进行单元测试

除非你是权威人士,否则你能做的最好的事情就是让他们相信测试套件的价值。

如果开发人员没有看到正确的做法,那么很难让他们看到这个问题的真相。

尝试与另一个开发人员配对,向他们展示首先编写测试的好处和清晰性。如果您不这样做,他们可能会编写所有的代码,让它工作,然后编写测试。因此,从他们的角度来看,这就像是一项额外的任务,不能帮助他们完成任务。

在我看来,强迫任何人做任何事都不是一种好的做法。我会在每一个机会向他们展示TDD的好处。这将自动使团队的其他成员自愿练习TDD。

你不需要口惠的单元测试,你需要全心全意的单元测试。这不是可以强迫的。你需要做的是随着时间的推移影响你的队友,让他们看到单元测试的好处,并发展一种单元测试文化。

首先,你需要了解不同的人因不同的原因而改变。在里面 Crossing the Chasm 换句话说,有远见的人会采用新技术,因为它们更好,但实用主义者采用新技术,要么是因为他们解决了当前的问题/痛苦,要么是因为其他人都在采用它。

然后,您的任务就是展示单元测试如何解决您的团队目前感到的痛苦。随着你一个接一个地赢得人们的支持,最终你会到达一个转折点,单元测试是一种规范,每个人都会遵守它。然而,如果您不能将单元测试与您的团队感到的痛苦联系起来,那么您说服他们的努力可能会失败。

从长远来看,考虑到单元测试可以提高代码和软件质量,我想说,是的,让开发人员提供单元测试是一种很好的做法——不管它是否是某种sprint的一部分。

我看到的单元测试的两个主要障碍是:

• 开发人员不明白:“为什么我们要写更多的代码只是为了测试?”
• “我们没有时间编写单元测试”

力
而且,即使你是他们的老板,如果他们被迫这样做,他们也可能做不到最好的工作:如果人们理解为什么和如何做,单元测试通常会做得更好!

另一件事是:很难知道“测试什么”和“如何测试”:你需要向你的同事解释/证明这一点:有些东西不能测试,有些东西不需要测试,有些东西不是“单元可测试的”——嗯,我想,除非你的软件设计得很好^^

我在过去的很多工作和合同中都得到过这样的职位,所以我最终感到气馁,并通过鼓吹来拥抱黑暗 Development Driven Development .

至少,他应该这么做。

有一篇关于软件的文章叫Joel Getting Things Done When You're Only a Grunt

1. 想做就做

   我认为最重要的是。定期编写测试,不要让它看起来好像你自己把它们看作是开发的一小部分。

2. 利用病毒式营销的力量

   如果您在其他人的代码中看到错误,请编写一个触发该错误的测试,并将这两个错误都呈现给他。也许他明白你的意思。

3. 确定那些对这个想法持开放态度但不太确定如何使用单元测试的团队成员,并建立一些测试类,直到他们每个人都知道如何做。然后转向另一个。一旦你不再是唯一的一个,事情就变得容易多了。

4. 将有一些团队成员几乎不可能编写测试。也许应该通过定期用新的提交破坏代码来处理这些问题,然后指出,由于它们没有测试,所以您很难注意到。

这取决于您的版本控制,但有一些版本控制软件允许您在签入或合并到生产分支之前运行脚本。如果单元测试失败,它也不会让开发人员签入。

就你而言, NCover 似乎 integrate nicely into CC.NET .

不。根据我的经验,TDD在实践中并不那么有用。我有时将它用于真正通用的基本类(如几何体或通用数据结构),这些类自然地适合自动测试。但对于UI组件或业务逻辑,我发现它的麻烦比它的价值还要多。