整理数据太麻烦时如何测试？

我正在编写一个解析器，作为其中的一部分，我有一个Expander将单个复杂语句“扩展”为多个简单语句的类。例如，它将扩展此内容：

x = 2 + 3 * a

变成：

tmp1 = 3 * a
x = 2 + tmp1

现在，我正在考虑如何测试此类，特别是如何安排测试。我可以手动创建输入语法树：

var input = new AssignStatement(
    new Variable("x"),
    new BinaryExpression(
        new Constant(2),
        BinaryOperator.Plus,
        new BinaryExpression(new Constant(3), BinaryOperator.Multiply, new Variable("a"))));

或者我可以将其编写为字符串并进行解析：

var input = new Parser().ParseStatement("x = 2 + 3 * a");

第二个选项更简单，更短且更易读。但它也引入了依赖性Parser，这意味着中的错误Parser可能会使测试失败。因此，测试将不再是一个单元测试Expander，我想在技术上成为一个集成测试Parser和Expander。

我的问题是：可以主要（或完全）依靠这种集成测试来测试此类Expander吗？

如果您可以简单地做的话，您将发现自己编写了更多的测试，这些测试具有更加复杂，有趣和有用的行为。所以涉及的选择

var input = new Parser().ParseStatement("x = 2 + 3 * a");

是相当有效的。它确实取决于另一个组件。但是，一切都取决于许多其他组件。如果您要模拟某个事物的生命力，则可能取决于许多模拟功能和测试装置。

开发者有时过度集中在他们的单元测试的纯度，或显影单元测试和单元测试只，无任何模块，集成，应力或其他类型的测试。所有这些形式都是有效和有用的，它们都是开发人员的适当责任-而不仅仅是Q / A或运营人员。

我使用的一种方法是从这些较高级别的运行开始，然后使用从它们生成的数据来构建测试的长格式，最低共母表达式。例如，当您转储input上面产生的数据结构时，则可以轻松构造以下内容：

var input = new AssignStatement(
    new Variable("x"),
    new BinaryExpression(
        new Constant(2),
        BinaryOperator.Plus,
        new BinaryExpression(new Constant(3), BinaryOperator.Multiply, new Variable("a"))));

一种在最低级别进行测试的测试。这样，您就可以得到很好的组合：少数几个最基本的原始测试（纯单元测试），但是没有花一个星期的时间在那个原始级别编写测试。这为您提供了时间资源，以使用Parser辅助工具编写更多，更少的原子测试。最终结果：更多的测试，更多的覆盖范围，更多的麻烦和其他有趣的案例，更好的代码和更高的质量保证。

当然可以！

您始终需要执行完整代码路径的功能/集成测试。在这种情况下，完整的代码路径意味着包括对生成代码的评估。那就是您测试解析x = 2 + 3 * a产生的代码，如果运行a = 5将设置x为17，如果运行a = -2将设置x为-4。

在此之下，您应该对较小的位进行单元测试，只要它实际上有助于调试代码。您拥有的粒度测试越精细，对代码的任何更改也需要更改测试的可能性也就越高，因为内部接口会发生变化。这样的测试没有什么长期价值，并且增加了维护工作。因此，存在收益递减的问题，您应该在此之前停下来。

单元测试使您可以查明损坏的特定项目及其在代码中的损坏位置。因此，它们非常适合进行细粒度的测试。好的单元测试将有助于减少调试时间。

但是，根据我的经验，单元测试很少能足以实际验证正确的操作。因此，集成测试也有助于验证操作链或操作顺序。集成测试可以帮助您完成功能测试。正如您指出的那样，由于集成测试的复杂性，很难在代码中找到测试中断的特定位置。它也具有更大的脆性，因为链中任何地方的故障都会导致测试失败。但是，您仍将在生产代码中保留该链，因此测试实际链仍然很有帮助。

理想情况下，您应该同时拥有这两种功能，但总的来说，自动测试总比没有测试好。

在解析器上进行大量测试，并在解析器通过测试时，将这些输出保存到文件中以模拟解析器并测试其他组件。