我正在编写一个.NET CIL反编译器（只是为了好玩）。我无法弄清楚如何在我的项目中对实际“反编译”的东西进行单元测试，特别是读取二进制文件的解码器＆amp;将其解码为有意义的数据结构。我附带的方法是存储可执行文件，这些文件在我的测试项目所在的同一目录中进行解码，并且只是在测试的初始化方法中读取它们。有许多文件，具有不同的文件格式案例。
这看起来并不优雅。将这些文件嵌入到单独的资源程序集中，或者甚至使用假对象，这会更好吗？这将返回我想要的每个用例的结果？ （有很多用例，因此配置这样的假对象将花费大量时间，查找具有特定情况的可执行文件要容易得多）。
最后，也许解码器不是应该进行单元测试的东西？
答案 0 :(得分：2)
据我所知，解码器的逻辑非常复杂，根据您所说的状态，可执行文件中有很多情况。所以测试这段代码是个好主意。
你很难过我们现在有两个选择：为特定案例提供一堆文件，并假设每个案例都有假对象。让我们回顾一下。
拥有一堆文件与构建虚假对象。
曾几何时，我花了很多时间思考这个问题。因此，让我们回顾一下我在实践中遇到的一些案例以及我做出的结论。我的一个项目中有一个强大的xml解析逻辑，我必须选择是将xml存储在xml个文件中，还是C#个文件中作为字符串文字或通过构建XDocument对象来模拟我需要的每个特定情况。最后的方法是杀了我，但它看起来像“正确和优雅”，然后我试图切换到C#字符串文字，这也是一种矫枉过正。编辑和理解这个巨大的字符串非常困难。所以我只创建了xml文件并忘记了所有问题。
在您的情况下，您似乎不需要经常编辑二进制文件，但构建虚假对象也需要花费大量时间。如果没有“廉价”的可能性来伪造这种逻辑，我会建议使用文件。我也不建议将它们放在资源中，你将从中获得单元测试项目没有任何好处。
另一个论点。为什么我们需要假物品？我们需要它们伪造我们的依赖关系并将被测系统（SUT）与我们正在测试的逻辑无关的所有内容隔离开来。有时我们的应用程序中有低级别的层，比如数据库提供程序或解码器，例如在使用伪对象有助于测试代码的情况下，但在实际场景中无法测试代码。通常，这可以通过缓慢覆盖此低级层来解决，并且可以使用integration tests。所以在你的情况下，我们只考虑你要为你的应用程序的最低级别编写一堆集成测试，这是好的和优雅的方法=）并且在这样做之后你将准备好从这个应用程序层抽象并写快速，再次优雅 Unit Tests为你的其他人申请。