什么时候不进行单元测试？

#1 楼

我见过的许多测试示例都涉及细节，涵盖了代码的所有方面。


那么？您不必测试所有内容。只是相关的事情。


由于我是唯一的开发人员，而且我非常接近整个项目中的代码，因此遵循写-后-手动测试模式。


实际上是错误的。效率不高。这真的只是一个习惯。

其他单独开发人员所做的工作是编写草图或轮廓，编写测试用例，然后用最终代码填充轮廓。 />

我还发现需求和功能的变化足够频繁，以至于维护测试会在项目上增加相当大的阻力。测试不是阻力。需求变更就是阻力。

您必须修复测试以反映需求。无论是细节还是高级；首先编写或最后编写。

测试通过之前，代码没有完成。那就是软件的普遍真理。

您可以进行有限的“这就是”验收测试。

或者可以进行一些单元测试。

也可以同时使用。

但是无论您做什么，总会有一个测试来证明该软件可以工作。 d建议一点形式性和漂亮的单元测试工具套件使该测试更加有用。

#2 楼

想象一下，您有一整套的测试可以眨眼就能亮起绿灯或红灯。想象一下，这组测试可以测试所有内容！想象一下，运行测试套件所需要做的就是键入^ T。这会给您带来什么力量？

您可以更改代码而不必担心破坏某些东西吗？
您可以添加新功能而不必担心破坏一个旧功能吗？ >您可以快速清理凌乱的代码而不必担心造成损害吗？

是的，您可以做所有这些事情！随着时间的流逝，您的代码会发生什么？它会变得越来越清洁，因为没有清洁的风险。每次您编写一行代码时，妖精都会在测试套件中添加一些内容，以测试该行代码是否达到了预期的目的。因此，每隔两秒钟您可以点击^ T，并看到编写的最后一行代码有效。

您认为应该进行多少调试？

如果听起来像是幻想，那是对的。但是现实并没有太大的不同。只需几秒钟即可替换眨眼，而将TDD学科替换为仙女，您几乎已经做到了。

比方说，您要回到一年前构建的系统，却忘记了如何创建中心对象之一。有一些测试可以以各种方式创建该对象。您可以阅读这些测试并慢跑您的记忆。需要调用API吗？有一些测试以各种方式调用该API。这些测试都是小文件，用您理解的语言编写。它们是完全明确的。他们是如此正式以至于执行。而且他们不能与应用程序不同步！

不值得投资吗？你在开玩笑吧！谁会不想要那套测试？帮自己一个忙，不要再为愚蠢而吵架了。学习做好TDD，并观察执行速度有多快，代码有多干净。

#3 楼

您所犯的错误是，您将测试视为没有立即回报的时间投资。

首先编写测试实际上会将您的注意力集中在代码的这一部分需要做的事情上。

其次运行它们会发现可能会导致错误的错误在测试中出现。

第三次运行它们有时会显示一些本来不会在测试中出现的错误，然后真的会在生产中咬你。

第四次如果您在运行的系统中遇到了一个错误并为其创建了单元测试，则以后将无法重新引入该错误。那可能是一个很大的帮助。重新引入的错误很常见而且很烦人。

第五，如果您需要将代码移交给其他人，则测试套件将使他们的工作变得更加轻松。另外，如果您忽略了一个项目并在几年后重返项目，那么您将再也无法接近它了，它将对您也有帮助。

我的经验一直以来一直以来，在项目的整个开发过程中，进行适当的单元测试始终使过程更快，更可靠。

#4 楼

JUnit（Java单元测试框架）的人有一种哲学，即如果测试太简单，就不要对其进行测试。我强烈建议您阅读他们的“最佳实践常见问题解答”，因为它非常实用。

TDD是编写软件的不同过程。单元测试的基本前提是，您将减少调试器中单步执行代码的时间，并更快地确定您的代码更改是否意外破坏了系统中的其他内容。这与TDD相符。 TDD周期如下所示：


编写测试
观察它是否失败（证明您有事要做）
写出进行测试所需的内容通过-再也没有了。应用TDD是因为它会改变您编写代码的方式。通过强迫自己考虑如何测试/验证代码是否正常，您正在编写可测试的代码。而且由于我们正在谈论单元测试，所以通常意味着您的代码变得更加模块化。对我来说，模块化和可测试的代码是一个大赢家。

现在，您是否需要测试C＃属性之类的东西？想象一下这样定义的属性：

bool IsWorthTesting {get; set;}

答案将是“否”，这不值得测试，因为此时您正在测试语言功能。只需相信C＃平台的家伙做对了。此外，如果失败了，您应该怎么做才能解决它？这意味着不要这样做，但请确保测试棘手的问题所使用/使用的代码： Java有很多这样的东西。即使没有黑客破解已安装的文件也无法失败，您仍需要编写catch块或声明已检查的异常。
用户界面。找到被测控件，并调用正确的事件来模拟用户的操作非常麻烦，在某些情况下是不可能的。但是，如果您使用模型/视图/控制器模式，则可以确保模型和控制器已经过测试，而视图部分则由手动测试完成。
客户端/服务器交互。这不再是单元测试，现在是集成测试。写出通过网络发送和接收消息所需的所有部分，但实际上不要经过网络。一个好的方法是减少实际通过有线与原始通信进行通信的代码的责任。在您的单元测试代码中，模拟通信对象以确保服务按预期运行。

信不信由你，TDD将帮助您进入可持续的发展步伐。这不是因为魔术，而是因为您有一个紧密的反馈循环，并且能够迅速发现真正愚蠢的错误。解决这些错误的成本基本上是恒定的（至少足以用于计划目的），因为小错误永远不会变成大错误。将其与代码狂暴/调试清除冲刺的突发性进行比较。

#5 楼

您必须在测试成本与bug成本之间取得平衡。

为打开文件的函数编写10行单元测试是毫无意义的。 />
对复杂的数据结构执行复杂操作的函数-显然是的。

介于两者之间的是一个棘手的问题。但是请记住，单元测试的真正价值不是测试特定功能，而是测试它们之间的棘手交互。因此，进行一次单元测试可以发现，只需更改一点代码，就可以破坏相距1000行的其他模块中的某些功能，因此值得一试。

#6 楼

测试就是赌博。

创建一个测试是一个赌注，即在一个单元中发生错误而不是通过该测试捕获错误的成本（现在以及以后的所有代码修订中）要比开发测试的成本高。这些测试开发成本包括诸如增加测试工程的工资单，增加的上市时间，因不编写其他代码而损失的机会成本等。

像任何赌注一样，有时您会赢，有时您会赢。失去。

有时错误少得多的较晚软件会赢得快速但有错误的东西，这些东西首先进入市场。有时相反。您必须查看自己特定领域的统计数据，以及管理层想要赌博的程度。 ，从统计上讲，这不值得花时间创建其他特定测试。但是有时，错误的成本如此之高（医疗，核能等），以至于公司必须下输（类似于购买保险）。许多应用程序没有那么高的故障成本，因此不需要更高的不经济保险。其他人也可以。

#7 楼

我的建议是仅测试您想要正常工作的代码。

不要测试您想要进行错误检查的代码，并给您带来麻烦。

#8 楼

我经常想知道我是否应该尝试TDD方法。这听起来像是个好主意，但老实说，我永远无法证明所涉及的额外工作。


TDD和单元测试不是一回事。

您可以编写代码，然后再添加单元测试。那不是TDD，而是很多额外的工作。

TDD是在“红灯”循环中进行编码的实践。绿灯。重构迭代。

这意味着编写尚不存在的代码的测试，观察测试失败，修复代码以使测试工作，然后使代码“正确”。这通常可以节省您的工作

TDD的优点之一是它减少了对琐事的思考。一站式错误之类的东西消失了。您不必遍历API文档，只需查找返回的列表是从0还是1开始即可。

#9 楼

我在一个可以测试几乎所有东西的系统上工作。测试中值得注意的执行是PDF和XLS输出代码。

为什么？我们能够测试收集数据的零件并建立用于创建输出的模型。我们还可以测试确定模型的哪些部分将进入PDF文件的部分。我们无法测试PDF看起来是否正常，因为那完全是主观的。我们无法测试PDF的所有部分是否对典型用户可读，因为这也是主观的。或者，如果条形图和饼图之间的选择对于数据集是正确的。

如果输出将是主观的，则几乎没有单元测试，您可以做值得的工作。

#10 楼

在很多情况下，“编写然后手动测试”只需要花费一些时间即可编写几次测试。节省时间来自能够随时重新运行这些测试。

考虑一下：如果您的测试具有不错的功能覆盖范围（不要与代码覆盖范围混淆），并且假设您具有10个功能-单击一个按钮意味着大约有10个重新测试...当您坐下来喝咖啡时。

您也不必测试Minutae。如果您不想深入了解细节，可以编写涵盖功能的集成测试... IMO，某些单元测试的语言和平台（而不是代码）的测试粒度太细。 >
; TL; DR实在不适合，因为这样做的好处实在太好了。

#11 楼

专业的开发人员编写单元测试是因为从长远来看，它们可以节省时间。您将迟早测试您的代码，如果您不这样做，则用户会这样做，并且如果以后必须修复错误，它们将变得更难修复，并且产生更多的影响。 />如果您编写的代码没有测试且没有错误，那就很好。我不相信您可以用零错误来编写一个非平凡的系统，所以我假设您正在以一种或另一种方式对其进行测试。

在修改或重构较旧的代码时，单元测试对于防止回归也至关重要。他们不会证明您的更改没有破坏旧代码，但可以给您带来很大的信心（只要他们当然可以通过：））对已经交付的代码进行测试，但是下次您需要修改功能时，建议您尝试为该模块或类编写测试，在应用任何更改之前，覆盖率应达到70％以上。看看是否对您有帮助。

如果您尝试一下并且可以诚实地说这没有帮助，那么就不够公平了，但是我认为有足够的行业证据表明，他们至少使您在尝试该方法时值得这样做。 >

#12 楼

我遇到的两个非常好的答案在这里：



什么时候进行单元测试与手动测试
关于单元测试，什么不应该测试？
避免明显开销的理由：


为您的公司立即节省时间/成本
从长远来看，在故障排除/维护/扩展方面可能节省时间/成本即使离开后也是如此。

您是否不想离开自己身边的优质产品作为工作质量的证明？用自私的话来说，这样做对您来说不是更好吗？

#13 楼

似乎大多数答案都是亲TDD的，即使问题不是关于TDD的，而是关于单元测试的一般性的问题。进行单元测试。但是有时候似乎很多程序员都不进行单元测试：


私有方法

根据您的OOP原理，您可能会创建私有方法使复杂的例程与您的公共方法脱钩。公共方法通常旨在在许多不同的地方被调用并经常使用，而私有方法仅由类或模块中的一个或两个公共方法真正地调用，以实现非常特定的功能。通常，为公共方法编写单元测试就足够了，但对于使某些魔术发生的底层私有方法而言，就足够了。如果私有方法出了问题，那么您的公共方法单元测试应该足以检测到这些问题。 br />
许多新的程序员在初次学习测试时就与之相反，认为他们需要对正在执行的每一行进行测试。如果您使用的是外部库，并且其功能已经过作者的充分测试和记录，则在单元测试中测试特定功能通常毫无意义。例如，某人可能编写测试以确保其ActiveRecord模型通过数据库的“ before_save”回调对属性保留正确的值，即使该行为本身已经在Rails中进行了全面测试。回调可能正在调用的方法，但不是回调行为本身。导入库的任何潜在问题最好通过验收测试而不是单元测试来揭示。

无论您是否进行TDD，这两种方法都适用。

#14 楼

肯，
我和许多其他开发人员在我们的职业生涯中多次得出与您相同的结论。 ）是为应用程序编写测试的初期投资似乎令人望而生畏，但如果编写得当并且针对代码的正确部分，它们确实可以节省大量时间。

是可用的测试框架。我从来没有真正感觉到他们就是我想要的东西，所以我只是推出了自己的非常简单的解决方案。这确实使我了解了回归测试的“阴暗面”。我将分享我在这里所做的操作的基本伪代码片段，希望您能找到适合您的解决方案。

弄清楚对于您正在执行的任何项目，您认为哪种粒度级别是最佳的“物有所值”。基本面不会真正改变。

祝你好运！