单元测试的编写和维护成本更低，但它们并不涵盖所有场景。他们之间的平衡是什么？
答案 0 :(得分：4)
区分这两种测试的意图和范围很重要：
unit test通常会测试模块/类级别的特定功能，例如create-X，update-Y，foo-the-bar，compact-the-whizbang等。一个类可能有多个单元测试
a functional test，也称为“验收测试”，通常测试从最外层接口到处理结束的用例场景，例如：从用户界面到数据库再返回，从输入过程到通知实用程序等。
这两种类型的测试不可互换，并且通常不相交。因此，在它们之间实现“平衡”的概念毫无意义。你需要它们，或者你不需要它们。
如果你指的是在测试框架中编写每种类型的测试的简易性，这是一个不同的问题 - 但是使用框架（比如NUnit与用户机器人）不会改变类型/测试的本质。
一般来说，最好的“平衡”是单元测试的置信度和完整性，以及客户接受度的功能测试答案 1 :(得分：3)
我同意Steven Lowe的观点，即单元测试和功能测试之间没有权衡，因为它们用于非常不同的目的。
单元测试涉及方法和类型验证，以及回归测试。功能测试涉及功能，场景和可行性测试。在我看来，几乎没有重叠，
如果有帮助，这是我的测试类别。
开发人员从内部开始，向外工作，专注于代码：
测试人员从外部开始并向内工作，专注于功能：
最终用户从外部工作，通常很少关注：
答案 2 :(得分：2)
我喜欢Brian Marick's quadrant关于自动化测试，其区别在于业务与技术的区别，支持编程与批判产品。
有了这个框架，平衡问题变成了，我现在需要什么？
答案 3 :(得分：0)
在我正在处理的应用程序上，功能测试可能有10：1单位。单元测试工作就像从数据库中检索实体，数据库/网络连接的错误处理测试等。这些事情快速运行 - 几分钟或更短时间，由开发人员每天运行。
功能测试虽然较少往往是厨房接收器方法 - 用户可以完成订单等等，往往覆盖业务领域的事情由业务分析和操作运行 - 遗憾的是我们经常手工操作。这些事情需要数周时间才能完成并通常最终确定发布周期。答案 4 :(得分：0)
我目前的项目是大约60％的单元测试覆盖率，所有用户故事都在硒测试中对用户故事进行了快乐的报道，其中一些还有额外的报道。
我们正在不断讨论这个问题：是否真的有任何因素推动针对更高覆盖率的越来越荒谬的情景进行单元测试？
争论的焦点是，扩大硒测试会增加对具有商业价值的事物的测试覆盖率。客户是否真的关心可能失败的单元测试极端情况？
当您擅长硒测试时，编写具有商业价值的新测试的成本会降低。对我们来说，它们就像单元测试一样简单。
运行时成本是另一个问题。我们有一小组盒子一直在运行这些测试。
所以我们倾向于更多地支持网络测试，可能是因为我们擅长编写它们并且它们提供了不可否认的商业价值。
答案 5 :(得分：0)
由于验收测试的初始成本因素，我最初倾向于偏爱功能/验收测试的单元测试。然而，随着时间的推移，我改变了我的理念，现在我强烈支持尽可能选择验收测试，并且只有在验收测试无法满足我的需求时才使用单元测试。
选择接受单元测试背后的基本理性与SOLID代码的基本理性相同。您的实现应该能够通过重构等进行大幅改变，但所有业务案例 - 验收测试 - 应该能够保持不变并证明可接受的系统行为（测试通过）。通过单元测试，测试与实现代码之间通常存在强烈的耦合。即使它是测试代码，它仍然是代码和强耦合，因为我们应该避免。通过选择验收测试，您通常会在成功的螺旋上领先，以创建精心策划的耗材去耦合API，让您的实施在幕后更改，而不会强制您的测试进行更改。此外，您的开发人员实施思路与业务系统行为思想一致。最后，我发现所有这些对商业和编码人员的满意度都更好。
从理论的角度来看，我经常问自己，如果一段代码无法通过验收测试进行测试，为什么这段代码应该存在？ IE - 如果它不是有效业务场景的一部分，那么该代码是否会增加价值，或者它当前是否仍然是单独成本？
此外，如果您对验收测试进行评论/记录，那些评论/文档通常是系统中最新，最准确的语言 - 通常可以让您避免使用其他不太有价值的文档方法。单元测试不适合这种形式的“业务术语”通信。
最后，我还没有从我的个人发展中形成这个观点，在我的“非常公司”的工作环境中，它已被证明是成功的，有几个不同的项目团队。
答案 6 :(得分：0)
测试应该快速运行并帮助本地化问题。 单元测试允许您仅通过测试相关模块来执行此操作。 但是，可以使功能/集成/验收测试在大多数Web场景中足够快地运行。
答案 7 :(得分：0)
我曾经读到单元测试是一个＆＃34;可执行要求＆＃34;，这对我来说非常有意义。如果您的测试不是专注于证明业务需求，那么它确实毫无用处。如果您有详细的要求（那就是酸测试），那么您将编写一些单元测试来练习每个可能的场景，从而确保数据结构算法和逻辑的完整性。如果您正在测试某些不是必需的东西但是您知道测试通过时必须是正确的，那么很可能您缺少要求。