How would I go about unit testing this?

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 appropri开发者_如何转开发ate 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.

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.

To add to Darin's answer I'd like to tell you what you are actually testing. There's a bit of business logic in there, for example the check on the status.

This unit test might seem a bit dumb right now, but what about future changes to your code and model? This test is necessary to make sure this seemingly simple functionality will always keep working.

As you noted, you are testing that the logic in the algorithm behaves as expected. Your approach is correct, but consider the future - Months down the road, this algorithm may need to be changed, a different developer chops it up and redoes it, missing a critical piece of logic. Your unit tests will now fail, and the developer will be alerted to their mistake. Unit testing is useful at the start, and weeks/months/years down the road as well.

If you want to add more, consider how failure is handled. Have your DB mock throw an exception on the delete command, test that your algorithm handles this correctly.

The extra value provided by your tests is to check that your code does the right things (in this case, delete the plan, delete any open tasks associated with the plan and leave any closed tasks associated with the plan).

Assuming that you have tests in place for your Repository classes (i.e. that they do the right things when delete is called on them), then all you need to do is check that the delete methods are called appropriately.

Some tests you could write are:
Does deleting an empty plan only call DeletePlan?
Does deleting a plan with two open tasks call DeleteTask for both tasks?
Does deleting a plan with two closed tasks not call DeleteTask at all?
Does deleting a plan with one open and one closed task call DeleteTask once on the right task?

Edit: I'd use Darin's answer as the way to go about it though.

Interesting, I find unit testing helps to focus the mind on the specifications. To that end let me ask this question...

If I have a plan with 3 tasks:

Plan1 {
 Task1: completed
 Task2: todo
 Task3: todo
}

and I call delete on them, what should the happen to the Plan?

Plan1 : ?
Task1: not deleted
Task2: deleted
Task3: deleted

Is plan1 deleted, orphaning task1? or is it otherwise marked deleted?.

This is a big part of the Value I see in unit tests (Although it is only 1 of the 4 values: 1) Spec 2) Feedback 3) Regression 4) granularity

As for how to test, I wouldn't suggest mocks at all. I would consider a 2 part method The first would look like

public void DeletePlan(Plan p)
{ 
  var objectsToDelete = GetDeletedPlanObjects(p);
  DeleteObjects(objectsToDelete);
} 

And I wouldn't test this method. I would test the method GetDeletedPlanObjects, which wouldn't touch the database anyways, and would allow you to send in scenarios like the above situation.... which I would then assert with www.approvaltests.com , but that's another story :-)

Happy Testing, Llewellyn

I would not write unit tests for this because to me this is not testing behaviour but rather implementation. If at some point you want to chance the behaviour to not delete the tasks but rather set them to a state of 'disabled' or 'ignored', your unit tests will fail. If you test all controllers this way your unit tests are very brittle and will need to be changed often.

Refactor out the business logic to a 'TaskRemovalStrategy' if you want to test the business logic for this and leave the implementation details of the removal up to the class itself.

IMO you can write your unit tests around the abstract PlanRepository and the same tests should be useful in testing the data integrity in the database also.

For example you could write a test -

void DeletePlanTest()
{
    PlanRepository repo = new PlanDbRepository("connection string");
    repo.CreateNewPlan(); // create plan and populate with tasks
    AssertIsTrue(repo.Plan.OpenTasks.Count == 2); // check tasks are in open state
    repo.DeletePlan();
    AssertIsTrue(repo.Plan.OpenTasks.Count == 0);
}

This test will work even if your repository deletes the plan and your database deletes the related tasks via a cascaded delete trigger.

The value of such test is whether the test is run for PlanDbRepository or a MockRepository it will still check that the behavior is correct. So when you change any repository code or even your database schema, you can run the tests to check nothing is broken.

You can create such tests which cover all the possible behaviors of your repository and then use them to make sure that any of your changes do not break the implementation.

You can also parameterize this test with a concrete repository instance and reuse them the test any future implementations of repositories.