我在一个团队中工作,开发一个web应用程序前端(使用角)和后端(使用Java)。
经理和团队要求我负责TDD (因为我是一名测试自动化工程师),所以他们告诉我在开发人员开始编写新特性和重新运行这些测试之前,编写TDD场景并将它们与代码联系起来。
测试人员做TDD是正常的吗?
发布于 2021-11-20 03:50:32
定义“正常”
更严重的是,在编写代码之前编写(失败)测试是TDD和BDD的本质。它意味着设计测试,然后是可测试代码。首先编写(失败)测试的结果是,它实际上改变了编写应用程序代码的方式,即可测试性。这将导致完全不同的代码。小方法只是这种方法结果的一个例子。尽管TDD意味着首先进行测试,但它通常意味着编写测试和代码,并在发现负面和边缘情况时在两者之间进行大量讨论。有两个不同的人(不是现场配对)在这将是非常缓慢的。
当另一个人(如自动化工程师)编写测试时,这通常是在给定的BDD形式下进行的。
在编写单元测试时,当您是不同角色的不同人员时,事先编写正确的测试是不实际的,因为在编写应用程序代码时,您会发现方法和负/边缘测试用例,并在编写解决方案时执行重构。以这种方式将测试和应用程序代码分离,将减缓过程,并导致质量较低的解决方案。
回到“正常”这个词。
这可能是不常见的,但使用正确的方法,如高级别的BDD,这是正确的方式。如果对你有用的话。但是,您将需要与开发人员进行大量的交互。你不一定要实施黄瓜。您可以指定给定、何时,然后在票据中供开发人员使用。我已经有效地做到了这一点,并发现它为他们提供了他们需要的规范。
外卖:
问:
发布于 2021-11-20 03:50:23
那就没说重点了。
TDD是关于快速反馈的,所以开发人员编写一个检查,运行它,它失败,编写进行检查所需的最低限度的代码,再次运行检查,这一次它通过,继续写另一个检查,.
我想,除非你在一台电脑上工作并共享键盘,否则两个人不可能同步。
当然,你可以在一段时间内把它当作一个实验,然后评估它是如何为你工作的。我猜这不会有多大效果,您甚至可能在开发人员完成他的代码之后完成测试代码。很明显这根本不是TDD。
发布于 2021-11-20 04:02:16
就像其他人说的那样,这将是没有意义的。
正如肯特贝克在TDD按例中所说,TDD是关于代码设计的。通过逐步定义应用程序的使用情况,测试将驱动应用程序的体系结构.
最后,建议的情况将把您转变为一个低级别的软件架构师--可能效率不高,因为您将成为团队中每一个编码工作的瓶颈。
您可能需要考虑的两个备选方案是:
https://sqa.stackexchange.com/questions/49379
复制相似问题