在进行BDD时，我必须首先对进行验收测试通过的每段代码进行TDD吗? [英] When doing BDD, must I first TDD each piece of code needed to make an acceptance test pass?

问题描述

我在周末得到了kata的工作.在开始之前，我真的只是想收集一些想法.我不是在寻找解决方案，只是在寻找最佳方法/做法的一些想法.

I've been given a kata to work on over the weekend. Before starting it I really just wanted to gather some thoughts. I'm not looking for the solution, just some ideas on the best approach/practice.

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

From the conversation I had it would seem that I need to use a BDD --> ATDD (relate to scenarios in gherkin) --> TDD approach. I'm just looking to work out the best approach.

我目前的想法是

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

1) Create a specflow project and distill the user story into a gherkin.

2)使用GWT语法在小黄瓜(场景)中创建关联的验收测试，从而在[binding]类中生成我的ATTD风格测试(右键单击生成").

2) Create the associated acceptance tests in the gherkin (the scenarios) using GWT syntax and thus generate my ATTD style tests in the [binding] class (right click 'generate').

3)通过小黄瓜ATDD测试.

3) Make the gherkin ATDD tests pass.

我面临的难题是，直接链接到我的gherkin文件中的ATTD测试的测试没有给我足够低的测试水平.

The conundrum I have is that the tests that link directly to the ATTD tests in my gherkin file don't give me low level enough testing.

那我该怎么办?我要编写高级ATDD测试，然后在通过它们之前先深入研究，然后编写纯粹的TDD测试来设计我的低级对象?

So what do I do? do I write my high level ATDD tests and then before making them pass do I dig down deeper and just write pure TDD tests to design my lower level objects?

是的，我还没有弄清楚如何以完全BDD方式(纯风格)工作，所以想知道我是如何深入研究的.我感谢您应该逐步进行工作并完成一项测试并通过，但我觉得我需要先从高级ATDD测试开始，然后再进行更深入的研究，因此更高级别的测试在我使我的低级代码正常工作之前不会起作用，但要遵循TDD我需要测试该低级代码，因此我已经破坏了1单元测试的原理，然后通过然后重构.....

Yeah, I haven't worked out how to work in a totally BDD manner (pure style) yet so just wondered how I dig down. I appreciate that you should work incrementally and complete one test and pass but I feel I need to start at a high level ATDD test and then go deeper, so the higher level tests wont work until I make my low level code work, but to follow TDD I need to test that low level code and so I have already broken the principle of 1 unit test then pass then refactor.....

希望有人知道如何告诉我怎么做"而不实际这样做.但是这是我所面临的问题...(我很感激，如果测试人员认为这可能使我无法在这里提出要求，但对我而言，学习而不是找到工作更重要).是的，我知道我是MAD:-)

Hope someone understands how to tell me 'how' to approach this without actually doing it. But here is the problem as provided to me...(I appreciate if the tester sees this they may fail me for asking here , but its more important that I learn rather than get the job). Yes I know I'm MAD :-)

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

I'd also love to know if I should have a separate project for my pure TDD tests. What's the best project structure? I'm thinking 1 specflow project and a .test project and a class library and a console app for the runtime.

P.S.任何帮助我解决这个问题的人都会得到我的帮助.拥抱或慈善捐赠.或者，我想这里只是+1是您真正想要的:-/

P.S. anyone that helps me with this has a favour owed to them from me. hug or charity donation. Or just the +1 on here i guess is what you really want :-/

岩石，纸张，剪刀

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的编码器.

I'd be looking for a scaled down version (think minimum viable product). No database (i.e. session stored), simple interface - 2 or 3 hours' worth of work (tops) would be perfectly reasonable. I'm not looking for a full blown thing, just a small thing well crafted. If this was Java and not .NET, and more back end oriented I would make do with a console app. Looking for unit tests and well factored code in C#. What I'm looking for is coders that happen to use C# ASP.Net MVC.

推荐答案

在进行BDD时可以严格遵循TDD，但是您不必，我也不必.

It's possible to follow TDD strictly while doing BDD, but you don't have to, and I don't.

BDD说要编写验收测试，并用单元测试排除细节.因此，在为某个功能编写验收测试后，您可以

BDD says write acceptance tests and drive out the details with unit tests. So, after you write an acceptance test for a feature, you can either

• 编写使验收测试通过(然后进行重构)所需的所有代码，或者

• write all the code needed to make the acceptance test pass (then refactor), or

考虑一下什么类，您需要使验收测试通过，对每个类进行TDD(即为每个类编写单元测试，使这些测试通过，然后进行重构)，然后运行验收测试，以确保其通过(并重构).

think about what classes and such you'll need to make the acceptance test pass, TDD each of them (i.e. write unit tests for each of them, make those tests pass, and refactor), and then run the acceptance test to make sure it passes (and refactor).

不管采用这两种方法中的哪一种，一种测试驱动器要求都不能通过编写单元测试来满足自己的验收测试要求.但是，第一种方法不需要在执行验收测试时为创建的每个类返回并编写单元测试.

Regardless of which of these two methods one follows, one test-drives requirements which don't merit their own acceptance tests by writing unit tests. However, the first method does NOT require going back and writing unit tests for every class created when implementing the acceptance test.

我使用第一种方法，因为

I use the first method, because

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

• it's easier to think about. It doesn't require as much design up front, and it doesn't require context-switching between acceptance and unit tests.

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

it creates only the code needed to make the acceptance test pass. I invariably find that writing unit tests before (or without) acceptance leads to wrong guesses and extra code.

它不会两次测试任何需求.最小的测试套件更快，更易于维护.

it doesn't test any requirements twice. Minimal test suites are faster and easier to maintain.

我可以看到的第二种方法的优点是

Advantages of the second method that I can see are

• 它分解了使验收测试通过所需的工作. (但是，使用我使用的工具和我使用的应用程序，我通常只需要一次性完成验收测试就不会有问题.如果这样做，我会在第一遍检查中偷工减料，然后再将其填入第二遍.)

• it breaks up the work needed to make the acceptance test pass. (But, with the tools I use and applications I work on, I don't usually have a problem just implementing the acceptance test in one go. If I do, I cut corners in the first pass and go back and fill them out in a second pass.)

每个类始终都有一个单元测试，因此很容易找到要运行的测试以确保在更改给定类时您没有破坏它. (但是您还是必须尽快找到并运行相关的验收测试.)

there is always a unit test for every class, so it's easy to find a test to run to make sure you haven't broken a given class when you change it. (But you're going to have to find and run the relevant acceptance test(s) soon enough anyway.)

关于项目结构，我总是发现最好将各种测试与代码保留在同一项目，存储库等中.看不见，忘了.

Regarding project structure, I always find that it's better to keep tests of all kinds in the same project, repository, etc. as the code. Out of sight, out of mind.

这篇关于在进行BDD时，我必须首先对进行验收测试通过的每段代码进行TDD吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！