红绿灯试验的相关性

Question

我开始，并热爱，TDD，但奇怪的红色绿灯的概念。从理论上讲，我理解在考试通过之前确保考试不及格的重要性。然而，在实践中，我发现这是一种徒劳无益的做法。

我觉得如果不实现我打算测试的代码，我就无法正确地编写失败或通过测试。例如，如果我编写一个测试来显示我的DataProvider正在返回一个DataRow，我需要编写DAL逻辑来给出一个有意义的失败，一个比一个NullException或者一个空方法返回更多的失败，这似乎是没有意义的，因为我觉得红灯应该表明我可以根据我正在测试的实际逻辑创建一个失败的测试。

换句话说，如果我只返回null或false，则从我正在测试的函数中得到我的失败值--红灯的实际值。

但是，如果我已经实现了逻辑(这在某种程度上违背了testing范式)，我发现我只是测试相互排斥的概念(IsTrue而不是IsFalse，或者IsNull而不是IsNotNull)，只是为了获得红灯而不是绿色，然后将它们切换到相反的位置以获得通行证。

我没有尝试这个概念，我真的提出了这个问题，因为这是我注意到的问题，我想知道我是否做错了什么。

编辑

我接受了查理·马丁的回答，因为它对我最有效，这绝不意味着其他答案不成立，所有这些都帮助我理解了一个我显然没有正确探索的概念。

Answer 1

把它看作是一种规范。首先，你会问自己，“我最终想要做的代码应该做些什么？”那么，假设您想要编写一个添加自然数的函数。你怎么知道这有用吗？那么，您知道2+2=4，所以您可以编写一个测试(这基本上是python，但忽略了很多细节，请参阅单元测试模块文档)：

def test2plus2(self):
    assertEquals(addNat(2,2), 4)

在这里，您定义了一个规范，说明“对于自然数a和b，计算a+b”。现在，您知道需要编写什么函数了。

def addNat(a,b):
    return a+b

你运行它，它就能通过测试。但是还有一些你知道的东西，因为它只适用于自然数(不管出于什么原因)，所以你需要增加一种防范非自然数的方法：

def testUnnatural(self):
    failUnlessRaises(AssertionErrof, addNat(-1, 2))

现在，您添加了一个规范，说明“如果数字为负数，则抛出一个AssertionError”。这将告诉您下一段代码：

def addNat(a,b):
    """Version two"""
    assert((a >= 0) and (b>=0))
    return a+b

现在运行它，断言就不会触发；再次成功。

关键是TDD是一种定义非常清晰、详细规范的方法。对于像"addNat“这样的东西，它们不是必需的，而是真正的代码，特别是在敏捷世界中，您并不凭直觉知道答案。TDD帮助您对这些进行排序，并对真正的需求进行修改，

Answer 2

红色权利的价值在于它能够识别假阳性。不管我的实现代码是什么，它总是通过测试。正是在这种情况下，红灯/绿灯测试才有帮助。

在我身上也发生了这样的事情:我的一些测试根本没有运行，而当我没有使用红灯的时候，我所看到的只是“构建成功”。如果我使用红灯来确保我的测试失败，那么当我期望构建失败时，我一看到构建成功就会产生怀疑。

Answer 3

有几个激励我的例子，我可以想到为什么红灯是有用的，并极大地帮助了我。

1. 为了精神健康写一份红色的考试。我确信这个测试可以验证我所知道的一些特性还没有实现，但实际上还没有实现。
2. 当您在代码中发现一个bug时，您将编写一个失败的测试来指出这个错误。从一开始就进行红色测试，您很确定您已经得到了它，并且知道错误何时修复。

也许曾经有一个例子，红灯是没用的，当你写测试来填充功能时，它们从一开始就会变绿。不过，我会警告您编写绿色测试时，可能会发生这样的情况:您必须重新设计类和其他什么东西，这会使一些测试变得过时。所有的绿色测试写作都是白费的！