遵循 BDD 时单元测试与端到端（集成本身）之间的关系

Question

我的问题也与谁在典型的 BDD 中做什么有关。我的理解，产品负责人提出用户故事（可能会或可能不会在 Gherkin 中），QA 编写端到端测试的场景（在功能文件中），Dev 编写他的代码（如何以及在哪里，他是否也遵循 BDD ？）。此时，如果开发人员编写自动化单元测试，QA 是否可以将其用于端到端，或者它们可以完全不同？

我的问题是 Dev 和 QA 在遵循 BDD 的同时如何在编码方面利用彼此的工作。我不知道如何连接这些点。

让我们以基于 JAVA 的应用程序为例，QA 已经使用 Cucumber 和 Selenium Webdriver 进行自动化测试。

Answer 1

如果您正在练习 BDD，那么您将首先创建规范（定义行为），然后才实现此行为（即编写生产代码）。在哪个级别定义行为不太相关，尽管在单元测试级别，大多数人会称之为“TDD”（尽管它不一定是测试驱动，因为“测试”是您要编写的代码的设计）。开发人员和 QA 将合作定义行为并实现测试和生产代码。理想情况下，我希望在不同级别进行不同的测试，最终（最高）级别是 E2E 测试。我也会确保不要重新测试所有内容在每个级别上，但只测试在那个级别上有意义的事情。例如：计算值的方法应该进行单元测试，该值如何在前端显示将在前端进行测试（仍然可以是单元测试），如何从后端获取值将是集成测试等。您可能有兴趣在此处阅读有关 BDD 的更多信息：https : //docs.cucumber.io/bdd/，在此处的任何相关博文中：https ://docs.cucumber.io/community/ blog-posts/或 The Cucumber Book / The Cucumber for Java Book。

Answer 2

我正在一个应用 BDD 的项目中工作。当 BA 创建工单并记下所有方案时，会将其分配给开发人员。同时，QA 还创建一个 QA 票证来与该 DEV 票证相关的工作。但是只有在 DEV 票证的代码正在审查或已经完成时，QA 才会开始编写自动化测试。这是因为该功能需要可用于测试。当 QA 开始编码时，应该完成该票的所有单元测试。因此，为了利用 DEV 和 QA 的工作，我们提出了一个解决方案。虽然它是在试点，但没有正式应用。QA 需要参与单元测试评审。这意味着她/他需要查看所有单元测试并在她/他认为需要添加或删除更多案例时发表评论。并且 QA 可以在单元测试中获得测试覆盖率，并根据该覆盖率决定编写自动化测试。在这里，QA 需要积极参与并决定在 e2e 中测试什么。如果您可以与开发人员面对面讨论以获得单元测试覆盖率会更容易，但我认为审查代码更客观。还有 f2f ，没有任何 DEV 愿意告诉 QA 他的工作。但是，此解决方案需要 QA 工程师的更多技能。不是任何 QA 都能阅读和理解 DEV 代码。这是我们QA团队在当前项目中给出的想法，不知道有没有项目应用这个。这真是个好问题。我还想从其他也希望利用 QA 和 DEV 工作的人那里听到更多的意见/想法。

Answer 3

开发人员和 QA 人员之间的 BDD/TDD 对等编程如何产生 e2e 测试自动化。这可能需要E2e 服务和应用程序部署自动化（一次性 - 非常适合在任何工程师笔记本电脑上工作）用例设置设置行为应用程序状态（更新数据存储/数据库中的数据/数据库模式，如果功能使用密钥开关，则配置文件）决定行为输入和输出的明确定义定义特征触发和验证规则实现应用逻辑使用已实现的逻辑验证验证规则我可能听起来有很多想法要一次做，因此很多人会不鼓励实施 e2e，我想如果使用正确的工具集，这个过程可以非常容易实施。