C# Unit Testing – How and What to Test in a Method?

cnettestingunit testing

I am relatively new to unit testing and have a query about what/how I should be testing a certain method. For the following (psudo-c#) method I have created (not a real-life example) what would you test for?

Initially, my thoughts would be to test the output with variations on the dictionary of form fields, e.g. valid, invalid, missing values. However I also wonder how you would test to make sure the object values have been changed to the correct value and that the correct email message was attempted to be sent (obviously both services could/would be mocked).

I hope what I am asking makes sense, I appreciate this is a subjective question and the answers may be 'it depends' 😉

public bool ProcessInput(Dictionary<string, string> formFields, ObjService objService, EmailService emailService)
    {
        try
        {
                   // Get my object id
                   int objId;
                   if(!int.TryParse(formField["objId"], out objId)
                   {
                      return false;
                   }

                   // Update my object - would you validate the save against a DB or a mocked inmemory db?
                   var myObj = objService.Find(objId);
                   myObj.Name = formField["objName"];
                   objService.Save(myObj);

                   // Send an email - how would you test to make sure content, recipient, etc was correct? 
                   emailService.SendEmail(formField("email"), "Hello World");

                   return true;    
        }
        catch(Exception ex)
        {
        return false;
        }
    }

Best Answer

You are on the right track. You should be testing (at least) the following scenarios:

invalid (non-integer) object ID: the method should return false and no changes should be made (i.e. no services called)
unknown object ID: the method should probably behave similarly to case 1 (but currently it does not seem to handle that case)
valid object ID, valid name in the form field: object should be saved to the object service, email should be sent
valid object ID but missing name in the form field: similar to case 3???

Both ObjService and EmailService should be mocked in your tests, then you can verify that they are (not) called with the expected parameters.

Related Solutions

Unit Testing and DRY Principle – Best Practices

There's a little warning about the DRY principle that many people aren't aware of: Don't get so obsessed about avoiding repetition that you remove 'duplicates' of things that appear to be the same but are actually conceptually very different.

As an extreme example you wouldn't try to remove the repetition of the duplicates of '/s', 'th', 'on', 'nt', etc within your original string.

In your particular example, you don't/shouldn't care about implementation details of your code under test. (I.e. that it uses the STRING_TEMPLATE const.) Your test cares about the fact that when you:

void Test() {
  DoSetup(...);
  ActualResult = DoProcess(...);
  Check(ActualResult == "/some/constant/string/with/1234/that/needs/interpolation/");
}

The fact that "/some/constant/string/with/1234/that/needs/interpolation/" is similar to STRING_TEMPLATE should be considered coincidental, not a violation of DRY.

NOTE: This of course doesn't apply if you're actually testing some localisation aspect of your system, or if your system is affected by localisation that you initially set up via STRING_TEMPLATE. Because then the duplication is explicit.

Unit-testing – Unit testing in Django

I'm going to go ahead and register an answer for what I've come up with so far.

My hypothesis is that for a function with deep coupling and state, the reality is that it's simply going to take a lot of lines to control for its outside context.

Here's what my test case looks like roughly, relying on the standard Mock library:

I use the standard ORM to set up the sequence of events
I create my own start datetime and subvert the auto_now_add times to fit a fixed timeline of my design. I thought that the ORM didn't allow this, but it works fine.
I make sure the function-under-test uses from datetime import datetime so that I can patch datetime.now() in just that function (if I mock the entire datetime class, the ORM pitches a fit).
I create my own replacement for object.key_method(), with simple but well defined functionality that depends on the arguments. I want it to depend on the arguments, because otherwise I might not know if the logic of the function-under-test is working. In my case, it simply returns the number of seconds between startTime and endTime. I patch it in by wrapping it in a lambda and patching directly on to object.key_method() using the new_callable kwarg of patch.
Finally, I run a series of asserts on various calls of summary with different arguments to check equality with expected hand-calculated results accounting for the given behavior of the mock key_method

Needless to say, this is significantly longer and more complicated than the function itself. It depends on the DB, and doesn't really feel like a unit test. But it is also fairly decoupled from the internals of the function--just its signature and dependencies. So I think it might actually be a unit test, still.

In my app, the function is quite pivotal, and subject to refactoring to optimize its performance. So I think the trouble is worth it, complexity notwithstanding. But I'm still open to better ideas on how to approach this. All part of my long journey toward a more test-driven style of development...

Best Answer

Related Solutions

Unit Testing and DRY Principle – Best Practices

Unit-testing – Unit testing in Django

Related Topic