我已经开始使用Quick和Nimble编写iOS的第一个BDD测试，并且我有一个关于测试覆盖率的问题。BDD和测试覆盖率
我意识到，在传统的单元测试中，开发人员的目标是拥有100％的测试覆盖率。不过，我还没有读过BDD。如果我正确理解BDD，当我测试我的代码的行为时，那么实现的细节并不重要;重要的是，我从我的代码中获得预期的结果，对吗？
我开始试图获得100％的代码覆盖率，但它似乎开始写脆性测试，因为不是专注于我的代码的结果，而是试图覆盖我的代码可以采用的所有路径。
正如评论之一提到的，BDD的核心方面是给你测试（可能是自动的）是保证你的产品是做正是什么是应该做的。显然：“不低于”。
在这个意义上，BDD 加覆盖率可以帮助你确保你的产品是不是做更比。
换句话说：假设你所有的BDD测试都通过了;并且你的覆盖率是75％...... 可能是意思是：你的代码库的25％是不需要为了提供你的BDD测试用例中指定的行为。意思是：你可以仔细看看这些25％的未触及线条，以了解为什么它们不是必需的;然后确定是否有机会删除未使用的源代码的相同部分。
如：第二好的东西您可以做软件开发人员：从您的代码库中删除代码，而不会降低产品的功能。
（及备案：在最好的事情，一个SW开发者可以做：添加新的功能，以他的产品，吸引新客户 - 删除代码有助于从长远来看你的质量，但客户支付你的薪水短，中期和长期）
这是有道理的。 –
当你讨论75％vs 25％时，我发现更清晰。原因在于我在一些'guard'语句中添加'fatalError（）'以帮助我轻松地找到逻辑中的漏洞。然而，当运行我的测试时，'guard'语句的'else'子句不会被执行，因为事情正如预期那样运行。我正在创建额外的测试，以使'guard'语句落入'else'子句，因此覆盖了'else'子句，不知道是否适合实现100％的覆盖率。 –
BDD和TDD的区别并不在于测试覆盖面，而是关注软件中的行为而不是测试实现细节（测试API而不是实现，有人称之为）， BDD和TDD都将导致100％的代码覆盖率，因为其中一个主要想法是在任何实现代码之前先编写测试。 –
您可以同时拥有100％的测试覆盖率，但BDD将确保您开发出正确的产品。 –
“我意识到，在传统的单元测试中，开发人员的目标是拥有100％的测试覆盖率”。他们当然不会。 100％的测试覆盖率意味着代码的所有分支至少被遍历一次，如覆盖工具所证明的那样。这通常是不必要的，除非你正在编写高度保密的代码（正式的方法可能更合适）。一个单元意味着要测试一个单元的正确功能，以便在错误修复和重构后，可以轻松检查功能是否正确。如果打算覆盖100％，那么也必须重写单元测试。 –