Correct way to cover dependencies in unit tests 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?
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/