Search code examples
tddtestdriven.nettestdrivendesign

TDD CRUD based scenario

I've got a simple CRUD based application to be done. I'm trying to approach this in a TDD way. I'm a newbie to TDD and cannot actually understand how to proceed with my tests.

The scenario is:

  • I need to be able to create/update/delete Employees (one at a time).
  • I need to be able to retrieve the list of employees for display purposes

You can assume this to be a commandline application for simplicity. (I'm actually going to do this as a WPF MVVM application.)

I'm not sure what my first test should be.

What I have tried so far is:

Assumed that I have a Employee repository that returns a set of Employees.

My attempted first test was:

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

    Assert.IsNotEmpty(employees);
}

I started with this and then return an Employee object from the GetEmployees() method to make my test pass. Then once the test was passing I refactred the EmployeeRepository to implement an interface and used that on the test method.

This is a quite trivial task and this approach appears to be an overkill for me (at least for now). But I'm sure that when the application grows bigger testing any even the trivial things would start to pay off.

But I have a feeling that something is not right in my approach. Would an experienced TDDer would follow the same approach? or what would that be. Also I can't think of a test that I could use for "Add Employee" functionality.

I can skip these CRUD scenarios and may be try to test drive other more complicated functionalities.. but is that a correct approach?

Basically what I'm doing right now is test driving my repository which doesn't do anything much other than persisiting and retrieving information. So far this TDDing this appeared to be a quite mundane task to me.

Appreciate all your inputs.

Solution

  • Sometimes doing the right thing is boring.

    Here's how I look at this..

    Your EmployeeRepository is a role, which is supposed to support CRUD for EmployeeObjects. So this is a port between your application and the DB/datastore. (Refer to Ports and Adapters pattern Cockburn et all).

    1. Write tests that document the specs that an EmployeeRepository must fulfill.. these tests invoke methods on a role/interface. You should be able to substitute any implementation (create instance in setup) and be able to run the tests against it. e.g. SqlEmployeeRepository. This would qualify as an integration test - you are testing that the sql subsystem follows the EmployeeRepository contract. Each member works as advt.
    2. The unit tests for the rest of the app will use a mock for this role. They would be testing that your app makes the right calls on the EmployeeRepository. Step1 will ensure that your tests run fast.. as you've eliminated the SQL dependency from the tests.