Is it good practice to do unit test coverage for even plain classes

Question

Here is an example of an class with no behaviour at all. So the question is should I be doing unit test coverage for it, as I see it as unnecessary for it does have any behaviour in it.

public class Employee
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public Address Address { get; set; }
}

My code coverage result complains that I have not done any coverage for the class

Answer 1

I never write tests for these. There's no behavior to test.

If there were any non-trivial behavioral code whatsoever (validation code, perhaps), then I would write a test for it.

Answer 2

I found this interesting article from Martin Fowler:

Test coverage is a useful tool for finding untested parts of a codebase. Test coverage is of little use as a numeric statement of how good your tests are.

===

Also this interesting quote from Object mentor:

It’s probably not mandatory and if your goal is 100% coverage, you’ll focus on that goal and not focus on writing the best tests for the behavior of your code.

Answer 3

I could take it or leave it. But while there is little evident benefit now, you would be covered if a programmer later came along, converted those into traditional, member-field backed properties, and fumbled the implementation in the trivial case.

But I personally wouldn't actually bother, as my time is limited and I have more important tests to write which will provide bigger bang for my buck.

Answer 4

Kent Beck in his "Test-Driven Development by Example" lists what you should test:

• conditionals
• loops
• operations
• polymorphism

Your class has none of these.

It often helps to ask yourself a question, "What do I gain if I cover this code with unit tests?". If "points towards some metrics" is the only answer you can come up with, it's probably not worth to write tests for such code. You'll spend time, produce extra code, and gain nothing (code-coverage "points" are of little value - at least in this context).

Also, have a look at those two questions (they both tackle similar issue, and answers primarily resolve around one important point - [in most cases] there's always somebody paying money for what you do - and that somebody might not be very thrilled knowing you spend your time improving ratings, as this is what it essentially is):

• How deep are your tests?
• When to unit test?

Final conclusion? I agree with others saying you should not test such classes.

Answer 5

It is not a bad idea... Say, for instance, you develop a backend for storing this data in the future (e.g.to a database). You might replace the generic get; set; calls with additional custom functionality. Having the unit test ensures that your code is always exercised and that no errors are introduced in the transition.

Even a very simple test that checks to see you can create the object, set fields, and read back the same values shows that you are exercising the code with an expected behavior. Even if it is all obvious to you, future developers on that code will have the example to draw on and ensure any changes match your original design goals.

I also look at it this way: there is little to no harm in developing the test with some very possible long-term advantages. It only takes a few minutes now versus tracking down a problem introduced down the line.

Answer 6

Alternative take on it: the fact that you don't have coverage on this particular class hints that there is some code that uses this class and that code does not have test coverage either. I'd solve that problem first and than see if more test needed.

As for testing such data-only object: I would definitely add explicit test if this object is part of external contract of library/unit. You promise that this data will be returned/consumed by your code. If there is no test verifying that you may change internals of the code and change this class you'll break the promise and nothing to stop you.

Answer 7

If you just keep such classes as data transfer objects one could argue that you don't need unit tests for them. However, as soon as you start adding behaviour, then you should write the corresponding tests.

Looking at code coverage that could be returned as part of your built process may help as well to spot any missing tests.

As a short answer I would say "yes", for plain classes you can get away without getting their coverage.

Answer 8

The point of unit testing is to keep your code "fixed" such that if you change the implementation, you do so knowing that you haven't broken anything, or that if you do break something you immediately know exactly what it is you broke.

A side benefit of this is knowing that your code as it is currently written does what you want it to do, but that is not (or not necessarily) the primary goal of unit testing. Unit testing is so that you can change your code with confidence.

If such a class as above is not unit tested, then the class can be broken without causing any test to fail. E.g.:

public class Employee
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get { return "Smith"; } set { FirstName = value; } }
    public Address Address { get; set; }
}

With unit tests you can know that something like this has not happened across your entire code base. (Is this specific example likely? maybe not. But something like this is very possible and basically innevitable.)

With just four simple unit tests, you can make this code "fixed", knowing that it cannot possibly change it's behaviour without a test failing*:

[TestMethod]
public void TestId() {
   var emp = new Employee { Id = 3 };
   Assert.AreEqual(3, emp.Id);
}

[TestMethod]
public void TestFirstName() {
   var emp = new Employee { FirstName = "asdf" };
   Assert.AreEqual("asdf", emp.FirstName);
}

[TestMethod]
public void TestLastName() {
   var emp = new Employee { LastName = "asdf" };
   Assert.AreEqual("asdf", emp.LastName);
}

[TestMethod]
public void TestAddress() {
   var address = new Address();
   var emp = new Employee { Address = address };
   Assert.AreEqual(address, emp.Address);
}

_{(*maybe except the side case of the broken implementation mimicking the values you use to test)}

I won't implement it here, but you can also use reflection to make writing these kinds of tests easier. For example, you can build something relatively easily that would allow you to do the following:

[TestClass]
public sealed TestEmployee {
   [TestMethod]
   public void TestSimpleProperties() {
      Assert.IsTrue(
         SimplePropertyTester.Create(
            new SimplePropertyTestCollection<Employee> {
               { emp => emp.Id, 3 },
               { emp => emp.FirstName, "asdf" },
               { emp => emp.LastName, "1234" },
               { emp => emp.Address, new Address() }
            }
         ).Test()
      );
   }
}

You lose the benefit of having each property in its own test, but you gain the ability to modify the set of tests very easily.

You could also build a separate tester with a single test for each unit test, and then you keep the tests separate, but it's not a lot different than just writing them manually, and you end up writing basically the exact same line of code over and over and over.

One thing you can do is put Console.WriteLine statements in the Test() method, and then you should be able to have some textual output to look at to pinpoint the problem a lot faster.

EDIT: Actually I've now gotten these to look like the following:

[TestClass]
public sealed TestEmployee {
   [TestMethod]
   public void TestSimpleProperties() {
      var factory = SimplePropertyTestFactory.Create<Employee>();
      new SimplePropertyTestCollection<Employee> {
         factory.IntTest(emp => emp.ID),
         factory.StringTest(emp => emp.FirstName),
         factory.StringTest(emp => emp.LastName),
         factory.ReferenceTest(emp => emp.Address)
      }.Test();
   }
}