陷入单元测试困境
关于单元测试的一些菜鸟问题。
假设我有一个类，我为其中的每个方法编写了一堆单元测试。
当我决定更改设计以使此类不再存在，但其功能应与其他类混合时会发生什么？那么所有的单元测试都变得过时了，对吗？我们对此无能为力。
然后，如果我们经常改变设计，就像实践中发生的那样，我们基本上应该一遍又一遍地编写相同的测试。我们如何避免这种情况？
人们可以通过仅对永远不会改变的坚如磐石的类进行单元测试来避免这种情况，而其余的则依赖于黑盒集成测试，但这是正确的方法吗？
A few noob questions about unit testing.
Let's say I have a class, for every method of which I write a bunch of unit tests.
What happens when I decide to change the design so that this class shouldn't exist anymore, but its functionality should be mixed among other classes? Then all the unit tests become obsolete, right? There is nothing we can do about it.
Then, if we change the design quite often, as it occurs in practice, we should basically write the same tests over and over again. How do we avoid that?
One could avoid this by unit testing only the stone-hard classes, which never change, and for all the rest rely on blackboxed integration testing, but is this the right approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，基于可靠需求的良好设计不需要对类进行重大更改。
如果您需要频繁更改并且仍然想采用单元测试，那么您别无选择，只能在每次更改时采用更困难的单元测试方法。也不例外。
First of all a good design based on solid requirements shouldn't require major changes to the
Class.In the event you need to frequently change and you still want to adopt
Unit Testing, you have no other option but to take the harder way of unit testing every time you make a change. No exception to that.您可以创建一个外观，其接口不会更改，而实现可以更改以遵循您的类的规范。
但在这种情况下，为什么类本身不采用门面的接口呢？
You might create a facade which interface does not change whilst the implementation can change to follow your class's specs.
But in this case, why not adopt the facade's interface for the class itself?