对编译器输出进行单元测试

Question

作为大学项目的一部分，我们必须为玩具语言编写一个编译器。 为了对此进行一些测试，我正在考虑如何最好地编写像单元测试这样的东西。 由于编译器是用haskell编写的，因此Hunit和quickcheck都可用，但可能不太合适。

我们怎么做任何非手动测试？ 我唯一的想法是有效编译到haskell，看看输出是什么，并使用一些shell脚本将其与编译程序的输出进行比较 - 这是相当多的工作，并不是太优雅无论是。

单元测试是为了帮助我们，而不是评估工作本身的一部分。

Answer 1

这实际上取决于您编写的编译器的哪些部分。 如果您可以保持阶段不同以帮助隔离问题，那就太好了，但是，在任何阶段，甚至在集成级别，单元测试由成对的源代码和手工编译的代码组成是完全合理的。 您可以从最简单的法律程序开始，并确保您的编译器输出与手动编译时相同的内容。

随着复杂性的增加，手工编译变得笨拙，编译器保留其所做的某种日志是有帮助的。 然后，您可以查阅此日志以确定是否为给定的源程序触发了特定的转换或优化。

根据您的语言，您可以考虑从程序片段集合中生成随机程序（在QuickCheck中）。 该生成器可以测试编译器的稳定性，以及处理可能无法预料的输入的能力。

Answer 2

单元测试应测试一小段代码，通常是一个类或一个函数。 词法和语义分析将各自进行单元测试。 Intermediate Represetation生成器也有自己的测试。

单元测试涵盖了一个简单的测试用例：它调用在受控环境中进行单元测试的函数，并验证（断言）函数执行的结果。 单元测试通常只测试一个行为，并具有以下结构，称为AAA：

• 安排：创建调用函数的环境
• 行动：调用该功能
• 断言：验证结果

Answer 3

一旦程序输出进入控制台（例如标准输出），测试就变得更加困难。 然后你必须使用一些外部工具，如grep或expect检查输出。

尽可能长时间地保持数据结构中函数的返回值。 如果编译器的输出是汇编代码，则在内存中构建一个字符串（或字符串列表）并在最后一刻输出它。 这样，您可以更直接，更快速地测试字符串的内容。

Answer 4

看看shelltestrunner 。 以下是一些示例测试 。 它也在这个编译器项目中使用 。

Answer 5

一个选项是这个人正在做的方法来测试真正的编译器：与你可以对话的人一起聚会，每个人编译并运行相同的程序集，然后比较输出。 请务必添加您使用的每个测试用例，因为更多输入会使其更有效。 通过自动化和源代码控制获得一点乐趣，您可以使其易于维护。

一定要先得到教授的确定，但由于你只是分享测试用例和输出，我看不出他有多少空间可以反对。