我应该要求程序员进行单元测试吗？[关闭]

我在一个我们购买大量IT项目的地方工作。我们目前正在为未来项目的需求制定系统要求标准。在此过程中，我们正在讨论是否可以要求供应商进行自动化的单元测试。

我坚信正确的自动化单元测试是记录代码质量和稳定性的唯一方法。其他人似乎都认为，单元测试是仅涉及供应商的可选方法。因此，我们将不需要自动化的单元测试，连续测试，覆盖率报告，单元测试检查或任何种类的测试。我发现这项政策非常令人沮丧。

我在这里完全不合时宜吗？

请为我提供任何观点的论据。

我坚信，正确的自动化单元测试是记录代码质量和稳定性的唯一方法。

事实是，您不能（或者至少很少）通过将其强加给人来获得适当的自动化单元测试。这是获得低劣测试并提高项目成本的好方法。

就个人而言，我会考虑一些涉及质量的需求或SLA。无论如何完成。10年前，单元测试充其量不多见。当我们有更好的方法来确保质量时，您不想在10年内束手无策，但是您的过时政策要求他们使用旧方法。

我个人认为，在您的情况下，您应该考虑验收测试：

• 您有一个黑匣子，您希望它以某种方式运行。
• 您需要付费才付款。
• 编写单元测试以执行您需要查看的行为，如果失败，则必须对其进行修复。

另请注意，这是信任的问题。如果您不信任供应商，则需要获取源代码，对其进行检查并自己进行编译。低于这个数字意味着您至少相信他们一些。

我坚信，正确的自动化单元测试是记录代码质量和稳定性的唯一方法。

这让我感到惊讶，这种想法如此普遍。自动化，是的。单元测试（单独），否。除了单独的单元测试之外，自动化软件测试还有更多的方法。集成，系统，功能，质量保证怎么样？由于某些原因，人们倾向于认为：“好，所以我们有适当的单元测试。完成测试后，将其称为星期五晚上！” 。单元测试仅仅是个开始。

无论如何，回到话题。我同意其他人的看法，即对任何人强加任何东西都可能产生与期望相反的结果。您永远都不知道团队是如何工作的，也许他们拥有价值一百万美元的测试部门，而且从未编写过单个单元测试。

在我的第一份工作中，我曾经在一个有0个单元测试的地方工作（我们是一群大三辈，他们或多或少都认真对待了）。信不信由你，它成功了。当然，没有人知道为什么修复了该错误，或​​者修复了哪些错误，但是仍然有效。有时会弹出一些绝对随机的错误，但是棒球棍和被烧毁的危险一些额外的时间可以创造奇迹。也许您的供应商使用类似的技术？

我非常怀疑您的管理层是否愿意为合同中的适当单元测试付费。适当的单元测试成本与它们测试的代码一样多，但是对最终用户而言却没有多少感知价值，因此它们不会被视为具有同等价值。没有一家质量开发公司愿意花比其他部件更低的成本来进行单元测试的开发工作，因为它们不会因为工作受到损害，他们可以找到更多需要花费相同时间的两份合同而没有单元测试要求。

严格的单元测试可能会使您收到的报价增加到不合理的水平，并且很可能会成为第一个获得较低价格的让步。

没有单元测试的成本取决于您将自己扩展/支持代码的数量。开始检查部分代码以了解质量也很重要。

如果您只是购买项目，以便可以像第三方库一样使用它们，并且不相信自己会对其进行修改，那么只要能真正起作用，较低质量代码的风险就较小。

这些最终都是业务决策，尽管您必须确保做出决策的人也知道技术评估。如果您需要向管理层解释，就像购买二手车一样。最终，由买主决定是否值得，但是将其交给机械师是一个好主意，因此您知道自己没有得到柠檬。

您在付款，可以索要任何东西，包括所有单元测试的副本/报告。

您甚至可以自己编写测试，或者至少编写测试规范。

我同意您的观点，因为它很好地衡量了代码质量。如果供应商拒绝此要求，则会响起警钟，为什么他们不愿意这样做-他们的质量标准很低，走捷径？

您的项目需要自动化的单元测试，连续的测试，覆盖率报告以及单元测试的检查是绝对正确的。

但是，苛刻的事物将无法实现您期望的结果，就像其他人详细介绍的那样。

您面临的挑战是要对人进行解释和说服-这是一项更加艰苦的技能！

我将首先从管理开始，解释测试的优缺点和未来的收益。请注意不要传达诸如“我编写适当的单元测试”之类的陈述（大写您的姓名）背后的情感。您不想“喊”这句话（正如ALL CAPS所暗示的那样），您将说服并说服人们，以便他们自己可以选择正确的解决方案。

最终，如果您不能引入这些方法论并让他们接受您所处的位置，另外，如果您对陈述的方法充满热情（这很好！），我会去另一家公司，因为很多公司都对这些方法很重视并欢迎您的加入。只要确保在面试中领先于他们，他们就会知道您的激情所在以及您是否适合自己。

正如@Joachim Sauer和@Telastyn在其评论中指出的那样，对某人强制进行自动测试将无法获得您想要的结果。对于很多人来说，自动化单元测试是他们思维的巨大转变。因为很多人写的代码行得通，但并不是很容易测试。我可以编写一个ASP.NET网页，其中所有逻辑，查询数据库，业务规则，对象等都在后面的代码中。该页面可以工作吗？是。使用自动化单元测试是否可以测试？绝对不。如果供应商没有自动化的单元测试，则将花费大量的精力来学习如何正确编写单元测试，并且由于学习了此结果，因此需要重新编写或重构其代码以使其更易于测试。他们很可能会将这笔费用转嫁给您。

事实是供应商正在为您提供产品，无论是.dll还是Windows应用程序，您都希望它在99％的时间内都能正常工作。当然，这里到处都有错误，但是在大多数情况下它应该可以工作。这是一个合理的期望，尤其是在供应商希望保留您的业务的情况下。如果它是一个黑匣子，那么它们如何工作并不重要，他们可以使用人工测试仪，也可以使用充满猴子的房间随机敲击键。只要有效。但是他们需要为您提供有关如何使用它的其他文档。

但是，如果他们提供了源代码以便您可以对其进行修改，那么我希望进行单元测试。我不会与不提供单元测试的公司合作。您还怎么知道您所做的修改不会使整个事情变得根深蒂固？

单元测试表明供应商在开发周期中如何应对风险。那些使用单元测试的人会降低风险，这些测试的质量表明了已管理了多少风险。

话虽如此，单元测试并不能定义项目试图解决的风险级别。在降低不良编程习惯所带来的风险方面，它也没有任何作用。

因此，您可以让一个供应商拥有可靠的测试实践，但是继续编写高风险代码，而另一个供应商进行零测试但编写低风险代码。如果两个供应商提供相同的产品，那么最好选择低风险的供应商。

这只能通过采访，指导和了解与该供应商有关人员的性格和技能来衡量。

我发现有关购买自定义软件的这篇文章非常有用：http : //blog.8thlight.com/paul-pagel/2012/06/20/entrepreneurs-guide-to-buying-software.html

他们建议提出的第一个问题是供应商是否编写测试。

与其他人达成共识，即要求进行单元测试会导致出于测试的目的而进行测试；与您想要的东西完全相反的东西。

在审核供应商的过程中；问他们他们的开发过程是什么，因为测试只是该过程的一部分。

他们有自动化的构建过程吗？他们遵循某种管理范式吗？他们是否有经过适当培训的测试人员和独立的质量保证团队？文档标准如何？

这些将帮助您判断其过程的整体质量，进而判断其生产的质量。

在我看来，包含此要求几乎没有实际好处，因为不可能执行。

您可以要求提供用于实际测试的代码，或者报告运行和通过了哪些实际测试的报告。如果这是一个专有项目，则供应商可能不希望提供该项目，因为它很可能暗示代码的细节，并且可能会勉强提供低级别的实现细节并告诉他们如何进行操作。职位。在某个时候，必须有一些信任。

如果您不这样做，他们可能会让您大吃一惊，但只需选中“运行一组单元测试”旁边的框即可满足要求，方法是编写一个可以通过其实用程序编译并运行的测试，或者通过类似测试获得一半努力。

因此，尽管自动化单元测试是一种值得赞扬的做法，但我认为从外部供应商那里坚持这种做法并不可行。

正如许多人指出的那样，强迫供应商编写单元测试（或者更好的是，将自动化的单元测试和集成测试结合起来）来履行合同可能不会产生高质量的结果。另一方面，我同意自动测试是目前用于确保代码质量的最佳方法。

我认为用单元测试编写的代码比首先编写并在以后添加单元测试的代码容易维护。它强制模块化和最小的依赖关系。 集成测试对于验证代码的正确性也是必需的，但是它们对代码质量的影响与编写的代码不同。从本质上讲，可以在事后添加自动集成测试，但是使用原始代码编写时，单元测试的影响最大。

对于您的情况，我的建议是寻找愿意使用单元测试编写代码的供应商，而不是倾向于不使用单元测试编写代码的供应商。如果管理层愿意为此付费，则将自动测试放入合同中，但前提是要使用卖方使用单位测试编写代码。

让我们首先确定优先事项...

作为客户，您主要关心的不是单元测试

如果您使用的是为您提供软件的供应商，那么您不必担心他们使用的是一种方法还是另一种方法。您的赌注是获得有助于您实现目标的某种解决方案。您唯一需要关心的是该解决方案是否可接受。这就是为什么我们要进行验收测试，因为这是您的责任，以确保您得到想要的东西。在客户接受的关键时刻，资金将从您公司的口袋中转移到供应商的口袋中。

您可以要求将单元测试作为可交付的要求，但是它们有一些继承问题，最严重的是，没有预先确定方法可以确定指标：

• 可接受的单元测试数量是多少？

应该有10个测试吗？100次测试怎么样？1000次测试怎么样？实际上，一开始就很难确定需要多少测试。实际的数量确实是不确定的……就像停顿问题一样……但我们没有解决这个问题。

您只需要具有单元测试的软件即可继续开发。单元测试还不能告诉您您已经破坏了什么，但是它们非常适合告诉您代码何时具有回归错误。

• 可接受的代码覆盖范围是多少？

“当然是100％！” 你会想。不幸的是，该指标具有误导性。即使您具有100％的代码覆盖率，您是否真的可以确保一切正常？可能有100％的覆盖率，但没有完成。

您真正需要做的是探索性测试，即找到一个真正擅长打破常规的人，然后让他们进行测试。查找甚至没有开发人员想到的错误。

如果您有一些必要的性能技巧并且使用难以测试的设计模式（在您最喜欢的搜索引擎中搜索“ singleton”和“ tdd”，您会找到一些示例），有时纯粹的单元测试有时也无法达到100％。

您希望交付的软件能够正常工作，并且规格文档是它唯一的保证。

您将需要更高水平的测试

您的规范文档必须以某种方式进行验证。您的供应商必须有明确的目标和接受标准，才能做到每一点。运作良好的质量检查组织（如果预算有限且范围有限，则可以使用强大的测试人员）将提供测试案例，以检查这些接受标准。您还需要有人来验证那些接受标准。

有几种方法可以验证您的目标，如果有人告诉我您无法设定任何理智的质量，性能和效率目标，那么我将分别在探索性，性能和可用性测试方面写大量的笨拙书籍，以达到目标。用目标过度矫kill可能很容易，但是知识和沟通将帮助您设定切合实际的目标。

我不是律师，但是我所阅读的大多数项目合同（基本上是该项目所有规格之母）通常都有一个缺陷率标准，该标准规定了可以接受的错误数量。这些错误通常是通过严重性来确定的，质量检查发现的停止显示错误的容忍度较低，而轻微瑕疵则具有较高的容忍度。在实际项目中，很难要求软件必须具有0个缺陷。截止日期通常会停止这种做法。在这些情况下，您必须开始讨价还价。

我见过的大多数提供的软件通常都不随单元测试一起提供。您可能会争辩说供应商应该足够专业，才能做到这一点，但是，您希望将单元测试交付给您的主要原因是要确保您没有回归错误，还可以进行重构。在现实生活中，随着项目的紧迫性，供应商和客户都将缩小范围，而单元测试通常会超出范围，并从所需的可交付成果列表中删除。

备受好评的开源软件随单元测试一起提供，但是专业的软件开发人员不能，对吗？

那么，作为客户，我什么时候开始关心单元测试？

我要说的是，您真正关心单元测试的唯一时间是，可交付使用的软件是否是不作为独立程序执行的自足组件，对此您可以做的最粗略的测试是单元测试。 。类库将是可以与单元测试一起交付的一种产品。

您怎么知道供应商没有编写单元测试。

也许管理层和供应商开会，供应商说代码花费$ X，单元测试花费$ Y。竹enny捏管理说，我们只想要代码。

供应商决定无论如何都要编写单元测试（由于质量），而只是不与您共享（因为竞争优势）。

现在，您需要对该软件进行一些重大调整。由于您拥有代码，因此您可以自己做，也可以有竞争力地出租它（不一定要卖给原始供应商）。但是，由于您没有购买单元测试，因此原始供应商将能够以比任何竞争对手更低的价格进行质量相当的工作。

尽管没有使用单元测试，但仍有许多项目非常成功。只要看一下linux内核，它是一个巨大的项目，其复杂性远远超出了任何普通项目中所能找到的，并且仍然可以使用。因此，如果结果是好的软件，那么您就不必关心他们是如何实现的。

不，您不一定需要完整的自动化测试单元。更重要的是，它们为您提供了适当的测试策略文档。这样我们做得很好。