如果一个测试内部实现，或者只测试公众的行为？ [英] Should one test internal implementation, or only test public behaviour?
问题描述
由于软件里...
- 该系统由几个子系统组成
- 每个子系统由几个组件
- 每个组件使用多个类实现
...我喜欢写每个子系统或组件的自动化测试。
... I like to write automated tests of each subsystem or component.
我不写为每个内部类组件的测试（除了因为每个类有助于组件的公共功能，因此可测试/通过组件的公共API从外部测试）。
I don't write a test for each internal class of a component (except inasmuch as each class contributes to the component's public functionality and is therefore testable/tested from outside via the component's public API).
当我重构一个组件（我经常这样做，为增加新的功能的一部分）的实施，因此，我并不需要改变任何现有的自动化测试：由于测试只取决于组件的公共API，以及公共API通常被扩展，而不是改变。
When I refactor the implementation of a component (which I often do, as part of adding new functionality), I therefore don't need to alter any existing automated tests: because the tests only depend on the component's public API, and the public APIs are typically being expanded rather than altered.
我觉得像重构测试code 文件这一政策对比，它说的东西一样...
I think this policy contrasts with a document like Refactoring Test Code, which says things like ...
- ...单元测试......
- ......一个测试类为系统中的每一个类......
- ......测试code /生产code比...非常视为接近的比例为1：1。
......所有这一切，我想我不同意（或至少不练）。
... all of which I suppose I disagree with (or at least don't practice).
我的问题是，如果你跟我不同意的政策，你解释一下为什么？在什么情况下是这种程度的测试不够？
在总结：
- 公共接口进行测试（并重新测试），而很少变化（它们添加到但很少改变）
- 内部API隐藏在公共API的背后，可以在不重写测试用例该测试公共API进行更改
脚注：我的一些测试案例作为数据的实际执行。例如，测试用例的UI由包含各种用户输入和相应的预期系统输出的数据文件。测试系统是指具有测试code它读取每个数据文件，重播将输入到系统中，并声称它获得了相应的预期输出。
Footnote: some of my 'test cases' are actually implemented as data. For example, test cases for the UI consist of data files which contain various user inputs and the corresponding expected system outputs. Testing the system means having test code which reads each data file, replays the input into the system, and asserts that it gets the corresponding expected output.
虽然我很少需要改变测试code（因为公共API通常添加到，而不是改变），我发现我有时（例如每周两次）需要改变一些现有的数据文件。当我改变系统输出为好（即新的功能改进了现有输出），这可能会导致现有的测试失败（因为测试code只尝试断言输出未改变）这可偏偏。为了处理这些情况下，我做以下内容：
Although I rarely need to change test code (because public APIs are usually added to rather than changed), I do find that I sometimes (e.g. twice a week) need to change some existing data files. This can happens when I change the system output for the better (i.e. new functionality improves existing output), which might cause an existing test to 'fail' (because the test code only tries to assert that output hasn't changed). To handle these cases I do the following:
- 重新运行自动化测试套件，一个特殊的运行时间标志，告诉它不能断言输出，而是捕捉到新的输出到一个新的目录
- 使用一个可视化差异工具，看看哪些输出数据文件（即什么测试用例）已经改变，以验证这些变化是好的，赋予新的功能如预期
- 通过复制新的目录新的输出文件从这些测试用例运行目录（盖写旧的测试） 更新现有的测试
- Rerun the automated test suite which a special run-time flag, which tells it to not assert the output, but instead to capture the new output into a new directory
- Use a visual diff tool to see which output data files (i.e. what test cases) have changed, and to verify that these changes are good and as expected given the new functionality
- Update the existing tests by copying new output files from the new directory into the directory from which test cases are run (over-writing the old tests)
脚注：由成分，我的意思是这样一DLL或一大......东西是足够大，是对架构或系统的部署图可见，使用了许多经常执行或100类，并用一个公共API只包含约1或接口少数...一些可被分配给的开发者之一的团队（其中不同的组件被分配到一个不同的小组），并因此将根据康威定律的具有相对稳定的公共API。
Footnote: by "component", I mean something like "one DLL" or "one assembly" ... something that's big enough to be visible on an architecture or a deployment diagram of the system, often implemented using dozens or 100 classes, and with a public API that consists of only about 1 or a handful of interfaces ... something that may be assigned to one team of developers (where a different component is assigned to a different team), and which will therefore according to Conway's Law having a relatively stable public API.
脚注：文章的 面向对象的测试：神话与现实 的说，
Footnote: The article Object-Oriented Testing: Myth and Reality says,
神话：黑盒测试是足够
如果你做的测试案例进行了认真的工作
设计使用类或接口
规范的，你可以放心，
类已经被充分行使。
白盒测试（在看
方法的实现设计
测试）违反了这一概念
封装。
Myth: Black box testing is sufficient. If you do a careful job of test case design using the class interface or specification, you can be assured that the class has been fully exercised. White-box testing (looking at a method's implementation to design tests) violates the very concept of encapsulation.
现实：OO结构的问题，部分
II。许多研究已经表明，
黑箱测试套件认为是
开发商彻底奇慢
仅仅从三分之一锻炼半
声明（更不用说路径或
状态）下的执行
测试。我们有理由三
这个。首先，输入或状态
通常选择正常行使
路径，但不要强迫所有可能的
路径/状态。二，暗箱
单独测试不能透露的惊喜。
假设我们测试过的所有
该系统的指定的行为
测试下。有信心也有
我们需要无未指定的行为
知道，如果系统的任何部分有
尚未行使的暗箱
测试套件。唯一的办法这
可以得到的信息是code
仪器仪表。第三，它往往是
难以行使例外，
错误处理不检查
源$ C $ C。
Reality: OO structure matters, part II. Many studies have shown that black-box test suites thought to be excruciatingly thorough by developers only exercise from one-third to a half of the statements (let alone paths or states) in the implementation under test. There are three reasons for this. First, the inputs or states selected typically exercise normal paths, but don't force all possible paths/states. Second, black-box testing alone cannot reveal surprises. Suppose we've tested all of the specified behaviors of the system under test. To be confident there are no unspecified behaviors we need to know if any parts of the system have not been exercised by the black-box test suite. The only way this information can be obtained is by code instrumentation. Third, it is often difficult to exercise exception and error-handling without examination of the source code.
我要补充一点，我做白盒功能测试：我看到了code（在执行），我写功能测试（这推动公共API）行使各项code分公司（详细信息的功能的实现）。
I should add that I'm doing whitebox functional testing: I see the code (in the implementation) and I write functional tests (which drive the public API) to exercise the various code branches (details of the feature's implementation).
推荐答案
我的做法是通过公共API / UI测试的内部。如果某些内部code不能从外部达成，那么我重构删除它。
My practice is to test the internals through the public API/UI. If some internal code cannot be reached from the outside, then I refactor for removing it.
这篇关于如果一个测试内部实现，或者只测试公众的行为？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
