当TDD没有帮助时，如何避免代码中的逻辑错误？

最近，我正在编写一小段代码，以人类友好的方式指示事件的年代。例如，它可能表明该事件发生在“三周前”或“一个月前”或“昨天”。

需求相对明确，这是测试驱动开发的完美案例。我一个接一个地编写了测试，实现了通过每个测试的代码，一切似乎都正常运行。直到生产中出现错误为止。

这是相关的代码段：

now = datetime.datetime.utcnow()
today = now.date()
if event_date.date() == today:
    return "Today"

yesterday = today - datetime.timedelta(1)
if event_date.date() == yesterday:
    return "Yesterday"

delta = (now - event_date).days

if delta < 7:
    return _number_to_text(delta) + " days ago"

if delta < 30:
    weeks = math.floor(delta / 7)
    if weeks == 1:
        return "A week ago"

    return _number_to_text(weeks) + " weeks ago"

if delta < 365:
    ... # Handle months and years in similar manner.

测试正在检查今天，昨天，四天前，两周前，一周前等事件发生的情况，并相应地构建了代码。

我错过的是，某事件可能在前一天发生，而可能是一天前发生：例如，发生在26小时前的事件可能是一天前发生，而如果现在是凌晨1点，则可能不是昨天，更确切地说，这是一点的东西，但由于delta是整数，所以它将只是一个。在这种情况下，应用程序显示“一天前”，这显然是意外的，并且在代码中未处理。可以通过添加以下内容进行修复：

if delta == 1:
    return "A day ago"

在计算完之后delta。

尽管该错误的唯一负面影响是我浪费了半个小时才想知道这种情况的发生方式（并且相信它与时区有关，尽管在代码中统一使用了UTC），但它的存在却使我感到困扰。它表明：

• 即使在这样简单的源代码中，犯逻辑错误也是非常容易的。
• 测试驱动的开发无济于事。

同样令人担忧的是，我看不到如何避免此类错误。除了在编写代码之前要多思考之外，我唯一能想到的方法是为我认为永远不会发生的情况添加很多断言（例如我认为一天前一定是昨天），然后逐一遍历在过去的十年中，检查是否有任何违反声明的情况，这似乎太复杂了。

我如何才能避免一开始就创建此错误？

这些是您通常在红色/绿色/重构的重构步骤中发现的错误类型。不要忘记这一步！考虑如下重构（未调试）：

def pluralize(num, unit):
    if num == 1:
        return unit
    else:
        return unit + "s"

def convert_to_unit(delta, unit):
    factor = 1
    if unit == "week":
        factor = 7 
    elif unit == "month":
        factor = 30
    elif unit == "year":
        factor = 365
    return delta // factor

def best_unit(delta):
    if delta < 7:
        return "day"
    elif delta < 30:
        return "week"
    elif delta < 365:
        return "month"
    else:
        return "year"

def human_friendly(event_date):
    date = event_date.date()
    today = now.date()
    yesterday = today - datetime.timedelta(1)
    if date == today:
        return "Today"
    elif date == yesterday:
        return "Yesterday"
    else:
        delta = (now - event_date).days
        unit = best_unit(delta)
        converted = convert_to_unit(delta, unit)
        pluralized = pluralize(converted, unit)
        return "{} {} ago".format(converted, pluralized)

在这里，您在较低的抽象级别上创建了3个函数，这些函数具有更大的内聚力，并且更容易进行隔离测试。如果您遗漏了您想要的时间跨度，它将在简单的辅助函数中像拇指一样伸出来。此外，通过删除重复项，可以减少出错的可能性。实际上，您实际上必须添加代码来实现破损的情况。

在查看这样的重构形式时，也更容易想到其他更微妙的测试用例。例如，best_unit如果delta为负怎么办？

换句话说，重构不仅是为了使其美观。它使人类更容易发现编译器无法发现的错误。

测试驱动的开发无济于事。

似乎确实有帮助，只是您没有针对“一天前”的情况进行测试。大概是在发现这种情况后，您添加了一个测试；这仍然是TDD，因为发现错误后，您可以编写单元测试来检测错误，然后进行修复。

如果您忘记编写行为测试，那么TDD并没有什么帮助您的；您忘了编写测试，因此不编写实现。

发生在26小时前的事件将是一天前

如果问题定义不明确，测试将无济于事。显然，您将日历天与以小时计算的天数混合在一起。如果您坚持日历日，那么26小时前的凌晨1点不是昨天。如果您坚持几个小时，那么26小时前的时间将舍入到1天之前的时间，而不考虑时间。

你不能 TDD非常适合保护您免受可能发现的问题的影响。如果遇到从未考虑过的问题，这将无济于事。最好的选择是让其他人测试系统，他们可能会找到您从未考虑过的极端情况。

相关阅读： 大型软件是否有可能达到绝对零错误状态？

我通常会采用两种方法可以找到帮助。

首先，我寻找边缘情况。这些是行为改变的地方。在您的情况下，行为会沿着正整数天的顺序在几个点发生变化。有一个边缘案例为零，一个，七个，等等，然后我将在边缘案例及其周围编写测试案例。我要在-1天，0天，1小时，23小时，24小时，25小时，6天，7天，8天等时间使用测试用例。

我要寻找的第二件事是行为模式。按照您数周的逻辑，您需要进行一周的特殊处理。在未显示的其他每个间隔中，您可能都有类似的逻辑。这个逻辑是不存在的日子里，虽然。我会怀疑地看待这个问题，直到我可以证实地解释为什么这种情况有所不同，或者我添加了逻辑。

你不能赶上存在于与TDD您的要求的逻辑错误。但是，TDD仍然可以提供帮助。毕竟，您发现了错误，并添加了一个测试用例。但从根本上说，TDD 仅确保代码符合您的思维模型。如果您的思维模式存在缺陷，那么测试用例将无法抓住它们。

但是请记住，在修复错误的同时，您已经确保没有破坏现有的运行行为的测试用例。这非常重要，很容易修复一个错误，但要引入另一个错误。

为了事先发现那些错误，您通常尝试使用基于等效类的测试用例。使用该原理，您可以从每个等价类中选择一个案例，然后再选择所有边缘案例。

您可以选择今天，昨天，几天前，一周前和几周前的日期作为每个等效类的示例。在测试日期时，还应确保测试未使用系统日期，而是使用预定日期进行比较。这也将突出显示一些极端情况：您将确保在一天中的任意时间运行测试，直接在午夜之后，午夜之前甚至是午夜直接运行测试。这意味着对于每个测试，将有四个基准时间被测试。

然后，您可以系统地将边缘情况添加到所有其他类中。您今天有考试。因此，应在行为切换前后添加一个时间。昨天也一样。一个星期前的情况相同，依此类推。

很有可能，通过系统地枚举所有边缘情况并为它们写下测试用例，您会发现您的规范缺少一些细节并添加它。请注意，处理日期是人们经常会犯错的事情，因为人们经常忘记编写测试，以便可以在不同的时间运行它们。

但是请注意，我写的大部分内容与TDD无关。关于写下等效类并确保您自己的规范足够详细。这是最小化逻辑错误的过程。TDD只是确保您的代码符合您的思维模型。

提出测试用例很难。基于等价类的测试还不是全部，并且在某些情况下，它可以大大增加测试用例的数量。在现实世界中，添加所有这些测试通常在经济上不可行（即使从理论上讲，也应该这样做）。

我能想到的唯一方法是为我认为永远不会发生的情况添加很多断言（例如我相信一天前一定是昨天），然后在过去十年中每秒循环浏览一次，以检查任何断言违规，这似乎太复杂了。

为什么不？这听起来是个不错的主意！

在代码中添加合同（断言）是提高其正确性的非常可靠的方法。通常，我们将它们添加为函数输入的前提条件，并作为函数返回的后置条件。例如，我们可以添加一个后置条件，即所有返回的值都采用 “ A [unit] ago”或“ [number] [unit] s ago”的形式。如果以一种有条理的方式完成工作，这将导致按合同进行设计，这是编写高保证代码的最常见方法之一。

至关重要的是，这些合同并不打算进行测试。它们和测试一样，都是代码规范。但是，您可以通过合同进行测试：在测试中调用代码，如果没有合同引发错误，则测试通过。通过循环每过去十年的第二个有点多。但是我们可以利用另一种称为基于属性的测试的测试样式。

在PBT中，您无需测试代码的特定输出，而是测试输出是否符合某些属性。例如，一个特性reverse()功能，对于任何名单l，reverse(reverse(l)) = l。这样编写测试的好处是，您可以让PBT引擎生成数百个任意列表（以及一些病理列表），并检查它们是否都具有此属性。如果没有，引擎会“缩小”失败的情况，以找到破坏代码的最小列表。看起来您正在编写Python，它具有假设作为主要的PBT框架。

因此，如果您希望找到一种您可能不会想到的棘手的极端情况的好方法，将合同和基于属性的测试一起使用将大有帮助。当然，这并不能代替编写单元测试，但确实可以增加它，这确实是我们作为工程师可以做到的最好的选择。

这是一个示例，其中添加一些模块化将很有用。如果多次使用容易出错的代码段，则最好将其包装在函数中。

def time_ago(delta, unit):
    delta_str = _number_to_text(delta) + " " + unit;
    if delta == 1:
        return delta_str + " ago"
    else:
        return delta_str = "s ago"

now = datetime.datetime.utcnow()
today = now.date()
if event_date.date() == today:
    return "Today"

yesterday = today - datetime.timedelta(1)
if event_date.date() == yesterday:
    return "Yesterday"

delta = (now - event_date).days

if delta < 7:
    return time_ago(delta, "day")

if delta < 30:
    weeks = math.floor(delta / 7)
    return time_ago(weeks, "week")

if delta < 365:
    months = math.floor(delta / 31)
    return time_ago(months, "month")

测试驱动的开发无济于事。

如果编写测试的人是对抗性的，则TDD作为一种技术最为有效。如果您不是成对编程，那么这将很困难，因此考虑此问题的另一种方法是：

• 不要编写测试来确认正在测试的功能是否正常运行。编写故意破坏它的测试。

这是另一种技术，适用于在有或没有TDD的情况下编写正确的代码，并且可能与实际编写代码一样复杂（如果不是那么复杂的话）。它是您需要练习的东西，而它没有一个简单，简单的答案。

编写功能强大的软件的核心技术，也是了解如何编写有效测试的核心技术：

了解函数的前提条件-有效状态（即您对函数作为方法的类的状态做出的假设）和有效输入参数范围-每个数据类型都有一个可能值范围-其中一个子集将由您的功能处理。

如果您只是在显式地测试函数输入时假设了这些，并确保在没有进一步处理的情况下记录或抛出了违规和/或函数错误，那么您可以快速知道您的软件是否在生产中失败，请使其功能强大和容错能力，并发展您的对抗测试写作技巧。

注意 关于前后条件，不变量等的完整文献，以及可以使用属性应用它们的库。我个人不喜欢这么正式，但值得研究。

这是有关软件开发的最重要的事实之一：编写完全没有错误的代码是绝对，绝对不可能的。

TDD不会避免您引入与您未想到的测试用例相对应的错误。这也不会免除您编写不正确的测试而没有意识到它，然后编写恰巧通过错误测试的错误代码的麻烦。而且曾经创建的所有其他单一软件开发技术也有类似的漏洞。作为开发人员，我们是不完美的人。最终，无法编写100％无错误的代码。它永远也不会发生。

这并不是说您应该放弃希望。尽管不可能编写出完全完美的代码，但是编写出很少有在极少数情况下出现的错误的代码是有可能的，因此该软件非常实用。在实践中不表现出错误行为的软件极有可能编写。

但是编写它需要我们接受一个事实，即我们将生产错误的软件。几乎每一个现代软件开发实践都在某种程度上围绕防止错误首先出现或保护自己免受我们不可避免地产生的错误的后果而建立：

• 收集全面的要求可以使我们知道代码中的不正确行为。
• 编写干净，经过精心设计的代码可以更轻松地避免一开始就引入错误，并且在我们识别出错误时更容易修复它们。
• 编写测试使我们能够记录我们认为软件中许多最严重的错误的记录，并证明我们至少避免了这些错误。TDD在代码之前生成这些测试，BDD从需求中生成这些测试，老式的单元测试在代码编写之后生成测试，但是它们都可以防止将来出现最差的回归。
• 同行评审意味着每次更改代码时，至少有两双眼睛看到了该代码，从而减少了错误进入主代码的频率。
• 使用将错误视为用户故事的错误跟踪器或用户故事跟踪器意味着，当出现错误时，它们会被跟踪并最终得到处理，而不是被遗忘并始终如一地以用户的方式接受。
• 使用登台服务器意味着在主要版本发布之前，所有显示阻止程序错误都有机会出现并得到解决。
• 使用版本控制意味着在最坏的情况下，将带有重大错误的代码交付给客户，您可以在进行整理时执行紧急回滚，并将可靠的产品重新交付客户。

解决您发现的问题的最终方法不是与无法保证不能编写无错误代码的事实相反，而是要接受它。在开发过程的所有领域中都采用行业最佳实践，您将一如既往地向用户交付代码，尽管这些代码虽然不够完善，但足以胜任工作。

您以前根本没有想到过这种情况，因此没有针对它的测试用例。

这种情况一直发生，而且很正常。您在创建所有可能的测试用例上付出了多少努力始终是一个权衡。您可以花费无限时间考虑所有测试用例。

对于飞机自动驾驶仪，您将花费比简单工具更多的时间。

通常可以考虑一下输入变量的有效范围并测试这些边界。

此外，如果测试人员与开发人员的身份不同，那么通常会发现更重要的案例。

（并且尽管代码中统一使用了UTC，但仍认为它与时区有关）

这是代码中的另一个逻辑错误，您尚未对其进行单元测试:)-您的方法将为非UTC时区的用户返回不正确的结果。在计算之前，您需要将“现在”和事件的日期都转换为用户的本地时区。

示例：在澳大利亚，当地时间上午9点发生了一个事件。由于UTC日期已更改，因此它将在上午11点显示为“昨天”。

• 让其他人编写测试。这样，对您的实现不熟悉的人可能会检查您从未想到的罕见情况。

• 如果可能，将测试用例作为集合注入。这使得添加另一个测试就像添加另一个行一样容易yield return new TestCase(...)。这可以朝探索性测试的方向发展，从而自动创建测试用例：“让我们看看一周前所有秒的代码返回了什么”。

您似乎误以为如果所有测试都通过了，那么您就不会有错误。实际上，如果所有测试都通过，则所有已知行为都是正确的。您仍然不知道未知行为是否正确。

希望您在TDD中使用代码覆盖率。为意外的行为添加新的测试。然后，您可以仅对意外行为进行测试，以查看其实际通过代码的路径。知道当前行为后，您可以进行更改以更正它，并且当所有测试再次通过时，您就会知道自己已经正确完成了。

这仍然并不意味着您的代码没有错误，只是比以前更好，而且所有已知行为都正确！

正确使用TDD并不意味着您将编写无bug的代码，这意味着您将编写更少的bug。你说：

要求比较明确

这是否意味着在要求中指定了超过一天但不是昨天的行为？如果您错过书面要求，那是您的错。如果您在编写代码时发现需求不完整，那么对您有好处！如果按照需求工作的每个人都错过了这种情况，那么您并不比其他人差。每个人都会犯错，而犯错越细微，就越容易错过。这里最大的收获是TDD 不能防止所有错误！

即使在这样简单的源代码中，犯逻辑错误也是非常容易的。

是。测试驱动的开发不会改变这一点。您仍然可以在实际代码以及测试代码中创建错误。

测试驱动的开发无济于事。

哦，但是做到了！首先，当您注意到该错误时，您已经具有完整的测试框架，并且只需要在测试中修复该错误（以及实际的代码）。其次，您不知道如果一开始没有做TDD的话还会有多少个bug。

同样令人担忧的是，我看不到如何避免此类错误。

你不能 甚至NASA都没有找到避免错误的方法。我们这个小人类当然也不会。

除了在编写代码之前要多考虑之外，

那是谬论。TDD的最大好处之一是您可以用较少的思想进行编码，因为所有这些测试至少都能很好地捕获回归。而且，即使是TDD或特别是TDD技术，也不会一开始就交付无错误的代码（否则您的开发速度就会停滞不前）。

我能想到的唯一方法是为我认为永远不会发生的情况添加大量断言（例如我认为一天前一定是昨天），然后在过去十年中每秒循环浏览一次，以检查任何断言违规，这似乎太复杂了。

这显然与仅编码您现在实际需要的宗旨相冲突。您以为您需要这些案件，事实如此。这是一段非关键的代码。就像您说的那样，没有损坏，只是您想知道它已经30分钟了。

对于关键任务代码，您实际上可以按照您说的做，但对于日常的标准代码则不能。

我如何才能避免一开始就创建此错误？

你不知道 您相信自己的测试可以找到大多数回归分析；您要保持红色-绿色重构周期，在实际编码之前/期间编写测试，并且（重要！）实现使红色-绿色切换所需的最小数量（不多，不少）。最终将获得很好的测试覆盖率，至少是正面的。

如果不是（如果不是）发现错误，则编写测试以重现该错误，并以最少的工作量修复该错误，以使所述测试从红色变为绿色。

您刚刚发现，无论您多么努力，都永远无法捕获代码中所有可能的错误。

因此，这意味着即使尝试捕获所有错误也是徒劳的，所以您应该只使用TDD之类的技术来编写更好的代码，而该代码中的bug较少，而不是0 bug。

相应地，这意味着您应该减少使用这些技术的时间，而将节省下来的时间用于替代方法，以发现贯穿开发网络的错误。

其他选择，例如集成测试或测试团队，系统测试以及记录和分析这些日志。

如果您无法捕获所有错误，则必须制定适当的策略来减轻从您身边溜走的错误的影响。如果仍然要执行此操作，则为此付出更多的努力比尝试（徒劳地）阻止它们首先更有意义。

毕竟，它花费大量时间在编写测试上是毫无意义的，而且在您将产品提供给客户的第一天，它就倒了，特别是如果您当时不知道如何查找和解决该错误的话。验尸和交付后的错误解决是如此重要，并且比大多数人在编写单元测试上花费的精力更多。保留单元测试中的复杂位，不要在先尝试完美。