什么样的技术可以使写作测试变得更有趣？

Question

我必须承认，我经常在实践测试驱动的开发中挣扎。尽管使用Rails使TDD变得非常简单，因为它是烘焙的，但我发现编写测试太无聊了！这就像牙线，我知道我应该这样做，但我很难调动起更多的热情。

• ，您用什么技术来使写作测试变得有趣？例如，我看到的一个技巧是围绕测试夹具数据编造一个小故事，而不是仅仅使用毫无意义的、无关的数据。

Answer 1

如果您首先编写测试，它们就是您编写代码的规范。

所有的思考都必须在写测试时完成。“它该怎么办？”“我怎么知道是它干的呢？”“它有哪些需要模拟的接口？”

此外，如果您使用简单的命名约定(使用“应该”)来构造测试，那么您可以更容易地确定应该发生的事情。

有关这方面的一些想法，请参见http://weblogs.asp.net/rosherove/archive/2005/04/03/TestNamingStandards.aspx。

如果您最后编写测试，它们会很无聊，因为您知道代码是有效的。

Answer 2

写阴性测试通常比“晴天”更有趣。想一想你可以打破类的所有创造性方法(传入null，值太大/太小等)。

它不仅会给你的大脑一个不同的角度咀嚼，它也会使你的班级更加健壮，因为人们会称它为零，大数等。

Answer 3

我担心这个听起来像一个代码气味。

是无聊的测试，因为它们非常重复？

这些测试是否多次涵盖相同的内容？(也就是说，测试用例不只是一次测试一件事情，所以有很多重复测试相同的事情.？)

您可能会感到厌烦，因为测试是在错误的抽象级别上编写的，或者它们迫使您做许多不必要的繁忙工作。

听起来有些东西需要重构，或者至少需要抽象，这样每个测试就能表达出新的或者与代码的其他部分不同的内容。

如果很多测试看起来很明显或乏味，那么在您使用的抽象中就缺少了一些东西。

我希望开始在那些您觉得无聊、或乏味的测试中寻找模式，看是否可以完成一些事情--比如创建一个很小的测试框架来帮助那些测试更容易地编写。

在检查时，您可能只需要删除一些冗余的测试并清理命名--这样就可以清楚地知道您需要测试什么，以及测试套件中其他地方可以依赖什么。

这都是为了取舍。我认为有必要重新评估你正在编写的测试类型，看看可能有哪些替代方案。