测试癌症

随着我的职业生涯转向全职写作，我经常担心自己会远离日常软件开发的现实。我看到其他知名人士与现实脱节，我担心自己也会遭遇同样的命运。我抵制这种现象的最大来源是 Thoughtworks，它就像一剂定期的现实剂量，让我脚踏实地。

Thoughtworks 也是我从该领域获得想法的来源，我喜欢写一些我的同事发现和开发的有用东西。通常这些都是有用的想法，我希望我的读者中有些人能够使用它们。我今天的话题不是那么令人愉快。这是一个问题，而且我们还没有答案。

场景是这样的。我们为客户执行一个项目，并交付一个闪闪发光的全新软件。正如我们现在习惯的那样，我们还交付了一套用于该软件的自动化测试（通常测试代码行数与功能代码行数一样多）。这些测试通常是单元测试和范围更广的功能测试和验收测试的混合。无论哪种方式，测试都充当软件功能的活动描述，以及一个错误检测器，以便在我们改进软件时快速发现问题。我们珍视这些测试，它们是我们成功构建软件系统的关键。

几个月后，满意的客户打电话让我们对软件进行进一步的工作，添加新功能和能力。我们来了，渴望在一个可能存在缺陷的代码库上工作——但至少是我们的缺陷。然后我们发现了一个令人不快的事情。

测试不再运行。

有时测试被排除在构建脚本之外，并且已经几个月没有运行了。有时“测试”会运行，但其中很大一部分被注释掉了。无论哪种方式，我们宝贵的测试都受到了可怕的癌症的困扰，这种癌症既耗时又令人沮丧，难以根除。

我们询问发生了什么事，并被告知诸如“我们做了一些更改，一些测试失败了，所以我们删除了测试”之类的话。你可以将其视为我们的失败——我们没有完全教会客户团队测试的价值。我们需要做更多工作来传递测试失败需要调查，而不是简单地忽略的理念。但无论任何人怎么说，我们都发现测试癌症是一种常见的疾病。

我们不认为测试癌症的出现是反对编写测试的理由。即使在离开后的第二天，一种特别恶性的毒株将它们全部消灭，我们仍然从构建系统时获得了一些价值。而且测试并不总是会得癌症。我们最近与一位开发人员交谈，他维护了我们几年前交付的系统后，成为了 TDD 的信徒。测试使我们的代码比其他公司后来添加的代码更容易使用。