如何使用 MSpec 有效测试固定长度的平面文件解析器？

Question

我有这个方法签名：ListParse(string[]lines)

ITMData 有 35 个属性。

您将如何有效测试这样的解析器？

问题：

• 我应该加载整个文件（我可以使用 System.IO）吗？
• 我应该将文件中的一行放入字符串常量中吗？
• 我应该测试一行或多行
• 我应该测试 ITMData 的每个属性还是应该测试整个对象？
• 我的测试的命名怎么样？

编辑

我将方法签名更改为 ITMData Parse(string line)。

测试代码：

[Subject(typeof(ITMFileParser))]
public class When_parsing_from_index_59_to_79
{
    private const string Line = ".........";
    private static ITMFileParser _parser;
    private static ITMData _data;

    private Establish context = () => { _parser = new ITMFileParser(); };

    private Because of = () => { _data = _parser.Parse(Line); };

    private It should_get_fldName = () => _data.FldName.ShouldBeEqualIgnoringCase("HUMMELDUMM");
}

编辑2

我仍然不确定是否应该每个类仅测试一个属性。在我看来，这使我能够为规范提供更多信息，即当我解析从索引 59 到索引 79 的单行时，我得到 fldName。如果我测试一个类中的所有属性，我就会丢失此信息。我是否过度指定了我的测试？

我的测试现在看起来像这样：

[Subject(typeof(ITMFileParser))]
public class When_parsing_single_line_from_ITM_file
{
    const string Line = ""

    static ITMFileParser _parser;
    static ITMData _data;

    Establish context = () => { _parser = new ITMFileParser(); };

    private Because of = () => { _data = _parser.Parse(Line); };

    It should_get_fld??? = () => _data.Fld???.ShouldEqual(???);
    It should_get_fld??? = () => _data.Fld???.ShouldEqual(???);
    It should_get_fld??? = () => _data.Fld???.ShouldEqual(???);
    It should_get_fld??? = () => _data.Fld???.ShouldEqual(???);
    It should_get_fld??? = () => _data.Fld???.ShouldEqual(???);
    It should_get_fld??? = () => _data.Fld???.ShouldEqual(???);
    It should_get_fld??? = () => _data.Fld???.ShouldEqual(???);
    ...

}

Answer 1

我应该加载整个文件（我可以使用 System.IO）吗？

如果这样做，它就不再是单元测试——它变成集成或回归测试。如果您希望它显示单元测试不会显示的可能错误，您可以这样做。但这不太可能。

单元测试可能会更好，至少在开始时是这样。

我应该将文件中的一行放入字符串常量吗？

如果您计划编写多个使用同一输入行的测试，那么当然可以。但就我个人而言，我可能倾向于编写一堆不同的测试，每个测试都传递不同的输入字符串。此时，没有太多理由创建常量（除非它是在测试方法内声明的局部常量）。

我应该测试一根或多根线吗？

您没有指定，但我假设您的输出与您的输入是一一对应的——也就是说，如果您传入三个字符串，您将获得三个 ITMData s回来了。在这种情况下，多线测试的需求将受到限制。

测试退化情况几乎总是值得的，在这种情况下将是一个空字符串数组（零行）。并且至少有一个包含多行的测试可能是值得的，这样您就可以确保迭代中没有愚蠢的错误。

但是，如果您的输出与输入是一对一的，那么您确实有另一种方法想要退出 - 您应该有一个 ParseSingleLine 方法。那么您的 Parse 只不过是迭代行并调用 ParseSingleLine 而已。您仍然需要对 Parse 进行一些测试，但大多数测试将集中在 ParseSingleLine 上。

Answer 2

如果我遇到这样的问题，我通常会这样做：

提前声明一个简短的免责声明：我认为我会更多地走“集成测试”或“测试整个解析器”路线，而不是测试单独的行。过去，我不止一次面临过这样的情况：大量实现细节泄漏到我的测试中，并迫使我在更改实现细节时经常更改测试。我猜是过度规范的典型情况；-/

1. 我不会在解析器中包含文件加载。正如 @mquander 建议的那样，我宁愿使用 TextReader 或 IEnumerable 作为输入参数。这将导致测试速度更快，因为您可以在内存中指定解析器输入，而不必接触文件系统。
2. 我不太喜欢手动滚动测试数据，因此在大多数情况下，我使用嵌入式资源和 ResourceManager 通过 assembly.GetManifestResource() 直接从规范程序集中加载测试数据。我的解决方案中通常有一堆扩展方法来简化资源的读取（例如 TextReader TextResource.Load("NAME_OF_SOME_RESOURCE")）。
3. 关于 MSpec：我使用每个文件一个类来解析。对于解析结果中测试的每个属性，我都有一个单独的 (It) 断言。这些通常是单行代码，因此额外的编码量并不大。就文档和诊断而言，恕我直言，这是一个巨大的优势，因为当属性未正确解析时，您可以直接看到哪个断言失败，而无需查看源代码或搜索行号。它也会出现在您的 MSpec 结果文件中。此外，您不会隐藏其他失败的断言（修复一个断言只是看到规范在下一个断言的下一行上失败的情况）。这当然迫使您更多地考虑在规范中使用的措辞，但对我来说这也是一个巨大的优势，因为我是语言形成思维这一观点的支持者。换句话说，如果您不知道如何命名您的断言，那么您的规范或实现可能有问题。
4. 关于解析器的方法签名：我不会返回像 List这样的具体类型。或数组，我还建议不要返回可变的 List类型。您在这里基本上说的是：“嘿，您可以在我完成后修改解析结果”，这在大多数情况下可能是您不想要的。我建议返回 IEnumerable相反（或 ICollection如果您确实需要事后修改它）

Answer 3

我通常会尝试考虑常见的成功和失败场景以及边缘情况。需求也有助于设置适当的用例。考虑使用 Pex 来枚举各种场景。

Answer 4

关于您的新问题：

我应该测试 ITMData 的每个属性还是应该测试整个对象？

如果您想安全起见，您可能应该至少进行一项测试来检查每个属性是否匹配。

我的测试的命名怎么样？

关于这个主题有很多讨论，例如这个。一般规则是，您的单元测试类中将有多个方法，每个方法都旨在测试特定的内容。在您的情况下，可能是这样的：

public void Check_All_Properties_Parsed_Correctly(){.....}

public void Exception_Thrown_If_Lines_Is_Null(){.....}

public void Exception_Thrown_If_Lines_Is_Wrong_Length(){.....}

因此，换句话说，测试您认为解析器“正确”的确切行为。完成此操作后，您在更改解析器代码时会感到更加轻松，因为您将拥有一个全面的测试套件来检查您是否没有破坏任何内容。请记住经常进行实际测试，并在进行更改时保持测试更新！

一般来说，我认为您可以通过谷歌搜索找到大多数问题的答案。还有几本关于测试驱动开发的优秀书籍，它们不仅会阐明 TDD 的如何，还会阐明为什么。如果您对编程语言相对不可知，我会推荐 Kent Beck 的 示例测试驱动开发，否则类似于 Microsoft .NET 中的测试驱动开发。这些应该会让你很快走上正轨。

编辑：

我是否过度指定了我的测试？

在我看来，是的。具体来说，我不同意你的下一句话：

如果我测试一个类中的所有属性，我就会丢失此信息。

您究竟以什么方式丢失信息？假设除了每个测试都有一个新类之外，还有两种方法可以进行此测试：

1. 对每个属性使用不同的方法。您的测试方法可以称为 CheckPropertyX、CheckPropertyY 等。当您运行测试时，您将准确地看到哪些字段通过了，哪些字段失败了。这显然满足了您的要求，尽管我会说这仍然是矫枉过正。我会选择选项 2：
2. 采用几种不同的方法，每种方法都测试一个特定的方面。这是我最初推荐的，我想你指的是这个。当其中一个测试失败时，每个方法您只能获得有关第一个失败的信息，但如果您很好地编码了断言，您将确切知道哪个属性不正确。考虑以下代码：

Assert.AreEqual("test1", myObject.PropertyX, "Property X was invalidly parsed");
Assert.AreEqual("test2", myObject.PropertyY, "属性 Y 被错误地解析");

当其中一个失败时，您将知道哪一行失败。当您修复了相关错误并重新运行测试时，您将看到是否有任何其他属性失败。这通常是大多数人采用的方法，因为为每个属性创建一个类甚至方法会导致太多的代码，并且需要太多的工作来保持最新。