单元测试-合同变更带来的单元测试的好处是什么? [英] Unit tests - The benefit from unit tests with contract changes?

问题描述

最近，我与一位同事就单元测试进行了有趣的讨论.我们正在讨论何时维护单元测试的效率降低，何时合同发生变更.

Recently I had an interesting discussion with a colleague about unit tests. We were discussing when maintaining unit tests became less productive, when your contracts change.

也许任何人都可以启发我如何解决此问题.让我详细说明:

Perhaps anyone can enlight me how to approach this problem. Let me elaborate:

因此，可以说有一个类进行一些漂亮的计算.合同规定应计算一个数字，否则由于某种原因失败将返回-1.

So lets say there is a class which does some nifty calculations. The contract says that it should calculate a number, or it returns -1 when it fails for some reason.

我有合同测试员对此进行测试.在所有其他测试中，我都会对这个漂亮的计算器进行测试.

I have contract tests who test that. And in all my other tests I stub this nifty calculator thingy.

因此，现在我更改合同，无论何时无法计算合同，都将引发CannotCalculateException.

So now I change the contract, whenever it cannot calculate it will throw a CannotCalculateException.

我的合同测试将失败，我将相应地对其进行修复.但是，我所有的模拟/存根对象仍将使用旧的合同规则.这些测试将成功，而不能成功！

My contract tests will fail, and I will fix them accordingly. But, all my mocked/stubbed objects will still use the old contract rules. These tests will succeed, while they should not!

一个提出的问题是，有了对单元测试的信念，可以对这种改变有多大的信心...单元测试成功了，但是在测试应用程序时会出现错误.使用此计算器的测试将需要修复，这会浪费时间，甚至可能会被抽签/嘲笑很多次……

The question that rises, is that with this faith in unit testing, how much faith can be placed in such changes... The unit tests succeed, but bugs will occur when testing the application. The tests using this calculator will need to be fixed, which costs time and may even be stubbed/mocked a lot of times...

您如何看待这种情况?我从没想过.我认为，对单元测试的这些更改是可以接受的.如果我不使用单元测试，我还将看到在测试阶段(由测试人员)出现此类错误.但是我没有足够的信心指出将花费更多(或更少)时间的事情.

How do you think about this case? I never thought about it thourougly. In my opinion, these changes to unit tests would be acceptable. If I do not use unit tests, I would also see such bugs arise within test phase (by testers). Yet I am not confident enough to point out what will cost more time (or less).

有什么想法吗?

推荐答案

您提出的第一个问题是所谓的脆弱测试"问题.您对应用程序进行了更改，并且由于该更改而导致数百个测试失败.发生这种情况时，您会遇到一个 design 问题.您的测试被设计为易碎的.它们还没有与生产代码充分分离.解决方案是(就像在所有此类软件问题中一样)找到一种抽象方法，该抽象方法将测试与生产代码分离开来，从而使测试中隐藏了生产代码的易变性.

The first issue you raise is the so-called "fragile test" problem. You make a change to your application, and hundreds of tests break because of that change. When this happens, you have a design problem. Your tests have been designed to be fragile. They have not been sufficiently decoupled from the production code. The solution is (as it it in all software problems like this) to find an abstraction that decouples the tests from the production code in such a way that the volatility of the production code is hidden from the tests.

导致这种脆弱性的一些简单原因是:

Some simple things that cause this kind of fragility are:

• 测试显示的字符串.这样的字符串是易变的，因为它们的语法或拼写可能会随着分析师的想法而改变.
• 测试应该在抽象之后(例如FULL_TIME)编码的离散值(例如3).
• 从许多测试中调用相同的API.您应该将API调用包装在一个测试函数中，这样，当API更改时，您可以在一处进行更改.

测试设计是TDD初学者经常忽略的重要问题.这通常导致脆弱的测试，然后导致新手拒绝将TDD视为非生产性".

Test design is an important issue that is often neglected by TDD beginners. This often results in fragile tests, which then leads the novices to reject TDD as "unproductive".

您提出的第二个问题是误报.您使用了如此多的模拟，因此您的测试都没有实际测试集成系统.尽管测试独立的单元是一件好事，但测试系统的部分和整个集成也很重要. TDD不仅仅是单元测试.

The second issue you raised was false positives. You have used so many mocks that none of your tests actually test the integrated system. While testing independent units is a good thing, it is also important to test partial and whole integrations of the system. TDD is not just about unit tests.

测试的安排应如下:

• 单元测试提供近100％的代码覆盖率.他们测试独立的单元.它们是由程序员使用系统的编程语言编写的.
• 组件测试覆盖了系统的约50％.它们是由业务分析师和质量检查人员撰写的.它们以FitNesse，Selenium，Cucumber等语言编写.它们测试整个组件，而不是单个单元.他们主要测试快乐路径案例和一些高度可见的不快乐路径案例.
• 集成测试覆盖约20％的系统.他们测试的是组件的小型组件，而不是整个系统.也用FitNesse/Selenium/Cucumber等编写.由建筑师撰写.
• 系统测试覆盖了系统的约10％.他们将整个系统集成在一起进行测试.同样，它们是用FitNesse/Selenium/Cucumber等编写的.由建筑师撰写.
• 探索性的手动测试. (请参阅James Bach)这些测试是手动的，但没有编写脚本.他们运用人类的创造力和创造力.

这篇关于单元测试-合同变更带来的单元测试的好处是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！