Question

最近，我开始阅读BDD和TDD，我迷上了。我迷失了大量无组织的信息来源以及对什么是最好的和什么不是什么的不同看法。最后我决定xBehave & xUnit。我喜欢流利的语法和使用Fluent Assertions和Fluent Validation定义行为的简易性。

我也正在尝试使用我正在努力学习的测试项目来实现洋葱架构。这是我的场景：为简化起见，该项目是一个产品跟踪器。我可以创建产品并跟踪谁拥有它。我想实现两个规范：

创建没有名称的新产品时，应显示错误
如果在未指定所有者的情况下创建新产品，则应显示错误。

我创建了一个规范，它实例化了一个新产品和一个新的ProductService，后者又创建了产品。规范通过并且验证正在发生，现在的问题是：

如何测试我的ProductRepository类？我接下来测试它或者模拟它并完成所有规范然后再回来测试存储库类吗？
我应该在第一个规范中嘲笑ProductService类吗？
这是在单元测试级别完成的吗？我应该创建一个单元测试类吗？
不测试存储库会使其成为集成测试吗？

到目前为止，我没有UI，而且我正在编写域，服务和基础架构层的规范。

我需要使用watin进行UI测试吗？
会切换到watin / specflow更有意义，并且可以节省从上到下完全测试图层的努力吗？

这是我参与的规范之一：

[Scenario]
public void creating_new_product_without_a_name_should_throw_error()
{
    var productService = default(IProductService);
    var action = default(Action);
    _
        .Given("a new product", () =>
            productService = new ProductService() as IProductService)

        .When("creating the new product without a name", () =>
            action = () => productService.Create(new Product()))

        .Then("it should should display an error", () =>
            action.ShouldThrow<ValidationException("Name is required."));
}

感谢您提前回复，如果您正在回复此主题，请回复一些材料/文章/示例代码，了解为什么您的建议会更好。

Answer 1

听起来你正在测试小零件，然后计划将它们粘合在一起。这是（IMO，反过来）不是TDD（当然也不是BDD）：你不会让测试推动设计/架构。

首先，不要过多考虑设计。不要以为洋葱架构，不要认为存储库，不要以为服务。

首先编写一个测试，从头到尾验证整个解决方案。使测试尽可能小。首先，请验证，例如显示标签。然后编写您可以想到的最小解决方案，以使测试通过。然后写另一个测试和解决方案。

过了一会儿，看看代码（生产，还要测试）来找到可靠性。那里有某个服务的胚胎吗？提取它！但是不要过早地这样做。让代码告诉你它想要的样子。

预先开始考虑域名（产品，所有者等），并在代码的早期包含它。持续等待一段时间（存储库），但不要太久。

继续在此级别进行测试（端到端）。必要时添加微测试。所以我对“如何测试我的ProductRepository / Service类”这个问题的回答是一个问题：你需要吗？或者它是否被端到端测试充分覆盖？如果没有，为什么？

外部不同层的BDD解决方案测试

1 个答案: