如何对线程代码进行单元测试？

Question

如何对线程代码进行单元测试？

到目前为止，我已经避免了测试多线程代码的噩梦，因为它看起来太像雷区了。我想问人们是如何进行依赖线程成功执行的代码测试的，或者人们是如何测试那些只在两个线程以给定方式交互时才会出现的问题的呢？

对于今天的程序员来说，这似乎是一个非常关键的问题，把我们的知识集中在这个IMHO上是很有用的。

Answer 1

听着，没有简单的方法可以做到这一点。我正在做一个本质上是多线程的项目。事件来自操作系统，我必须同时处理它们。处理复杂的多线程应用程序代码的最简单方法是：如果测试太复杂，那么您就做错了。如果您有一个具有多个线程的实例，并且不能测试这些线程相互执行的情况，那么您的设计就需要重新进行。它既简单又复杂。多线程有许多方法可以避免线程同时运行在实例中。最简单的方法是使所有对象不可变。当然，这通常是不可能的。因此，您必须在设计中确定线程与同一个实例交互的位置，并减少这些位置的数量。通过这样做，您隔离了一些实际发生多线程的类，从而降低了测试系统的总体复杂性。但是，您必须认识到，即使这样做，您仍然不能测试每一种情况下，两个线程的步伐，彼此。要做到这一点，您必须在同一个测试中并发地运行两个线程，然后精确地控制它们在任何给定时刻执行的行。你能做的最好的就是模拟这种情况。但是，这可能需要您专门为测试编写代码，而这最多是实现真正解决方案的半步。测试代码以解决线程问题的最好方法可能是通过对代码的静态分析。如果您的线程代码没有遵循有限的线程安全模式集，那么您可能会遇到问题。我相信VS中的代码分析确实包含了一些线程知识，但可能并不多。看，目前的情况(可能还会有一个好时机)，测试多线程应用程序的最好方法是尽可能减少线程代码的复杂性。尽量减少线程交互的区域，尽可能最好地进行测试，并使用代码分析来确定危险区域。

Answer 2

这个问题发布的时候已经有一段时间了，但还是没有答案.有一种方法，我练习C#代码。对于单元测试，您应该能够编程。可复制测试，这是多线程代码中最大的挑战。因此，我的答案是将异步代码强制放入测试工具中，这是可行的。同步.这是Gerard Meszardos的书中的一个想法“xUnit测试模式并且被称为“谦卑对象”(第695页)：您必须分离核心逻辑代码和任何闻起来像异步代码的代码。这使您可以在同步方式，道路。您对在核心逻辑上执行的呼叫的时间有绝对的控制，因此可以进行可复制测试。这是分离核心逻辑和异步逻辑的好处。这个核心逻辑需要由另一个类包装，它负责异步地接收对核心逻辑的调用。代表们这些对核心逻辑的调用。生产代码只能通过该类访问核心逻辑。因为这个类只应该委托调用，所以它是一个非常“愚蠢”的类，没有太多的逻辑。因此，您可以将这个异步工作类的单元测试保持在最低限度。以上的任何东西(测试类之间的交互)都是组件测试。同样在这种情况下，如果你坚持“谦逊对象”模式，你应该能够对时间有绝对的控制。

Answer 3

真厉害！在我的(C+)单元测试中，我按照所使用的并发模式将其分解为几个类别：对于在单个线程中操作的类的单元测试，而不是线程感知的类-简单，像往常一样进行测试。单元测试监视对象(那些在调用者的控制线程中执行同步方法的方法)，这些方法公开了同步的公共API-实例化了执行API的多个模拟线程。构造执行被动对象内部条件的方案。包括一个更长时间运行的测试，它可以在很长一段时间内从多个线程中摆脱出来。这是不科学的，我知道，但它确实建立了信心。单元测试活动对象(封装自己的线程或控制线程的线程)-类似于上面的#2，根据类设计的不同而有所变化。公共API可能阻塞或非阻塞，呼叫者可能获得期货，数据可能到达队列或需要去排队。这里有很多种组合；白色的盒子离开了。仍然需要多个模拟线程来调用被测试对象。作为旁白：在我所做的内部开发人员培训中，我教并发支柱这两种模式作为思考和分解并发问题的主要框架。显然还有更高级的概念存在，但我发现这套基础知识可以帮助工程师远离困境。它还导致代码更易于测试，如上文所述。