2

最近，我开始阅读 BDD 和 TDD 并迷上了。我迷失在大量杂乱无章的信息来源和关于什么是最好什么不是什么的不同意见中。最后我选择了xBehave & xUnit。我喜欢流畅的语法以及使用 Fluent Assertions 和 Fluent Validation 轻松定义行为。

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

  • 当创建没有名称的新产品时，应显示错误
  • 如果在没有分配所有者的情况下创建新产品，则应显示错误。

我创建了实例化一个新产品和一个新产品服务的规范，而新产品服务又创建了产品。规范通过并且正在验证，现在问题是：

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

到目前为止，我还没有 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."));
}

提前感谢您的回复，如果您正在回答此线程，请提供一些材料/文章/示例代码，以说明您的建议为什么会更好地遵循。

4

1 回答 1

0

听起来您正在测试小部件，然后计划将它们粘合在一起形成大的东西。这是（IMO，againt）而不是 TDD（当然也不是 BDD）：您不会让测试驱动设计/架构。

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

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

过了一会儿，看看代码（生产，但也测试）以找到责任。那里有服务的雏形吗？提取它！但不要过早地这样做。让代码告诉你它想要的样子。

开始考虑领域（产品、所有者等）并尽早将其包含在您的代码中。使用持久性（存储库）稍等片刻，但不要太久。

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

于 2012-06-04T06:36:17.673 回答