使用Lettuce的BDD测试可以替代项目中的所有其他测试方式吗？
我喜欢Lettuce这个工具，它让测试变得很有趣。请问我可以用Lettuce的功能来替代项目中的所有测试（比如文档测试和单元测试）吗？
3 个回答
用Gherkin/Lettuce来做所有事情并不是个好主意。
1) 你绝对不应该完全放弃手动测试。虽然你可以用它来替代那些重复的脚本测试，但你还是需要让一个可能会误解或错误使用软件的人来测试一下。创造性、破坏性的人为测试是很重要的——不过大部分的测试（90%以上）应该是自动化的。
2) 另一个原因已经提到过了：它的运行速度比单元测试慢。我发现测试运行得越久，人们就越不愿意频繁地去跑它。你希望在每次修改后都能毫不犹豫地运行测试，可能每5分钟就跑2到3次（没错，就是这么快！）。
3) 就我个人而言，我觉得在不同的窗口里用sniffer或autonose来写单元测试，给我提供了最好的代码测试环境。我不知道用lettuce怎么做到这一点。
4) 如果不需要，为什么要换语言呢？单元测试是用Python写的，而且没有任何固定的东西或复杂的东西来让你接触到你想测试的代码。它和模拟对象（mocks）以及假对象（fakes）配合得很好。Gherkin虽然有趣，但涉及的东西更多。如果有非程序员在写测试，那额外的东西是不错的，但如果没有，那就只是多余的负担。
简单来说，答案是否定的。
我没有用过Lettuce，但你的问题同样适用于其他BDD框架，比如Cucumber。
这种做法被认为是不太好的，因为集成测试的运行速度比单元测试慢，而且维护起来也更麻烦。
另外，Gherkin语法的一个大优点是，它对非技术人员也很友好，可以专注于业务规则，而单元测试通常关注的是类或函数的具体实现，这些内容对关注业务的人员来说并不太重要。
有时候，单元测试和集成/验收测试之间会有一些重叠，但一般来说，你应该努力找到一个合适的平衡点。
我不同意Andy的看法。
我同意在合适的时候进行适当的测试，而且单元测试（也就是只测试自己内部的部分，不和外部交互的测试）并不能替代所有其他类型的测试。
但这并不意味着，只要分得当，就不能用BDD框架（我也没用过Lettuce）来运行你的测试。
我也很喜欢Gherkin语法，因为它可以让业务专家、测试人员和赞助商参与进来，帮助记录需要遵循的流程。所以我觉得可以有一套规格针对单元测试，另一套规格则针对系统测试和回归测试。
想象一下这个（虽然有点牵强，明显不够详细）例子：
- 假设我的测试服务器已经更新到昨晚的版本
- 当我运行我的回归测试包1
- 那么我的回归测试结果应该和回归测试包1的已知结果一致
我并不是说这种方法在所有情况下都合适。你应该评估一下这种方法相比于把所有测试放在不同的测试运行系统中能带来什么好处。特别要考虑进行测试的人的经验水平。
所以如果你在做一个小的技术项目，只有你一个开发者，并且你喜欢这种语法，那就没有理由不这样做。只要确保你能把单元测试、系统测试和回归测试分开就行。
但如果你是一个大团队的一部分，包括开发者、测试人员和业务分析师，那么你的理由就需要更有说服力，而且不太可能真的有效。