Question

I need to develop a fairly simple algorithm, but am kindof confused as how to best write a test for it.

General description: User needs to be able to delete a Plan. Plan has Tasks associated with it, these need to be deleted as well (as long as they’re not already done).

Pseudo-code as how the algorithm should behave:

   PlanController.DeletePlan(plan)
     =>
     PlanDbRepository.DeletePlan()
      ForEach Task t in plan.Tasks
          If t.Status = Status.Open Then
            TaskDbRepository.DeleteTask(t)
          End If
      End ForEach

Now as far as I understand it, unit tests are not supposed to touch the Database or generally require access to any outside systems, so I’m guessing I have two options here:

1) Mock out the Repository calls, and check whether they have been called the appropriate number of times as Asserts

2) Create stubs for both repository classes, setting their delete flag manually and then verify that the appropriate objects have been marked for deletion.

In both approaches, the big question is: What exactly am I testing here? What is the EXTRA value that such tests would give me?

Any insight in this would be highly appreciated. This is technically not linked to any specific unit testing framework, although we have RhinoMocks to be used. But I’d prefer a general explanation, so that I can properly wrap my head around this.

Answer 1

You should mock the repository and then construct a dummy plan in your unit test containing both Open and Closed tasks. Then call the actual method passing this plan and at the end verify that the DeleteTask method was called with correct arguments (tasks with only status = Open). This way you would ensure that only open tasks associated to this plan have been deleted by your method. Also don’t forget (probably in a separate unit test) to verify that the plan itself has been deleted by asserting that the DeletePlan method has been called on the object your are passing.