编写代码后无法进行单元测试吗？

Question

我完成了一个应用程序，之后我正在尝试编写单元测试以涵盖所有方法。

事情就是我看到我正在测试我的代码并了解它的工作原理。

对我来说有点愚蠢，因为我知道代码是如何工作的，而我正在测试我的代码实际上在做什么。

我的问题是：

这没用吗？我正在测试它的作用，而不是它想要做什么。我的代码有效，但我可以改进它。然后：

我是否应该完成所有测试，然后尝试重构我的代码，将我的测试更改为“代码应该如何工作”并对应用程序进行更改以通过测试？

谢谢。

Answer 1

您需要测试“代码应该如何工作”。也就是说，您清楚地了解特定方法的行为，然后创建涵盖该行为的测试集。如果您的代码未通过测试，那么您可以修复它。

即使您的代码现在正在运行，您仍然需要进行回归测试的测试。稍后当您修改代码或向其添加新扩展时，您需要确保不破坏现有功能。您今天获得的测试集将能够告诉您您的表现如何。

Answer 2

虽然我并不总是进行测试驱动开发（在实现类之前编写测试），但我总是在实现代码后编写测试。甚至几天之后。至少我尝试遵循路径覆盖策略（即，从开始到方法的每个路由流程，直到它返回）。也适用于意外的参数值。这对于增强您对函数的正确行为的信心非常有用，当您更改代码时也是如此。

我总能找到意想不到的行为或小错误:)所以它有效

Answer 3

如果您更改代码，这将非常有用。

Answer 4

相当无用，我会说。出于某种原因，它被称为“测试驱动”。每一行代码都是通过测试来激发的。

这意味着代码行也可以防止更改。

测试驱动的开发需要简约的方法和大量的纪律。添加测试以稍微扩展功能。实现功能，使它只是浅绿色，但仅此而已。愚蠢的实施，直到测试迫使你做出严肃的。

我试图在现有代码中添加测试，但发现很难。趋势是只有部分功能被测试。这很危险，因为测试套件会让人们认为代码受到保护。一种方法是逐行检查代码并确保对其进行测试。对代码进行愚蠢的更改，直到测试强制您返回到原始版本。最后，对代码的任何更改都应该破坏测试。

但是，您无法从代码中获取需求。任何反向工程的测试套件都不会完整。

Answer 5

你至少应该尝试来构建关于它应该如何工作的测试。因此，最好提前构建测试，但现在构建测试仍然没用。

原因：您没有构建测试来测试当前代码，但是您正在构建它们以测试将来的修改。单元测试对于测试修改是否不破坏早期代码特别有用。

Answer 6

迟到总比没有好！

当然，最好的选择是在开始实现之前进行单元测试，这样你就可以从中获益更多，但是有一套好的单元测试可以防止你在重构或实现新的时引入很多错误功能，无论您是在实施之前还是之后实施了单元测试。