5

周末有人给了我一个 kata 工作。在开始之前，我真的只是想收集一些想法。我不是在寻找解决方案，只是关于最佳方法/实践的一些想法。

从我的谈话来看，我似乎需要使用 BDD --> ATDD（与 gherkin 中的场景相关） --> TDD 方法。我只是想找出最好的方法。

我目前的想法是

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

2）使用 GWT 语法在小黄瓜（场景）中创建相关的验收测试，从而在 [binding] 类中生成我的 ATTD 样式测试（右键单击“生成”）。

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

我遇到的难题是，直接链接到我的小黄瓜文件中的 ATTD 测试的测试没有给我足够低级别的测试。

那我该怎么办？我要编写高级 ATDD 测试，然后在使它们通过之前，我是否深入挖掘并编写纯 TDD 测试来设计我的低级对象？

是的，我还没有弄清楚如何以完全 BDD 方式（纯风格）工作，但我只是想知道我是如何挖掘的。我很欣赏您应该逐步工作并完成一项测试并通过，但我觉得我需要从高级 ATDD 测试开始，然后更深入，所以在我使低级代码工作之前，更高级别的测试将无法工作，但要遵循TDD 我需要测试那个低级代码，所以我已经打破了 1 个单元测试然后通过然后重构的原则......

希望有人明白如何告诉我“如何”在没有实际操作的情况下解决这个问题。但这是提供给我的问题......（我很感激如果测试人员看到这一点，他们可能会因为在这里问我而失败，但更重要的是我学习而不是得到这份工作）。是的，我知道我很生气 :-)

我也很想知道我是否应该为我的纯 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 的编码器。

4

2 回答 2

1

在做 BDD 时可以严格遵循 TDD，但你不必，我也不必。

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

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

  • 想想你需要哪些类和这样的类来使验收测试通过，对它们中的每一个进行 TDD（即为它们中的每一个编写单元测试，使这些测试通过，然后重构），然后运行验收测试以确保它通过（和重构）。

不管遵循这两种方法中的哪一种，一种是通过编写单元测试来测试那些不值得自己进行验收测试的需求。但是，第一种方法不需要返回并为实现验收测试时创建的每个类编写单元测试。

我使用第一种方法，因为

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

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

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

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

  • 它分解了使验收测试通过所需的工作。（但是，使用我使用的工具和我从事的应用程序，我通常不会有问题，只需一次实施验收测试。如果我这样做了，我会在第一遍中偷工减料，然后回去填写第二遍。）

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

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

于 2016-02-03T12:11:24.127 回答
0

来自 WordPress 后端世界的想法 [是的，这是一件事]...

你在做BDD！实际上，您正在讨论的这种二分法在我看来是进行 BDD 的主要方面之一。一般来说，验收测试比单元测试更慢、更脆弱、更不集中。通常，您使用浏览器测试的内容可以通过另一种方式进行测试，例如使用 API 测试或单元测试。通常最好减少对浏览器或端到端测试的使用，并增加对单元测试的使用。我喜欢将验收测试视为尚未重构的单元测试。

尽管我的评论与框架无关，但我使用 Codeception [for WordPress / PHP]。Codeception 在基于浏览器的测试和单元测试之间轻松切换。Codeception 的一个简洁功能是它具有自由形式的 PHP 验收测试，比 Gherkin [它还运行 Gherkin] 更进一步。所以我可以从比 Gherkin 场景不那么正式和不完整的验收测试开始。很多时候，它只是一堆评论或注释。[顺便说一句：作为一名自由小型企业开发人员，我还没有看到一个能够容忍 Gherkin 的非程序员。不是一个。]在开发中[与测试相反]，我经常发现当我开始接受测试时，它们开始有点模糊或一半工作。所以我可能会从一个做不了多少的验收测试开始，当我试图把它变成一些东西时，

换句话说，我使用验收测试来驱动我接下来要进行的单元测试。希望在一堆周期结束时，我要么有一个非常好的和简单的以激光为中心的验收测试和更多的单元测试 - 或者 - 理想情况下我完全消除了验收测试，只进行了一堆快速的单元测试. 它有点蒸发成一堆单元测试。

至于要测试什么。如果您在团队中，请测试所有内容。如果您自己工作，请执行以下操作：当您开始在脑海中形成关于应该发生什么的想法时，开始根据您的一半想法进行单元测试。如果可以消除一些验收测试，那就太好了！如果想法完成，请完成测试以使其成为现实。测试完成后，如果您想在不进行其他测试的情况下继续进行，那很好。继续。只需保持代码简洁明了。当您自己工作时，您不必担心覆盖范围，它只是一个工具。一遍又一遍地这样做，很快你就会有一堆测试和一堆对你的代码的信心。

于 2018-02-01T12:51:28.280 回答