我有一个开发人员，它将通过编写永不失败的测试来解决我们的代码问题。

该代码简直是残酷的，但是测试从未捕获它，因为它们是assert(true)。

我编写了代码审查，但我无法始终让每个人都为他们工作。我们如何激发这样的人去开发好的软件？

是否有用于检测不会失败的测试的构建插件？

C＃，mbUnit测试。

解决方案

我们应该真正指定要使用的语言/框架。

在最简单的情况下，我认为使用简单的grep-ping可以很容易地检测到assert(true)字符串。

对于应用程序配置值，我们总是可以尝试使用垃圾进行测试。

是否通过了任何测试？

真正的动力来自内部。有些人有时会出于其他任何可能的机会而使用系统进行游戏。其他人仅仅是因为他们是黑客。

就是说，假设经理与开发人员举行了"耶稣会面"会议。如果仍然无法解决问题，那就总有门。

如果我们不是经理，请使用适当的渠道。

我想我们在那里几乎已经回答了自己的问题。如果我们有某人为我们工作或者与我们一起工作(我们不清楚是否是该开发人员的经理)，那么如果他们没有正确地完成工作，那么肯定会有一些程序可以使该人清楚他们没有按照可接受的标准制作作品。

开发人员是TDD的新手吗？也许他们需要编写良好的测试等方面的学费。否则，他们需要精打细算，并向他们强调，测试似乎并不比他/她所编写的代码重要。

哦，是的，在插件方面，忘记了，只需检查我们正在执行的相同代码就足够了。

与其花费时间寻找不会失败的测试，不如将测试扩展一点，会使代码在许多方面失败。那会

• 向他展示如何编写更好的测试
• 强迫他修复自己的代码，并防止检入更多错误代码

我们必须使用一段越野车代码是一个很好的起点-我们必须确保它能正常工作...

选择他正在测试的界面，并将其简化为最简单的形式。换句话说，采用类/方法签名，然后仅添加编译所需的代码。对此进行测试。问他，当程序什么都不做时，为什么他的测试通过了。

由两个或者两个以上已经受到测试感染的开发人员进行的Code Review，可能是使开发人员了解自动单元测试确实不是那么困难，也不是不寻常的最佳方法。每条评论上都有两名受测试感染的开发人员，将加强质量单元测试对他的重要性。
另外，给他分配经过良好测试的其他开发人员代码的审阅将有助于他学习如何进行单元测试。

我们应该看看做一些突变测试，以检测弱测试。 Nester(相当于Jester的.Net)是一种有用的工具。

请让我们知道情况！

更新：我碰到过："为什么大多数开发人员仍然不编写单元测试？"并认为在这里阅读也将是一件好事。

我认为我们需要尝试让他先写一个失败的测试。设法使他养成这种习惯。单元测试的新手PPL通常很难编写它们。

还有一些工具可以"探索所有可能的代码路径"。我建议我们看一下，PEX将生成自动测试，并且很可能会破坏他的代码...虽然这可能不是最佳选择，但请尝试推广共享代码库的概念。

让开发人员与程序结对，当我们与其他人一起使用同一功能时，变得"懒惰"要困难得多，并且这样会分散代码所有权。我们似乎没有这样做，因为我们谈论的是"他的"代码。如果有2个人从事同一工作，我们可以完成多少工作，这可能会令人惊讶，这将大大提高质量。

同样，单元测试并不是消除所有问题的圣杯……它们应该是我们可以使用的工具之一。

代码覆盖要求是什么？