Question

我有一个简单的基于CRUD的应用程序。我试图以TDD方式处理这个问题。我是TDD的新手，实际上无法理解如何继续我的测试。

场景是：

我需要能够创建/更新/删除员工（一次一个）。
我需要能够检索员工列表以便显示

为简单起见，您可以将此视为命令行应用程序。（我实际上将把它作为WPF MVVM应用程序。）

我不确定我的第一次测试应该是什么。

到目前为止我尝试的是：

假设我有一个Employee存储库，它返回一组Employees。

我尝试的第一次测试是：

[Test]
public void RepositoryShouldReturnTheListOfEmployees()
{
    var repository = new EmployeeRepository();
    var employees = repository.GetEmployees();

    Assert.IsNotEmpty(employees);
}

我从这开始，然后从GetEmployees（）方法返回一个Employee对象，以使我的测试通过。然后，一旦测试通过，我重构了EmployeeRepository以实现一个接口并在测试方法上使用它。

这是一项非常简单的任务，这种方法对我来说似乎是一种矫枉过正（至少目前为止）。但我敢肯定，当应用程序变得越来越大，测试时，即使是微不足道的事情也会开始得到回报。

但我觉得我的做法有些不对劲。有经验的TDDer会采用相同的方法吗？那将是什么。此外，我无法想到可以用于“添加员工”功能的测试。

我可以跳过这些CRUD场景，可能会尝试测试其他更复杂的功能......但这是一种正确的方法吗？

基本上我现在正在做的是测试驱动我的存储库除了持久化和检索信息之外没有做任何其他事情。到目前为止，这个TDDing对我来说似乎是一项非常平凡的任务。

感谢您的所有投入。

Answer 1

有时做正确的事情很无聊。

以下是我对此的看法..

您的EmployeeRepository是一个角色，应该支持EmployeeObjects的CRUD。所以这是应用程序和DB /数据存储区之间的端口。（请参阅端口和适配器模式Cockburn等）。

编写记录EmployeeRepository必须满足的规范的测试。这些测试调用角色/接口上的方法。您应该能够替换任何实现（在安装中创建实例）并能够针对它运行测试。例如SqlEmployeeRepository。这可以作为集成测试 - 您正在测试sql子系统遵循EmployeeRepository契约。每个成员都作为建议。
应用程序其余部分的单元测试将使用模拟此角色。他们将测试您的应用程序在EmployeeRepository上进行正确的调用。 Step1将确保您的测试运行得很快..因为您已从测试中消除了SQL依赖性。

基于TDD CRUD的场景

1 个答案: