Correct way to cover dependencies in unit tests

Question

My approach to unit testing feels very wrong. I feel like I am missing something very basic, and I'm looking for some insight please.

Let's assume that I am testing a method (I'm using NUnit) that returns an object. It might look like this:

public void TestConnection()
{
     DBConnector dbConn = new DBConnector(connString);
     Assert.IsInstanceOf(typeof(DBConnector), dbConn);
}

Let's assume too that the test passes.

Later in my test class, I create another test on an object that has a dependency on MyObject. That test method might look like this:

public void IsCallInstanceNull()
{
     DBConnector dbConn = new DBConnector(connString);
     dbConn.EstablishConnection();
     CallInstance ci = new CallInstance(dbConn);
     Assert.IsNotNull(ci);
}

I am first marking TestConnection() "public void", ensuring a basic pass, then changing the method to private so that I can use a typed object in the second method, instead of duplicating code. So my example test class becomes:

private DBConnector CreateDBConnector()
{
     var dbConn = new DBConnector(connString);
     dbConn.EstablishConnection();
     return dbConn;
}

public void IsCallInstanceNull()
{            

     CallInstance ci = new CallInstance(CreateDBConnector());
     Assert.IsNotNull(ci);
}

But this feels completely wrong. No one will ever know that the constructor for DBConnector was ever tested (since not only did I change its visibility, I renamed the method!) so how can this be refactored so that I ensure test coverage for the private method without having to leave 2 almost identical methods in the test class?

Answer 1

Okay so I'll try answer the meta-question about unit testing with dependencies. As others have pointed out, your examples aren't really unit tests, which makes it a little difficult to redo them.

First point. the aim of a unit test is to test some behaviour of the system, in an isolated manner. This is important to keep in mind as not all dependencies are the same, and their nature dictates how you'll handle them.

Some dependencies will be the source of state, some will be the source of domain logic/knowledge and others will be further system behaviour.

So lets take the following code: (Implied is the code to set the fields which hold the dependencies)

public class House {
  private TemperatureSensor thermometer;
  ...
  public bool IsLoungeTooHot() {
    return thermometer.CurrentTemperature > 20;
  }
}

It's a simple class with a single bit of behaviour checking the lounge temperature and a single dependency on a thermometer.

So thermometer is the source of the data and as such it is always faked since the test needs to be able to use multiple temperatures to ensure it works (at the very least return temp below 20 and above 20)

Now if we were to extend the code to

public class House {
  private TemperatureSensor thermometer;
  private Thermostat thermostat;
  ...
  public bool IsLoungeTooHot() {

    return thermometer.CurrentTemperature > thermostat.DesiredTemperature;
  }
}

So we now the desired temperature is no longer a constant but rather retrieved from a domain object. So the thermostat dependency is something that will almost never be faked (safe to read never but there can be edge cases). The reason why we don't want to fake this is to protect ourselves against test fragility.

As the writers of the code we could create a perfect fake of the Thermostat. However it would only be perfect at the moment we wrote the test. At some point down the line the behaviour of Thermostat could change, and if we had used a fake there is a very good chance we would not notice.

Third and final extension of the code:

public class House {
  private TemperatureSensor thermometer;
  private Thermostat thermostat;
  private DataRepository repo;
  ...
  public bool IsLoungeTooHot() {
    repo.Audit("IsLoungTooHot");
    return thermometer.CurrentTemperature > thermostat.DesiredTemperature;
  }
}

The repo dependency similar to the thermostat dependency, it is additional system behaviour. However in this specific case we would replace it with a fake because using the real database would break the isolation we need to ensure that this test doesn't affect other tests that may also be running.

A bit of a wall of text, hope it's made things a little clearer.

---

fake - stub/mock see https://stackoverflow.com/a/346440/5889 for a good explanation of the differences.

Answer 2

When unit testing a class you should focus only on the functionality in that class. For all other dependencies, mocking should be used. That is to say you should create "fake" implementations of the dependencies and use them to simulate the real thing. You can then run tests against the mocks to ensure that they are being used correctly according to the functionality of the class under test.

In order to do this you will have to inject all dependencies(this is pretty much always what you should be doing), likely in your constructor.

Your test example doesn't tell us too much and doesn't test anything. Instantiating a class then validating its type is not a test. Could you provide the class that you would like to test? Then we can give concrete examples.

I wrote a tutorial for using Moq to test dependencies, it can be found here: http://stevemichael.net/how-do-i-use-moq-with-asp-net-mvc/