基本上我有两个主要问题：
问题是我有几个依赖于数据库连接和/或通信应用程序的应用程序，这意味着大多数测试用例都是集成测试（或者我认为）。
大多数类本身都相当简单，但实现通信协议的类，对于自动化测试很有用，似乎很适合“单元测试”模型。
另一个例子。我开发了I管道结构，支持消费者/生产者模式的多线程支持。当一个线程读取管道并发现它为空时，它会阻塞，直到一个写入器写入管道。我应该使用单元测试来测试该类吗？
你如何决定单位测试的内容？
编辑：我的意思是为自动化单元测试编写单元测试。
答案 0 :(得分：4)
您单元测试代码的单位。真正的问题是究竟是什么构成一个单位？
在面向对象的环境中，单元是一个类。一个类，因为对象的行为随对象的状态而变化，因此单独测试方法不会产生最完整的结果。
首先，您需要识别类的不变量。也就是说，对于班级的所有实例而言总是如此。例如。在分数类中，不变量可能是分母！= 0.
接下来，您需要确定每种方法的合同，即方法的前后条件。
然后，您可以针对可能出现的每种情况编写测试。因此，对于单个类，您可能最终会使用许多测试方法来测试每种方法可能遇到的各种条件。在每次测试中，您都要确保该类的不变量保持不变，并且方法的契约永远不会被破坏。
在某些情况下，例如您提供的示例可能需要在环境中创建其他对象以测试您的类的条件。在这些情况下，您可以使用模拟对象。
答案 1 :(得分：1)
您应该抽象出您的基础架构问题（即从数据库中检索数据的代码，执行文件i / o的代码等），以便您可以存根/模拟这些部分，以便对您的应用程序进行单元测试。然后，您将能够针对您的基础架构代码编写针对性/特定的测试来测试它。
您将发现自己创建更多接口（在您的应用程序中创建），并且需要使用更好的OO原则（即SOLID）来开发更易于测试的应用程序。
一年前我和你在一起的那条船在同一条船上。而那本真正帮助我完成它的那本书（以及一些实践练习）是The Art of Unit Testing by Roy Osherove
答案 2 :(得分：1)
在专用的受控环境中对单元测试单元（即方法或功能）隔离进行单元测试。每个单元测试通过仅实例化执行一个测试所需的类，将它们置于已知状态，然后调用要测试的方法并验证结果，在自己的环境中创建。此验证是通过关于方法的行为的断言完成的（与其实现相反）。
执行行为而不是执行的验证很重要，因为这允许在不破坏单元测试的情况下修改实现，因此使用单元测试作为修改的安全网。
所有语言都有[至少]一个unit test framework，其作用是执行单元测试。编写单元测试有两种方法：测试优先或测试最后。
测试优先也称为Test-Driven Development。基本上它需要三个步骤：
TDD的支持者声称这会产生可测试的代码，而事后可能很难编写单元测试，特别是当方法执行多项操作时。建议遵循单一责任原则。
关于管道结构和通信协议示例，一些指导原则说明了这一点 a test is not a unit test if：
当线程读取管道并找到时 它一直空着它直到一个作家 写入管道。我应该用吗？ 单元测试来测试那个类？
我会测试类，但不测试阻塞读取方法，因为我认为它是通过阻塞调用操作系统的read()函数构建的。
答案 3 :(得分：0)
单元测试是测试整个单元的工作方式与更改前相同，并对更改进行了改进。如果要更改模块的窗口，则测试模块。这与系统测试相比较，系统测试用于测试每个模块。如果您的更改影响了许多模块（不确定您的系统是如何设置的），那么它应该进行系统测试。
答案 4 :(得分：0)
这是考虑它的另一种方式 - 特别是如果你不是专注于面向对象的代码，而是更多的功能或程序代码。
理想情况下，单元测试应涵盖代码中的每条路径。您应该有机会看到代码中的每条路径都按预期和需要运行。如果您正在练习测试驱动开发，那么它暗示一切都会得到测试。
我认为查看此博文会有助于澄清：https://earnestengineer.blogspot.com/2018/03/unit-testing-what-to-test.html