原副标题：PDP合作开发：PDPTDD构架
也许单元试验最关键的原素是试验构架。在这篇昌明中，我们将探讨在PDP合作开发中C词汇的各种优先选择，并概要分析异同。
考虑因素
Test Runners
绝大多数PDP程式设计采用C，下面探讨的所有构架都是针对C或C++的。这这类会带来许多困难。许多单元试验构架利用了被称为“反思”的词汇优点。事实上，这是在运转时确定正在继续执行的程序的结构信息的能力。它对向构架人格注册登记的试验十分管用，并广泛用于面向全国Ruby、Python和Java等词汇的构架。
事实上，这意味着C中的试验构架须要开发人员做更多的增设工作。绝大多数构架须要两个全自动撰写的“runner”来初始化试验组件，这可能将会引致严重错误，例如忘掉向runner加进某一的试验。有许多辅助工具能帮助智能化那个过程，但它无此严格的“试验构架”的范围内——它这类更近似于完备的构筑控制系统。
C++有许多容许反思的优点，所以试验该词汇的组件能实现自动试验注册登记。在绝大多数情况下，将完全用C撰写的项目校对和试验为C++是可能将的。这一般来说是两个好的软件系统，但对不习惯这种词汇的PDP合作开发者来说可能将会不太难受。
在硬体上运转
有一则该文，探讨了运转试验的最差位置。它列举了三个相同的快捷键：通过辅助工具包的合作开发控制系统、邻近地区服务站或控制系统硬体。一般来说，采用前两个快捷键中的两个是有象征意义的，但在某些情况下(或相同的试验)，采用其他快捷键可能将有象征意义。
科折粉，试验构架的优先选择将影响到是否能继续执行这些操作。根据你平台需用的辅助工具包类型，可能将极难采用倚赖在操作控制系统下运转的辅助工具(如check))。这肯定不会对裸金属硬体这类起作用。另一方面，当试验失败可能将引致单向严重错误时，具备在单独的门牌号空间中运转试验的机能是十分好的。
构架快捷键
Unity
那个试验构架很轻，十分易于随身携带。合作开发者宣称，它能移殖到任何构架上，从高效能的x86电脑到8位中央处理器，包括具备谜样机能的构架，如怪异的有理数长度。它专门针对PDP合作开发。
它的缺点是缺乏高级机能，如门牌号空间隔离，或自动运转程序生成和试验集成。它与ThrowTheSwitch辅助工具组件集成得很好，其中包括CMock、CException以及Ceedling。当一起采用时，Unity的简单性的许多缺点被减轻了。
Check
check是另两个相对轻量级的C单元试验构架。与Unity相同，相反，它专注于安全和简单易用。它出名的主要原因是它在两个隔离的门牌号空间中运转每个试验，这意味着能捕获无效的内存访问。相比之下，采用Unity的试验会因为单向严重错误而彻底失败。
它还有许多比Unity更方便的机能，包括参数化试验，能方便地撰写应该在一系列相同值上验证输出的例程。它在设计时没有考虑裸机PDP合作开发。
check也有缺点。首先，很明显，是对操作控制系统的依赖，这意味着直接移殖到PDP控制系统十分困难，并且在辅助工具包下交叉校对运转时可能将会有问题。
其次，生成子进程比简单的函数初始化要昂贵得多，所以当check必须运转许多试验时，它往往会停滞不前。
像任何其他纯C构架一样，试验运转程序必须手工撰写。
GoogleTest
GoogleTest是Google的单元试验构架。它是用C++撰写的，但稍加调整就能用来试验C应用程序。它支持采用Google Mock，这对试验倚赖硬体的模块是必要的。
GoogleTest确实支持在原则上的门牌号空间中运转试验，但默认情况下并不这样做。这些试验被称为“死亡试验”，它主要用于捕捉预期的故障，而不是对意外segfaults等的保护。
那个试验构架的文件十分好，PDP合作开发者值得一看。
