Unit Testing a 'SetDefaults()' method

Question

I am in the process of learning to unit test. I have a 'domain object' that doesn't do much apart from hold state (i.e. 'Employee' without any business logic). It has a method SetDefaults() which just fills its state with reasonable values. A simple method.

But when I go to unit test this method all I can think of is to run the method then check that every field is what it should be. Like (in C#):

     [TestMethod()]
 public void SetDefaultsTest()
 {
  Employee target = new Employee();

  employee.SetDefaults();

  Assert.AreEqual(employee.Name, "New Employee");
  Assert.AreEqual(employee.Age, 30);
  // etc.
 }

It feels wrong to duplicate the entire functionality of SetDefaults() within my test. Should I just leave this method untested? The problem is that I'd like a test to ensure that when new properties are added to the class they are also added to the SetDefaults() method.

Answer 1

Trivial getters and setters sometimes don't have unit tests written for them. If that's all that SetDefaults() does, it probably won't hurt to skip it.

One thing you would want to consider testing, though, is that none of the set properties of the employee instance are null after calling SetDefaults():

var nonNullProperties = new object[] { employee.Name, employee.Age, ... };
foreach (var property in nonNullProperties)
  Assert.IsNotNull(property);

This makes sense, since you really just care that they are set to some default value, and not so much that they're a specific value.

Answer 2

It depends on what value you get out of that test. Don't test just for the sake of testing. However, if those defaults are important to be correct, and not change, then go right ahead.

A lot of testing involves deciding "Hey, is this going to make my job easier in the long run?" Are these defaults changing all the time, or are they constant? Are the defaults very complicated, or are they a handful of strings and numbers? How important is it to the customer that these defaults are correct? How important is it to the other developers that the defaults are correct?

The test could do a million things, but if it doesn't add some value to someone who cares about it, then don't worry about it. If you've been asked to automate testing of 100% of all your code, perhaps reading up and discussing some of the ideas presented in the following blogs might benefit your team:

http://blog.jayfields.com/2009/02/thoughts-on-developer-testing.html http://msdn.microsoft.com/en-us/magazine/cc163665.aspx

Otherwise, if it doesn't add much value or constantly breaks, I'd say go ahead and leave it out.

Answer 3

That looks like a pretty reasonable unit test to me. You are providing a simple test that checks the results of calling that method. It doesn't help you with any new properties though, as the existing test would still pass. Perhaps you could use Reflection to iterate over all the properties of the object and check they are non-null?

Also SetDefaults() seems like a slightly odd method. Why not just initialise a new Employee to those values to start with? That way there is no risk that another coder will create an Employee and forget to call SetDefaults().