CODEWITHSUNDEEP
unit-testing
McDonnellDean
McDonnellDean

Reputation: 1087

Unit Testing. When to stop

I have been doing unit testing on my own projects for a little while now and wanted to get feedback on when to stop testing. Consider the following example.

public class Foo
{
    public object Bibble { get; private set; }

    public string Hooch { get; private set; }

    public string BibbleHooch { get { return string.Format("{0},{1}", Bibble, Hooch); } }

    public Foo(object bibble, string hooch)
    {
        if (bibble == null) 
            throw new ArgumentNullException("bibble");

        if (string.IsNullOrEmpty(hooch)) 
            throw new ArgumentNullException("hooch");

        Bibble = bibble;
        Hooch = hooch;
    }
}

These are the following tests I can think of when the constructor is called.

Given that these are different permutations I would say they are all valid scenarios. Granted some duplication could be removed but the fact remains that there are a large number of tests needed to cover constructor creation. If I had SetBibble() / SetHooch methods I am getting into major duplication.

My question is: How much of the above would you test, how do you deal with tests that are permutations, when does the cost of writing the test exceed the value of the test.

Upvotes: 2

Views: 133

Answers (2)

Nathan Hughes
Nathan Hughes

Reputation: 96394

I would test actual logic and not get carried away testing getters and setters. Usually getters and setters get covered in the course of testing the interactions between the objects. The only things in your example that I see as possibly need testing are that the IllegalArgumentExceptions get thrown, and that the formatting works. (Considering your properties allow the members to get reset to null, testing that the exception gets thrown doesn't have a lot of value.)

Unit tests are supposed to be primarily useful to the developer, they're not there to make management happy or satisfy code-coverage metrics (although there are plenty of places that get carried away with that kind of thing). I wouldn't spend time testing for different combinations of things that are not interrelated.

Upvotes: 2

Alex
Alex

Reputation: 7919

Why are you testing for interactions between unrelated parameters? You have named a lot of duplicate tests in your question. As I see it you have:

Null tests

  • ArgumentNullException test for null bibble
  • ArgumentNullException test for null hooch
  • ArgumentNullException test for empty hooch

Property tests

  • Bibble property set correctly by ctor
  • Hooch property set correctly by ctor
  • BibbleHooch property returns expected value

These 6 tests fully cover the entirety of possible scenarios in your class.

If I had SetBibble() / SetHooch methods I am getting into major duplication.

Don't expose setters if it is not necessary. Prefer a minimal interface to your class - you will need fewer tests and the logic will be simpler.

Upvotes: 2

Related Questions