Do I have to unit-test classes without specific functionalities?

Question

I am learning about unit-testing best-pratices (especially thanks to this post : What makes good unit-test?), because during my project we started to make unit-tests in a bit anarchic way. So now I have to get almost everything from the start to apply strong testing method.

One question the quoted post did not answered was do I have to test all classes, even classes that does not have specific functionnalities ?

Edit : By "no functionality" I mean a class that does not have public methods. For example a Person class which would only have 2 auto-implemented properties for Name and Lastname.

Answer 1

Arguably you shouldn't have classes with no specific functionality (see single responsibility rule), but the answer is yes. Ideally you should unit test all public methods/properties on any class you write.

Ideally:

• Write the test first.
• Create the class/methods etc to make the test compile.
• Implement the bare minimum code required to make the test pass (even returning hard-coded values to match the test if necessary).
• Refactor to remove duplication (i.e. change the code so that it works "properly" rather than returning hard-coded "correct" values).
• Make small changes so that tests continue to pass, and you know exactly what the cause of a failure was as soon as tests start failing.
• Later, rinse, repeat.

I got this process from the Kent Beck TDD book.

Answer 2

Any class should be tested. Test automation is the only way to decrease human factor of software defects. This can be coupled by test simplicity (divide and conquer;) and good software design in the first place.

If your class implements several tasks, then split it. If it implements one case of tasks, but some of them are pretty huge, then move some code to underlying classes that will be invoked when needed. But never implement something that is not well-designed as this means it's not defined properly -- and this leads to poor analysis.

Answer 3

Would an example of a class without functionalities be something like a domain object?

public class DomainObjectFoo
{
    public int Id { get; set; }
    public string Name { get; set; }
    public DateTime DateCreated { get; set; }
}

If all your class contains is auto-implemented properties, fields, etc. then there really isn't anything to test. The instant, however, you add something like

public override string ToString()
{
    return Name;
}

then it merits unit-testing. The unit test may be simple in this case, but that's okay. It'll describe exactly what ToString is supposed to return (in this case, Name). You can even write edge cases for this method as well: What if Name is empty? What if Name is null? Generally, .NET stuff (such as auto-implemented properties) don't need unit tests making sure that the getters and setters work. However, even the simplest of functionality (in this example, ToString()) should be tested.

Answer 4

Hi!

In your case, I don't know if it's worth to test the public auto-generated properties. However, you should think in cases where you expect a non null value.

For example:

public IList<Thing> Things {get; set;}

If you GET this property before you SET it, you'll get a null, and maybe you expect (I often do) a List with zero elements.

Regards!

Answer 5

You may find this question helpful : "How deep are your unit tests?" too.

Answer 6

I'm betting your class does have functionality. For instance, I'd bet that it should throw an exception if the constructor is passed improper input. Also, I'd bet you can probably compare one to another, and expect them to be equal if they both encapsulate the same values.

If it really doesn't have any functionality, and is conceptually more of a structure, then I don't see any need for actual tests.