单元测试枚举转换器的最佳实践答案

【问题标题】：Best Practice for Unit Testing Enum Translator单元测试枚举转换器的最佳实践
【发布时间】：2012-06-05 13:40:05
【问题描述】：

对这类方法进行单元测试的最佳实践是什么？

public VerificationResultCode Translate(int value)
    {
        VerificationResultCode result;

        if (Enum.IsDefined(typeof(VerificationResultCode), (int)value))
            result = (VerificationResultCode)((int)value);
        else
            throw new UnknownResultReturnFromGatewayException();

        return result;
    }

VerificationResultCode 是 Enum 类型，如：

public enum VerificationResultCode 
{
        BankingNetworkError = 100,
        NotEqual =101,
        InputFormatError = 102,
        MerchantAuthenticationFailed = 103,

...
}

我们应该为每个 Enum 成员编写一个测试方法还是只编写一个包含大量断言的测试方法？

【问题讨论】：

一方面，您不应该将整数编码为双精度数。你会有虚假的失败。
两个测试。一个值正确，一个值不正确。注意你没有得到异常，然后你确实得到了异常。您正在对 CLR 从整数转换为枚举的能力进行单元测试的任何其他内容。
你在测试什么？枚举还是翻译方法？如果是后者，那么一个有效值和一个无效值（有预期的例外）应该这样做。如果是前者，那么您将需要一些带有定义的外部资源。

标签： c# unit-testing tdd

【解决方案1】：

代码几乎太琐碎，无法进行单元测试。您应该对依赖于VerificationResultCode 的行为进行单元测试，这也将测试Translate 函数。一个更大的问题是为什么你需要一个公共的翻译函数而不是把它封装在对象中？

【讨论】：

它是来自 Brownfield 应用程序的一个小型 sn-p，我们试图重构、增强和添加一些单元测试。
如果您正在重构遗留代码，那么您需要以足够大的粒度选择测试接缝，以便您可以在测试中重构。单元测试像您的示例这样的小型翻译功能可能会适得其反，因为当您重构时，您会破坏数十个这样的微单元测试。
感谢您的回答。你说这段代码对于单元测试来说太琐碎了。但是这部分是一些支付网关的小sn-p，有很多网络服务调用和数据访问逻辑。我想如果我测试依赖于枚举的行为，它有点像集成测试。
您将需要重构数据访问/Web 服务，这样您就可以在运行单元测试之前将这些依赖项注入虚假内容。当您需要重构、添加功能或进一步了解遗留代码时编写测试。不要仅仅为了进行单元测试而添加测试。 This book may help.