在做BDD时,首先必须TDD每条代码进行验收测试吗？

Question

周末我被给了卡塔工作.在开始之前我真的只想收集一些想法.我不是在寻找解决方案,只是关于最佳方法/实践的一些想法.

从我的谈话中我似乎需要使用BDD - > ATDD(与小黄瓜场景相关) - > TDD方法.我只是想找出最好的方法.

我目前的想法是

1)创建一个specflow项目并将用户故事提炼成一个小黄瓜.

2)使用GWT语法在小黄瓜(场景)中创建相关的验收测试,从而在[binding]类中生成我的ATTD样式测试(右键单击'generate').

3)使小黄瓜ATDD测试通过.

我遇到的难题是直接链接到我的小黄瓜文件中的ATTD测试的测试并没有给我足够低水平的测试.

那我该怎么办？我是否编写了高级ATDD测试,然后在将它们传递之前,我是否深入挖掘并编写纯TDD测试来设计我的低级对象？

是的,我还没有弄清楚如何以完全BDD的方式工作(纯粹的风格),所以只是想知道我是如何挖掘的.我很欣赏你应该逐步完成并完成一个测试并通过,但我觉得我需要从高级ATDD测试开始然后更深入,所以更高级别的测试不会工作,直到我使我的低级代码工作,但要遵循TDD我需要测试那个低级代码,所以我已经打破了1单元测试的原则然后通过然后重构.....

希望有人明白如何在没有实际操作的情况下告诉我如何处理这个问题.但是这里提供给我的问题是......(我很欣赏,如果测试人员看到这一点,他们可能会因为我在这里问我而失败,但更重要的是我学到而不是得到这份工作).是的我知道我是MAD :-)

我也很想知道我是否应该为我的纯TDD测试设计一个单独的项目.什么是最好的项目结构？我正在考虑1个specflow项目和一个.test项目以及一个用于运行时的类库和控制台应用程序.

PS帮助我的人对我有所帮助.拥抱或慈善捐赠.或者只是这里的+1我猜你真正想要的是: - /

剪刀石头布

User Story Front
+--------------------------------------------------+
|                                                  |
|     Title: Waste an Hour Having Fun              |
|                                                  |
| As a frequent games player,                      |
| I'd like to play rock, paper, scissors           |
| so that I can spend an hour of my day having fun |
|                                                  |
| Acceptance Criteria                              |
|  - Can I play Player vs Computer?                |
|  - Can I play Computer vs Computer?              |
|  - Can I play a different game each time?        |
|                                                  |
+--------------------------------------------------+

User Story Back
+--------------------------------------------------+
|                                                  |
| Technical Constraints                            |
|                                                  |
| - Doesn't necessarily need a flashy GUI          |
|   (can be simple)                                |
| - Can use any modern language                    |
|                              |
| - Libs / external modules should only be used    |
|   for tests                                      |
| - Using best in industry practices               |
|                                                  |
+--------------------------------------------------+

不知道比赛？http://en.wikipedia.org/wiki/Rock-paper-scissors

我正在寻找缩小版本(想想最小可行产品).没有数据库(即会话存储),简单的界面 - 2或3小时的工作(上衣)将是完全合理的.我不是在寻找一个完整的东西,只是一个精心制作的小东西.如果这是Java而不是.NET,并且更多的是面向后端,我会使用控制台应用程序.在C#中寻找单元测试和良好的代码.我正在寻找的是正好使用C#ASP.Net MVC的编码员.

Answer 1

在进行 BDD 时严格遵循 TDD 是可能的，但你不必这样做，我也没有。

BDD 表示编写验收测试并通过单元测试确定细节。因此，在为某个功能编写验收测试后，您可以

• 编写通过验收测试所需的所有代码（然后重构），或者

• 考虑一下您需要哪些类等才能通过验收测试，对每个类进行 TDD（即为每个类编写单元测试，使这些测试通过，然后重构），然后运行验收测试以确保它通过（和重构）。

无论采用这两种方法中的哪一种，都会通过编写单元测试来测试不值得进行验收测试的需求。但是，第一种方法不需要返回并为实现验收测试时创建的每个类编写单元测试。

我用第一种方法，因为

• 更容易思考。它不需要太多的预先设计，也不需要在验收和单元测试之间进行上下文切换。

• 它仅创建通过验收测试所需的代码。我总是发现在接受之前（或不接受）编写单元测试会导致错误的猜测和额外的代码。

• 它不会对任何要求进行两次测试。最小的测试套件更快、更容易维护。

我认为第二种方法的优点是

• 它分解了通过验收测试所需的工作。（但是，凭借我使用的工具和我处理的应用程序，我通常不会在一次性实施验收测试时遇到问题。如果这样做，我会在第一遍中偷工减料，然后返回并填写它们第二次通过。）

• 每个类总是有一个单元测试，因此很容易找到要运行的测试，以确保在更改给定类时没有破坏它。（但是无论如何，您都必须尽快找到并运行相关的验收测试。）

关于项目结构，我总是发现最好将各种测试保留在与代码相同的项目、存储库等中。眼不见，心不烦。