周末我被给了kata工作。在开始之前我真的只想收集一些想法。我不是在寻找解决方案，只是关于最佳方法/实践的一些想法。
从我的谈话中我似乎需要使用BDD - ＆gt; ATDD（与小黄瓜中的情景有关） - ＆gt; TDD方法。我只是想找出最好的方法。
我目前的想法是
1）创建一个specflow项目并将用户故事提炼成一个小黄瓜。
2）使用GWT语法在小黄瓜（场景）中创建相关的验收测试，从而在[binding]类中生成我的ATTD样式测试（右键单击'generate'）。
3）让小黄瓜ATDD测试通过。
我遇到的难题是直接链接到我的小黄瓜文件中的ATTD测试的测试并没有给我足够低水平的测试。
那我该怎么办？我是否编写了高级ATDD测试，然后在将它们传递之前，我是否深入挖掘并编写纯TDD测试来设计我的低级对象？
是的，我还没有弄清楚如何以完全BDD的方式工作（纯粹的风格），所以只是想知道我是如何挖掘的。我很欣赏你应该逐步完成并完成一个测试并通过，但我觉得我需要从高级ATDD测试开始然后更深入，所以更高级别的测试不会工作，直到我使我的低级代码工作，但要遵循TDD我需要测试那个低级代码，所以我已经打破了1单元测试的原则，然后通过了重构......
希望有人明白如何在没有实际操作的情况下告诉我如何处理这个问题。但是这里提供给我的问题是......（我很欣赏，如果测试人员看到这一点，他们可能会因为我在这里问我而失败，但更重要的是我学到而不是得到这份工作）。是的我知道我是MAD： - ）
我也很想知道我的纯TDD测试是否应该有一个单独的项目。什么是最好的项目结构？我正在考虑1个specflow项目和一个.test项目以及一个用于运行时的类库和控制台应用程序。
P.S。任何帮助我的人都会对我有所帮助。拥抱或慈善捐赠。或者只是这里的+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的编码员。
答案 0 :(得分：1)
在做BDD时可以严格遵守TDD，但是你不必这样做，而且我不会。
BDD表示写入验收测试并通过单元测试推出详细信息。因此，在为功能编写验收测试后，您可以
编写验收测试通过所需的所有代码（然后重构）或
考虑哪些类等你需要进行验收测试，TDD各自（即为每个类编写单元测试，使这些测试通过，重构），然后运行验收测试以确保它通过（和重构）。
无论采用这两种方法中的哪一种，一种测试驱动要求都不值得通过编写单元测试来进行自己的验收测试。但是，第一种方法不需要返回并为实现验收测试时创建的每个类编写单元测试。
我使用第一种方法，因为
它更容易思考。它并不需要预先设计，并且它不需要在验收和单元测试之间进行上下文切换。
它只创建验证测试通过所需的代码。我总是发现在接受之前（或不接受）编写单元测试会导致错误的猜测和额外的代码。
它没有两次测试任何要求。最小的测试套件更快，更容易维护。
我能看到的第二种方法的优点是
它打破了验收测试通过所需的工作。 （但是，通过我使用的工具和我所使用的应用程序，我不会一次只能实施验收测试。如果我这样做，我会在第一遍中偷工减料并回去填充它们在第二次通过。）
每个班级都有一个单元测试，因此很容易找到要运行的测试，以确保在更改时不会破坏给定的类。 （但是你无论如何都要尽快找到并运行相关的验收测试。）
关于项目结构，我总是发现最好将所有类型的测试保存在同一个项目，存储库等中作为代码。看不见，心不在焉。
答案 1 :(得分：0)
来自WordPress后端世界的想法[是的，这是一件事] ......
你正在做BDD！实际上，你所讨论的这种二分法在我看来是做BDD的主要方面之一。一般来说，验收测试比单元测试更慢，更脆，更少集中。通常，您使用浏览器测试的内容可以通过其他方式进行测试，例如API测试或单元测试。通常最好减少使用浏览器或端到端测试，并增加单元测试的使用。 我喜欢将验收测试视为尚未重新计算的单元测试。
我使用Codeception [for WordPress / PHP]虽然我的评论是框架无关的。 Codeception轻松地在基于浏览器的测试和单元测试之间切换。 Codeception的一个优点是它具有自由形式的PHP验收测试，比Gherkin更进一步[它还运行Gherkin]。因此，我可以从接受测试开始，这些测试不如Gherkin场景那样正式且不完整。很多时候它只是一堆评论或笔记。 [顺便说一句：作为一名自由职业小企业开发人员，我还没有看到一个能够容忍Gherkin的非程序员。不是一个。]在开发中[与测试相对]我经常发现，当我从验收测试开始时，他们开始有点模糊或半工作。因此，我可能会从半开始的验收测试开始，但实际上并没有做太多的事情，当我尝试将其变成某种东西时，我会专注于为项目添加UNIT测试。
换句话说，我使用验收测试来推动接下来要进行的单元测试。希望在一堆循环结束时，我要么有一个非常好的和简单的验收测试，它是激光聚焦和更多的单元测试 - 或者 - 理想情况下我完全取消了验收测试并且只进行了一系列快速单元测试。它有点蒸发成一堆单元测试。
至于测试的内容。如果你是一个团队，那就测试一切。如果你是独自工作，那就这样做：当你的思想开始在脑海中形成应该发生的事情的时候，开始根据你的半想法进行单元测试。如果可以省去一些验收测试，太棒了！如果思想完成，请完成测试以使其成为现实。一旦测试完成，如果你想在没有进行另一次测试的情况下漫步，那很好。继续。只需保持代码简洁明了。当你独自工作时，你不必担心报道，它只是一个工具。反复这样做很快就会有一堆测试和对你的代码充满信心。