我有一个头文件，其中包含struct和一些方法的声明，以及一个＆＃39; C＆＃39;定义（实现）结构和方法的文件。现在在编写单元测试用例时，我需要检查一些结构变量（没有getter方法）是否被修改。由于结构的定义包含在C文件中，单元测试用例应该基于标题文件或C文件？
答案 0 :(得分：1)
测试系统其他部分可用的组件接口，大小写的标题，而不是接口的实现细节。
单元测试会对组件的行为进行断言，但不应该依赖于该行为的实现方式。这些测试描述了组件所做的，而不是 的完成方式。如果您更改实现但保留相同的行为，则测试仍应通过。
如果您的测试取决于具体的实施，那么它们将是脆弱的。更改实施将需要更改测试。这不仅是额外的工作，而且还无法保证测试应该提供的保证。如果您可以针对新实现运行现有测试，那么您可以确信新实现未改变其他组件可能依赖的行为。一旦你必须改变测试以便能够针对新的实现运行它，你必须仔细考虑你是否已经改变了测试过程中的任何期望。
使用此组件的公共接口测试无法访问的行为可能很重要。考虑一下这个界面可能设计得不好的好提示。 TDD鼓励首先进行测试＆＃34;方法，这是原因之一。如果您首先定义要对组件行为进行的断言，则必须设计一个公开该行为的接口。这就是使得流程＆＃34;测试驱动＆＃34;。
的原因如果您必须在他们测试的组件之后编写测试，那么至少尝试利用这个机会重新评估设计并从测试中学习。这个行为是一个实现细节，不值得测试，或者接口应该更新以暴露它（这可能比仅公开它更复杂，因为它现在应该是安全合理的系统的其他组件访问它公共属性）。
答案 1 :(得分：0)
我建议所有测试，除了开发人员在开发过程中执行的短暂内容之外，应该测试API而不是内部。毕竟，这是您需要满足的规范。
因此，如果您保持外部世界不的内容，那么这本身并不是需要直接测试的方面。相反，如果出现错误，那么影响外部世界， 影响你应该测试。
封装意味着可以自由地完全更改底层实现，而不会受到外部世界的影响，您会发现，如果您根据外部视图对测试进行编码，则不需要进行任何更改你做了这样的改变。
因此，例如，如果您的单位是地址簿，那么您应该测试的内容如下：
不之类的事情：