我应该对小型项目进行单元测试吗？

#1 楼

简短答案：

是的，您应该对小型项目进行单元测试。功能上。你为什么要这么做？因为测试很有用！单元测试是相同的。如果您回过头来重构代码，则可以添加或编辑功能以进行单元测试，这将为您提供即时反馈，表明您所做的更改不会破坏任何内容。

我真的建议您尝试一下“测试驱动”发展。您考虑一下需要什么，对失败的测试进行纠正，然后添加代码以使其通过。泡沫，冲洗，重复。这是通过这种方式编写代码或在主题上运行google搜索的好处的一个好列表，那里有很多资源。 TDD易于理解，很难掌握。

http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first

#2 楼

测试是达到目的的一种手段，而不是目的本身。如果您对使用当前开发和测试实践的工作质量感到满意，则无需进行其他工作。如果您对工作质量不满意，编写单元测试是一种可能的改进途径。

我不能保证编写单元测试会为您带来更好的结果。在某些情况下，这可能会浪费时间，例如当开发人员不想编写单元测试时，或者当单元测试专注于不重要或不太可能存在错误的事物时。在适当的情况下，它们可以发挥很大的作用。当我是开发人员时，我编写了单元测试，对我来说这是一种富有成效的实践。

#3 楼

绝对应该编写单元测试。无法保证以后不会添加您的小型项目-或操作系统的下一版本不会否决您的项目正在进行的调用。否则，任何其他无数奇怪的事情都不会发生。某人的原型成为新应用程序的核心并变身为维护噩梦的情况并不少见，因为最初认为这是一次性代码并不正确。通过这些可能性中的任何一种，避免它们。就此而言，单元测试是软件界的安全套：它们可以防止各种不可预见的事件以及您希望它们防止的事物。

#4 楼

TL; DR答案


是的，即使在小型项目中，单元测试也值得。

完整答案许多年来，我一直误以为我没有足够的时间为我的代码编写单元测试。当我确实编写测试时，它们是肿的，沉重的东西，这仅促使我认为我应该只在知道需要它们时才编写单元测试。

然后我开始使用测试驱动开发和发现这是一个完整的启示。现在，我坚信我没有时间不编写单元测试。

根据我的经验，通过考虑测试进行开发，最终会得到更简洁的界面，更集中的类和模块和通常更多的可测试的SOLID代码。

每当我使用没有单元测试并且必须手动测试某些东西的旧代码时，我一直在想：“如果这样做，这样做会更快。代码已经进行了单元测试”。每次我不得不尝试在具有较高耦合度的代码中添加单元测试功能时，我总是在想：“如果以非耦合方式编写，这将变得更加容易”。
对比了我支持的两个实验站。一个已经存在了一段时间，并且拥有大量的遗留代码，而另一个则相对较新。

在向旧实验室添加功能时，通常是进入实验室的一种情况。并花费许多时间来研究其所需功能的含义以及如何添加该功能而不影响任何其他功能。根本没有将代码设置为允许离线测试，因此几乎所有内容都必须在线开发。如果我确实尝试离线开发，那么最终我会得到比合理数量更多的模拟对象。

在较新的实验室中，我通常可以通过以下方式添加功能：在我的办公桌上离线开发该功能，仅模拟那些立即需要的东西，然后仅在实验室中花费很短的时间，解决所有未解决的问题行。

#5 楼

项目大小不应成为跳过单元测试的考虑因素。

如果我有充分的理由不进行单元测试，这里的大多数人都会讨厌我。这是我考虑的仅有的三个：有测试软件的经验。不要立即开始。从长远来看，您的软件可以极大地提高生产力，但是一开始您的工作速度就会变慢。当您的最后期限/工作没有紧要关头时，请学习TDD错误不会破坏您的生命，那么不要编写单元测试


维护

如果您的工具只做一件事情而您非常确定您将不必再触摸它（几乎没有这种情况），那么也可以不进行单元测试。