我得到了一个周末练习的型。在开始之前，我真的只是想收集一些想法。我不是在寻找解决方案，只是在寻找有关最佳方法/实践的一些想法。
从我的谈话来看，我似乎需要使用 BDD --> ATDD(与小 cucumber 中的场景相关)--> TDD 方法。我只是想找出最好的方法。
我目前的想法是
1) 创建一个 specflow 项目并将用户故事提炼成小 cucumber 。
2) 使用 GWT 语法在小 cucumber (场景)中创建关联的验收测试，从而在 [binding] 类中生成我的 ATTD 样式测试(右键单击“生成”)。
3) 让小 cucumber ATDD 测试通过。
我遇到的难题是，直接链接到我的 gherkin 文件中的 ATTD 测试的测试没有给我提供足够低级别的测试。
那我该怎么办？我应该编写我的高级 ATDD 测试，然后在让它们通过之前我是否深入挖掘并只编写纯 TDD 测试来设计我的较低级别对象？
是的，我还没有想出如何以完全 BDD 的方式(纯粹的风格)工作，所以只是想知道我是如何深入挖掘的。我很欣赏你应该逐步完成一个测试并通过，但我觉得我需要从高级 ATDD 测试开始然后更深入，所以在我使我的低级代码工作之前更高级别的测试不会工作，但是要遵循TDD 我需要测试那些低级代码，所以我已经打破了 1 个单元测试然后通过然后重构的原则......
希望有人知道如何告诉我“如何”在不实际执行的情况下处理这个问题。但这是提供给我的问题......(我很感激如果测试人员看到这个他们可能会因为我在这里问而失败，但更重要的是我学习而不是得到这份工作)。是的，我知道我很生气 :-)
我也很想知道是否应该为我的纯 TDD 测试创建一个单独的项目。什么是最好的项目结构？我在考虑 1 个 specflow 项目和一个 .test 项目以及一个类库和一个用于运行时的控制台应用程序。
附言任何帮助我的人都是我欠他们的人情。拥抱或慈善捐赠。或者只是这里的 +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
我会寻找缩小版(想想最小可行产品)。 没有数据库(即存储的 session )，简单的界面 - 2 或 3 小时的工作(顶部)将是完全合理的。 我不是在寻找一个完整的东西，只是一个精心制作的小东西。如果这是 Java 而不是 .NET，并且更面向后端，我会使用控制台应用程序。 在 C# 中寻找单元测试和分解良好的代码。 我正在寻找的是碰巧使用 C# ASP.Net MVC 的编码器。
最佳答案
在执行 BDD 时可以严格遵循 TDD，但你不必这样做，我也不需要。
BDD 表示编写验收测试并通过单元测试驱动细节。因此，在为某个功能编写验收测试后，您可以
编写使验收测试通过(然后重构)所需的所有代码，或者
考虑需要哪些类等才能通过验收测试，对每个类进行 TDD(即为每个类编写单元测试，使这些测试通过，然后重构)，然后运行验收测试以确保它通过(并重构)。
无论遵循这两种方法中的哪一种，一种方法都是通过编写单元测试来测试不值得进行自己的验收测试的需求。但是，第一种方法不需要返回并为实现验收测试时创建的每个类编写单元测试。
我用的是第一种方法，因为
更容易思考。它不需要那么多的预先设计，也不需要在验收测试和单元测试之间进行上下文切换。
它只创建使验收测试通过所需的代码。我总是发现在接受之前(或没有接受)编写单元测试会导致错误的猜测和额外的代码。
它不会对任何要求进行两次测试。最少的测试套件更快，更易于维护。
我能看到的第二种方法的优点是
它分解了通过验收测试所需的工作。 (但是，使用我使用的工具和我处理的应用程序，我通常不会遇到一次性实现验收测试的问题。如果我这样做，我会在第一次通过时偷工减料，然后返回并在第二遍。)
每个类总是有一个单元测试，因此很容易找到要运行的测试，以确保您在更改给定类时没有破坏它。 (但无论如何，您将不得不尽快找到并运行相关的验收测试。)
关于项目结构，我总是发现最好将各种测试与代码放在同一个项目、存储库等中。眼不见，心不烦。
关于.net - 在进行 BDD 时，我是否必须首先对通过验收测试所需的每段代码进行 TDD？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15300521/