我一直在阅读有关单元测试的很多内容，并且我第一次强烈考虑将它与C ++和TDD一起使用。我遇到的问题是我在创建测试时看到的所有示例，当我考虑如何开始为即将开发的项目编写测试时，它们看起来太微不足道了。可能是我错过了单元测试的重点，所以请告诉我这是否是这种情况。
很容易理解一个功能，例如检查素数。它有一个简单的输入（要测试的数字）和一个简单的输出（真或假）。这里很容易理解并创建单元测试。
现在，让我们来看一个防火墙应用程序，它有一个规则配置文件和一个评估引擎，用于按特定顺序评估这些规则，用于特定输入;网络数据包的详细信息，如IP，子网，端口，域等。
在没有编写单元测试的情况下，我认为首先编写一个解析器来将规则配置文件解析为类，然后编写规则引擎，将给定的网络数据包与这些类中的规则进行比较，逐步执行规则他们被解析，直到找到匹配。
单元测试和TDD声明在编写代码之前，应首先编写失败的测试。因此，在防火墙项目的情况下，您是否可以通过编写检查文件解析的测试来开始，通过创建模拟文件来提供一组特定的规则，或者这只是测试文件的读取，这通常不是推荐用于单元测试，而是集成测试？如果要在这里进行测试，应该测试什么？
另外，如何考虑为这样的规则引擎编写测试以评估规则？如果网络数据包的详细信息是输入，则输出将是数据包是否被接受，拒绝或忽略。这样的测试几乎与规则引擎的测试相同，那么如何将其分解为小的“单元”测试呢？
答案 0 :(得分：1)
您需要对解析器进行测试。对于给定的输入字符串，请确保输出正确的规则对象。这不会访问文件，因为您的解析器不应该紧密耦合到文件I / O.
您需要针对每条规则进行测试。确保规则为给定的数据包提供您想要的结果。这可能是最重要的部分;一定要彻底测试边缘情况。你不希望任何这些规则行为不端，因为它们会受到恶意输入的轰炸。
您需要对规则系统进行测试。编写简单的测试规则并使用它们来确保规则系统正确地分派数据包并对响应进行操作。
所有这些都可以在实际代码之前轻松编写。