我是否应该为A类编写测试，如果它属于B类 [英] Should I write tests for class A if it's covered from class B

问题描述

我想对测试方法有一些看法。

I'd like to get some opinion about testing methodology.

让我们假设我们有A类和B类.B类使用A类的功能.B类经过全面测试，因此一些测试覆盖也间接应用于A类。

Lets assume we have class A and B. Class B uses functionality of class A. The B class is fully tested and thus some test coverage is also applied indirectly for class A.

我应该直接为A类编写完整的测试吗？或者我应该只测试没有测试过的A类功能吗？

Should I write full tests directly for class A? Or should I test only not tested A class functionality?

我在问，因为将来可能会删除或修改B类的方式它可能不会使用A类中的相同功能，因此可能会留下一些未经测试的方法。你会做什么？

I am asking because maybe in the future there will be possibility that the B class will be removed or modified in the way that it might not use the same functionality from A class so it might leave some methods untested. What would you do?

推荐答案

CLASSES！= UNITS

如果你练习一个好的TDD，你会很容易理解背后的东西。

---

IMO，你应该测试 B 的行为不基于 A 已经过测试的事实。

CLASSES != UNITS

If you practice a good TDD, you will understand easily what is behind.

---

IMO, you should test B's behavior without based on the fact that A would already be tested.

实际上，有三种情况：

A 和 B 属于同一层：

• 如果 A 是通过 B 的重构循环（提取类）创建的（通常在练习好的TDD时发生），然后 A 应该完全没有经过测试！根本不需要测试它！
  
  实际上，代码结构（在这种情况下，类/ SRP的分离）应该独立于 Unit 概念; B 和 A 在这种情况下属于同一单位。

• If A is created through refactor cycle (extract class) of B (happens often while practicing a good TDD), then A should TOTALLY be left untested! No need to test it at all!
  Indeed, structure of code (in this case, separation of classes/SRP) should be independent of Unit concept; B and A in this case belonging to the same unit.

如果 A 已存在之前 B ， B 不应该基于这个事实， B 的整个行为应该是测试。

If A existed BEFORE B, B should not be based on this fact, and B's whole behavior should be tested.

A 和 B 不属于同一层（不同边界：

A and B NOT BELONGING TO THE SAME LAYER (distinct boundaries for instance):

• 如果 B 是一个GUI类， A 一个业务类，然后在测试<$ c时应该加倍/模拟 A $ c> B ，还有 A 应该有专门的测试。
  
  的确，域架构不应该混合行为/功能概念。

• If B is a GUI class, and A a business class, then A should be doubled/mocked when testing B, and also A should have a full test dedicated for it.
  Indeed, domain architecture should not be mingled with behavior/feature notion.

要理解原因，请阅读此内容最近Bob叔叔处理这个概念的文章：

To understand why, read this recent article of Uncle Bob dealing with this concept:

http://blog.8thlight.com/uncle-bob/2014/01/27/TheChickenOrTheRoad.html?utm_source=hootsuite&utm_campaign=hootsuite

摘录：

测试的设计必须是一种常见的误解镜像
生产代码的设计。正如作者
建议的那样，TDD并不要求系统中的每个单元都与b $ b b设计精良的单元测试配对。事实上，这是
我们很多人已停止称其为单位测试的原因之一。

It is a common misconception that the design of the tests must mirror the design of the production code. TDD does not require, as the Author suggests, "that every unit in your system is paired with a well-designed [...] unit test." Indeed, that's one of the reasons that many of us have stopped calling them "unit" tests.

注意：TDD不关心未来，相反，它可以帮助您编写尽可能多的代码，而不是更多。所以你不应该担心这个：

Note: TDD doesn't care about "future", in the contrary, it helps you to write as much code as you need, no more. Therefore you should not worry about this:

将来B类可能会被
删除或修改

in the future there will be possibility that the B class will be removed or modified

如果你写了好的测试（我更喜欢单词specs），那么会立即检测到这种删除。

If you wrote good tests (I prefer the word "specs"), such removal would be detected immediately.

这篇关于我是否应该为A类编写测试，如果它属于B类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！