单元测试是否可以帮助花旗避免这种昂贵的错误？

我读到了这句话：在合法交易被误认为测试数据15年之后，花在编程上的错误使花旗集团损失了700万美元。

在1990年代中期引入该系统时，程序代码过滤掉了从089到100的三位数分支代码的所有交易，并将这些前缀用于测试目的。

但是在1998年，公司在扩展业务时开始使用字母数字分支代码。其中包括代码10B，10C等，系统将该代码视为在排除范围内，因此，它们的交易已从发送给SEC的所有报告中删除。

（我认为这说明使用非显式数据指示符是次优的。填充并使用语义上显式的Branch.IsLive属性要好得多。）

除此之外，我的第一个反应是“单元测试会在这里有所帮助”……但是他们会吗？

我最近读了《为什么大多数单元测试会引起人们的兴趣浪费》，所以我的问题是：在引入字母数字分支代码后失败的单元测试会是什么样？

您是否真的在问，“单元测试是否对这里有所帮助？”，或者您在问，“任何种类的测试都可能对这里有所帮助？”。

最有帮助的测试形式是代码本身的前提条件断言，即分支标识符仅由数字组成（假设这是编码器编写代码时所依据的假设）。

然后，这可能在某种形式的集成测试中失败，并且一旦引入了新的字母数字分支ID，该声明就会崩溃。但这不是单元测试。

或者，可以对生成SEC报告的程序进行集成测试。此测试可确保每个真实的分支标识符都报告其事务（因此需要真实输入，以及所有使用中的分支标识符的列表）。因此，这也不是单元测试。

我看不到所涉及接口的任何定义或文档，但可能是单元测试可能未检测到错误，因为单元没有故障。如果允许单元假定分支标识符仅由数字组成，并且开发人员从未决定过代码应做的情况（如果代码不这样做），则他们不应编写单元测试以在非数字标识符的情况下强制执行特定行为，因为该测试将拒绝正确处理字母数字分支标识符的单元的假设有效实现，并且您通常不想编写阻止有效的单元测试未来的实现和扩展。或者也许是40年前写的一份文档（通过原始EBCDIC中的一些词典范围，而不是更人性化的整理规则）隐含地定义了10B是测试标识符，因为事实上它确实在089和100之间。 15年前，有人决定将其用作真实标识符，因此，“故障”不在正确实现原始定义的单元中：它在于未能注意到10B被定义为测试标识符的过程，因此不应将其分配给分支。如果将089-100定义为测试范围，然后引入标识符10 $或1.0，则在ASCII中也会发生同样的情况。碰巧在EBCDIC中，数字在字母后面。

可以想到的一个单元测试（或可以说是功能测试）可能已经保存了一天，这是对生成或验证新分支标识符的单位的测试。该测试将断言标识符必须仅包含数字，并将其写入以便允许分支标识符的用户采用相同的标识符。或者，也许某个地方有一个单元导入了真实的分支标识符，但从未看到过测试的标识符，并且可以对其进行单元测试以确保它拒绝所有测试标识符（如果标识符只有三个字符，我们可以枚举所有字符，然后比较它们的行为）验证程序与测试过滤器的验证程序以确保它们匹配，这是对点测试的常见异议）。然后，当有人更改规则时，单元测试将失败，因为它与新要求的行为相矛盾。

由于测试的存在是有充分的理由的，因此由于业务需求的变化而需要将其删除的点成为了某人获得工作的机会，“在代码中的每个位置都找到了我们想要的行为。更改”。当然，这很困难，因此也不可靠，因此决不能保证节省时间。但是，如果您在假设单位属性的测试中掌握了假设，那么您就给了自己一个机会，因此工作量并没有完全浪费。

我当然同意，如果没有首先用“有趣的形状”输入定义单位，那么就没有要测试的东西。杂乱的名称空间划分可能很难正确测试，因为困难不在于实现您的有趣定义，而在于确保每个人都理解并尊重您的有趣定义。那不是一个代码单元的本地属性。此外，将某些数据类型从“数字字符串”更改为“字母数字字符串”类似于使基于ASCII的程序处理Unicode：如果您的代码与原始定义紧密耦合，并且在数据类型是程序工作的基础，因此它经常是紧密耦合的。

认为这很大程度上是浪费精力，这有点令人不安

如果您的单元测试有时失败（例如，在重构时），并且这样做可以为您提供有用的信息（例如，您的更改是错误的），那么您的工作就不会浪费。他们不做的是测试系统是否正常运行。因此，如果您编写单元测试而不是进行功能测试和集成测试，那么您可能会次优地使用时间。

单元测试可能已经发现分支代码10B和10C被错误地归类为“测试分支”，但是我发现该分支分类的测试不可能足够广泛地捕获该错误。

另一方面，对所生成报告的抽查可能表明，分支10B和10C在报告中始终比现在允许该漏洞存在的15年要早得多。

最后，这很好地说明了为什么将测试数据与实际生产数据混合在一个数据库中是个坏主意。如果他们使用了包含测试数据的单独数据库，则无需将其从官方报告中过滤掉，也就不可能过滤掉太多。

该软件必须处理某些业务规则。如果有单元测试，则单元测试将检查该软件是否正确处理了业务规则。

业务规则已更改。

显然没有人意识到业务规则已更改，也没有人更改软件以应用新的业务规则。如果有单元测试，则必须更改这些单元测试，但是没有人会这样做，因为没有人意识到业务规则已更改。

因此，不，单元测试不会发现这一点。

例外情况是，单元测试和软件是由独立的团队创建的，而进行单元测试的团队更改了测试以应用新的业务规则。然后，单元测试将失败，希望可以导致软件更改。

当然，在相同情况下，如果仅更改软件而不更改单元测试，则单元测试也将失败。每当单元测试失败时，这并不意味着软件是错误的，这意味着软件或单元测试（有时两者）都是错误的。

否。这是单元测试的主要问题之一：它们使您陷入一种虚假的安全感。

如果您所有的测试都通过了，那并不意味着您的系统运行正常。这意味着您的所有测试都通过了。这意味着您有意识地思考并编写测试的设计部分正在按您有意地认为的那样工作，无论如何，这实际上并不是什么大问题：那是您实际上一直在密切注意的东西到，所以很可能您还是正确地做到了！但这并不能捕捉到您从未想到的案例，例如本案例，因为您从未想过为它们编写测试。 （如果有的话，您将意识到这意味着必须更改代码，并且已经进行了更改。）

不，不一定。

最初的要求是使用数字分支代码，因此将为接受各种代码并拒绝任何类似10B的组件进行单元测试。该系统本来可以正常工作（过去）。

然后，需求将发生变化，代码将更新，但这将意味着必须修改提供不良数据（现在是良好数据）的单元测试代码。

现在我们假设，管理系统的人员会知道是这种情况，并且会更改单元测试以处理新代码...但是，如果他们知道这种情况正在发生，他们也将知道会更改处理这些代码的代码。反正代码..他们没有那样做。如果您不知道更新测试，则最初拒绝代码10B的单元测试在运行时会高兴地说“这里一切都很好”。

单元测试适合于原始开发，但不适用于系统测试，尤其是长期遗忘了要求后的15年。

在这种情况下，他们需要的是端到端集成测试。您可以在其中传递希望使用的数据并查看是否可以使用的数据。有人会注意到他们的新输入数据没有产生报告，然后会进一步调查。

类型测试（使用随机生成的有效数据测试不变式的过程，例如Haskell测试库QuickCheck以及受其他语言启发的各种端口/替代品）可能已经解决了这个问题，单元测试几乎肯定不会完成。

这是因为在更新分支代码的有效性规则时，不太可能有人会考虑测试这些特定范围以确保它们正常工作。

但是，如果已使用类型测试，则在实施原始系统时，应该有人编写了一对属性，一个用于检查特定于测试分支的代码是否被视为测试数据，另一个用于检查是否没有其他代码。是...当更新分支代码的数据类型定义时（为了允许测试分支代码从数字到数字的任何更改都有效），此测试将开始测试新范围，很可能已经确定了故障。

当然，QuickCheck最早是在1999年开发的，因此赶上这个问题已经为时已晚。

我真的怀疑单元测试是否会对这个问题有所影响。听起来像是那些隧道视觉情况之一，因为功能已更改为支持新的分支代码，但这并未在系统的所有区域中执行。

我们使用单元测试来设计一个类。仅当设计已更改时才需要重新运行单元测试。如果某个特定单位没有变化，则未更改的单元测试将返回与以前相同的结果。单元测试不会向您显示更改对其他单元的影响（如果这样做的话，您不是在编写单元测试）。

您只能通过以下方式合理地检测到此问题：

• 集成测试-但是您必须专门添加新的代码格式，才能通过系统中的多个单元（即，如果原始测试包括现在有效的分支，它们只会向您显示问题）
• 端到端测试-企业应运行包含新旧分支代码格式的端到端测试

没有足够的端到端测试更加令人担忧。您不能依靠单元测试作为系统更改的唯一或主要测试。听起来好像只需要有人就新支持的分支代码格式运行报告。

运行时内置的断言可能有所帮助；例如：

1. 创建一个像 bool isTestOnly(string branchCode) { ... }
2. 使用此功能可以确定要过滤出的报告
3. 在分支创建代码的断言中重用该函数，以验证或断言不是（无法）使用这种类型的分支代码创建分支！
4. 在实时运行时启用此断言（而不是“除在代码的仅调试开发人员版本中以外，都已优化”）！

也可以看看：

• 单独的“调试”和“发布”版本？（即在运行时启用断言）
• 是应该测试内部实施还是仅测试公共行为？（即，与单元测试相比，系统测试可能更有用，覆盖面更广）

解决的方法是快速失败。

我们没有代码，也没有很多根据代码测试或不测试分支前缀的前缀示例。我们所拥有的是：

• 089-100 =>测试分支
• 10B，10C =>测试分支
• <088 =>可能是真实分支
• > 100 =>可能是真实分支

该代码允许数字和字符串的事实有点奇怪。当然，可以将10B和10C视为十六进制数，但是如果将前缀全部视为十六进制数，则10B和10C不在测试范围之内，将被视为实分支。

这可能意味着前缀存储为字符串，但在某些情况下被视为数字。这是我能想到的最简单的代码，它复制了这种行为（使用C＃进行说明）：

bool IsTest(string strPrefix) {
    int iPrefix;
    if(int.TryParse(strPrefix, out iPrefix))
        return iPrefix >= 89 && iPrefix <= 100;
    return true; //here is the problem
}

用英语来说，如果字符串是一个数字，并且介于89到100之间，则它是一个测试。如果不是数字，那就是测试。否则，这不是测试。

如果代码遵循此模式，则在部署代码时没有任何单元测试可以捕获此错误。以下是一些单元测试示例：

assert.isFalse(IsTest("088"))
assert.isTrue(IsTest("089"))
assert.isTrue(IsTest("095"))
assert.isTrue(IsTest("100"))
assert.isFalse(IsTest("101"))
assert.isTrue(IsTest("10B")) // <--- business rule change

单元测试表明“ 10B”应被视为测试分支。上面的@ gnasher729用户说，业务规则已更改，这就是上面的最后一个声明所显示的内容。在某个时候断言应该已经切换到isFalse，但是那没有发生。单元测试在开发和构建时运行，但此后再也没有。

这是什么教训？ 该代码需要某种方式来表示已收到意外输入。这是编写此代码的另一种方法，该代码强调该代码期望前缀为数字：

// Alternative A
bool TryGetIsTest(string strPrefix, out bool isTest) {
    int iPrefix;
    if(int.TryParse(strPrefix, out iPrefix)) {
        isTest = iPrefix >= 89 && iPrefix <= 100;
        return true;
    }
    isTest = true; //this is just some value that won't be read
    return false;
}

对于不了解C＃的用户，返回值指示代码是否能够解析给定字符串中的前缀。如果返回值为true，则调用代码可以使用isTest out变量检查分支前缀是否为测试前缀。如果返回值为false，则调用代码应报告预期的给定前缀，并且isTest out变量无意义，应将其忽略。

如果您可以接受例外处理，则可以改用以下方法：

// Alternative B
bool IsTest(string strPrefix) {
    int iPrefix = int.Parse(strPrefix);
    return iPrefix >= 89 && iPrefix <= 100;
}

这种选择更为简单。在这种情况下，调用代码需要捕获异常。无论哪种情况，代码都应该以某种方式向调用者报告它不希望将strPrefix转换为整数。这样，代码很快就会失败，银行可以迅速找到问题，而不会令SEC感到尴尬。

答案如此之多，甚至没有Dijkstra的名言：

测试表明存在缺陷，而不是缺陷。

因此，这取决于。如果对代码进行了正确的测试，则很可能不存在该错误。

我认为这里进行单元测试可以确保问题永远不会存在。

考虑一下，您已经编写了bool IsTestData(string branchCode)函数。

您编写的第一个单元测试应为null和空字符串。然后，对于长度不正确的字符串，然后对于非整数字符串。

要使所有这些测试通过，您必须在函数中添加参数检查。

即使您仅测试“好”数据001-> 999而不考虑10A的可能性，在开始使用字母数字时，参数检查仍将迫使您重写该函数，以避免其抛出异常