作为专业开发人员，不编写单元测试是否可以接受？[关闭]

只是想知道TDD /自动单元测试的优缺点，并寻找社区对于专业开发人员在不支持单元测试的情况下编写应用程序是否可接受的观点？

要测试什么？

如果您正在谈论100％的代码覆盖率，那么它是极为罕见，无用且通常是不可能的。同样，测试与CRUD相关的代码是浪费时间，并且花大量时间编写不需要的代码而不是做一些实际有用的事情是非常不专业的。

现在，作为开发人员，您必须知道如何编写单元测试以及在哪里需要它们。

理论

有一个常见的误解，认为单元测试用于测试“单元”。
单元测试和所有其他测试一样，都测试功能。根本没有其他可以测试的了。

但是，复杂系统的功能通常无法有效测试。
假设用户按下“删除”按钮，则什么也没有发生。为什么？数据库中可能存在错误，连接可能已断开，核心逻辑可能发生故障，甚至操作可能成功，但接口未正确更新。每一层可能包含许多彼此调用的函数，而且错误的位置并不总是很清楚。
单元测试基于分离组件的范例，并分别进行测试。

再一次，它不能保证整个系统都能正常工作，但是可以简化测试。

TDD本身不是必需的。它通过迫使开发人员首先回答“我实际上要编写什么代码？”，从而简化了编码。

费用

许多人认为，通过不编写测试，可以节省时间。错误。从战略上考虑，从出现到检测到，错误的代价会随着时间呈指数增长。

假设您在代码中出错，并在同一天检测并修复它。成本是$ X。
让我们假设错误仍然未被发现，并进入每周内部构建。幸运的是，QA已检测到它，并在bug跟踪器中引发了一个bug，这个问题是在5人的一次会议上进行了5分钟的讨论，等等。成本是每个人花费的人力之和，在这种情况下可能是3 * X。
如果错误转至Beta测试并吸引更多人怎么办？比方说，$ 10 * X。
如果很长一段时间都未被发现，则去了1000个客户（希望不是一百万！），其中有10个发现了它，他们与您的支持人员进行了讨论，有的人称呼您的老板，您的队友试图复制它，等等，等等。最后，错误再次出现，您可以修复它。总共多少钱？那么超过$ 50 * X。

如您所见，一个错误迟早会再次出现在您（或您的同事）身上。唯一的区别是发生的时间和费用。
单元测试缩短了错误的生命周期，因此降低了成本。

专业的

• 单元测试使开发人员可以更好地编写代码。就如此容易。
• 他们让您节省时间。
• 它们降低了成本；
• 单元测试与它们测试的代码一起生活。根据任何更改请求（始终发生），测试将适应。

骗子

我可以看到一个不写测试的借口。如果您正在编写原型，例如某些东西永远不会交给别人。或者，也许您正在写一些一次性的东西。

当然，不编写用于很少的内部辅助工具或测试工具的单元测试还是可以接受的，这种情况下企业确实确实需要质量以外的其他东西，而作为专业开发人员，您会发现可以完成软件并以同样快的速度工作没有。

以我的经验，单元测试可以捕获的错误中有95％来自对数据层的调用，尤其是在数据库设计更改之后。如果您使用的是数据库，则只需对用于访问数据库的每种方法进行测试。测试甚至不需要精心设计，只需进行健全性检查即可。

在回答您的问题时-如果您访问数据库并且您是专业开发人员，则应该使用单元测试。否则，这取决于。

这实际上取决于应用程序的使用方式。这是关键任务应用程序吗？还是仅由开发人员在内部使用的简单验证应用程序？在为公司的核心应用程序工作时，应进行必要的单元测试，以确保涵盖业务决策。取决于您的公司，这些是客户看到的应用程序，而错误可能会造成金钱损失。如果做得好，单元测试可以极大地确保您的应用程序在部署后能够正常工作。但这并不是全部治愈方法，仍然应该进行人工测试。简单的内部（或辅助）应用程序不需要单元测试，但仍然应该写得很好。

TDD不仅要先编写测试。这是关于确保您的代码易于测试。而且经常比不容易测试的代码更容易读取/调试/维护。可测试的代码通常还遵循模式和OO原则，例如SOLID。我认为作为专业开发人员，您的代码应始终采用这种方式编写。

您绝对不希望“不进行测试”。如果编写单元测试，则至少要确保代码与测试匹配（尽管您需要确保测试与规范匹配）。

但是，如果您仅拥有单元测试，那么您还没有完成。您可能仍然需要进行集成测试和端到端测试（并且随着时间的推移，会积累测试用例以捕获错误回归）。

我将在这里走出去，说这主要是主观的，取决于您的目标。tl; dnr：这样做很好，但是，教条主义只会导致更多问题。

TDD /单元测试将提高代码的稳定性。它们使在不十分了解代码库的情况下更容易进行更改，它们使您可以更快地进行重构，并且可以确保您所做的事情不会傻。单元测试也可能浪费时间。可以花时间编写代码。如果您盲目地遵循它们，它也可以让您自以为是，认为自己的代码行不通。

如果您在一家支持最佳实践的公司工作，并给您时间来实施它们，并且您想要一个持久的应用程序，那么对于所有人来说，使用和实践单元测试和代码审查确实是最好的。如果开发人员不滥用质量保证小组，则可以接受。如果您正在编写原型（甚至是生产原型），则只需进行烟雾测试即可​​更快。

如果您正在从事的工作不会陷入困境，那么覆盖范围可能会较小。金融交易？很多。如果您有一个由强大的开发人员组成的团队，他们了解代码库，可以很好地协同工作，而且没有人员流动，那么您可能需要的覆盖面会更少。等等。

因此，这可能是

• 团队规模/营业额
• 应用所需的保质期
• 应用程序以及严重故障的严重程度
• 提供时间来实施与开发进度表有关的最佳实践
• 团队的才能（这并不意味着成为一名优秀的程序员意味着您不应该编写单元测试，但是没有初级开发人员的团队也许可以坐下来，获得更大的成功）

在很多情况下，不编写单元测试是可以接受的。TDD现在处于“介入”状态，但这不是灵丹妙药。

编写可维护的单元测试可以节省您的时间和泪水，这是专业的！

有一个misconception that Unit test finds bugs。好吧，这并非在所有情况下都是正确的。单元测试与查找错误或检测回归无关。根据定义，examine each unit of your code separately。但是，当您的应用程序真正运行时，所有这些单元都必须协同工作，并且整个过程比独立测试的部分之和更加复杂和微妙。

因此，单元测试（在TDD过程中）的目标是关于稳健地设计软件组件。

编辑：有一个例外，其中单元测试确实检测到错误。这是在重构或重组单元的代码但无意更改其行为的时候。在这种情况下，单元测试通常可以告诉您单元的行为是否已更改。

作为专业开发人员，不编写单元测试是否可以接受？

没有。

毫无疑问-这应该是新生学习的第一门课程。您必须开发单元测试以证明您的代码可以工作，然后再告诉质量检查人员您的代码已准备好进行测试。否则，将增加项目成本并降低团队士气。

这些单元测试应该有多彻底？

这是石蕊测试：如果QA在您的代码中发现错误，您是否愿意使用单元测试向老板证明您的尽职调查？

如果您的回答是“否”，那么您应该进行更好的单元测试。
如果您的回答是“是”，则您的代码已准备好进行验证。

作为专业开发人员，不编写自动化的单元测试是否可以接受？

是。

特别是，如果花费大量时间和精力编写自动化的单元测试，将超过通过测试获得的收益。这包括但不限于可能难以模拟的UI代码。

重点：我并不是说不可能为UI代码编写自动化的单元测试。我只是说，根据我的经验，有时很难为某些 UI代码编写自动化的单元测试。