Test Driven Development with C++: How to test a class which depends on other classes?

Question

Suppose I have a class A which depends on 3 other classes X, Y and Z, either A uses these through a reference or a pointer or say A is templated to be instantiated with X, Y and Z doesn't matter, the key is that in order to test A, I need to have X, Y and Z.

So I need to have fakes for A, B and C. Suppose I write them. Now, how do I swap real and fake objects easily? I can see that this works very easily in the case of templates. In order to make it work when A depends on X, Y and Z through a reference or a pointer, I would need to have a base class say X_Interface from which I can inherit X_Real and X_Fake.

So basically, I would end up in having 3 times the number of classes for every class that would need to have a fake.

I am most likely missing something. There has to be a simpler way to do this. Having a base class X_Interface is also quite expensive as I will be using more space and making virtual calls. I guess I could use CRTP as I know whether its a X_Real or X_Fake at compile time but still there must be a better way.

Answer 1

I think you are looking for a dependency injection framework. See the past SO questions on this.

Answer 2

Unfortunately, there isn't much option in strongly, compile-time typed languages. That's actually OK, because good architecture practice also pushes you towards programming to interfaces, rather than implementations. In order to minimize dependencies between modules/classes, you should have at least, e.g. X_Interface and X_Real. In this case, good design and good testability go hand-in-hand. I suspect that many TDD'ers would point out that that's exactly the point.

Answer 3

First make sure that the objects you depend on (X, Y & Z) are passed in at the constructor, this way you can easily pass in 'fakes' when you are testing. (I really hope you are using a unit test framework, like CUnit)

Now when you are writing the test, all you need to do is make up 'fakes' for the objects the class under test depends on. Often you can just pass in 'null', but if you really need to do something with that 'fake' you can simply instantiate it (you made sure all its dependencies are passed in at the constructor too, right? right!).

Or in an extreme case you might extend the class that is depended upon and reimplement some key methods to suit your test.

So now in most cases you don't need a 'fake', sometimes you simply instantiate a real 'fake', and in rare cases you have an extra class that resides only in your test code.

Look at this video for a much better explanation.

There are more on this topic from GoogleTechTalks, but you'll manage from here.

Answer 4

Although you often hear that a unit test should cover only one class, depending on the complexity of your classes, you may not have to do that and can test all 3 at the same time.

You always have to consider the return on investment. How much will you gain by testing the components separately vs how much effort you have to put into it. A few things to consider:

• If a bug is discovered during automated test of all 3 classes together, will it still be easy to debug it? Is so, consider testing all 3 at the same time.

• Will it be a common thing to replace one of the 3 classes with another class (which implements the same interface)? If so, testing the classes separately may make more sense.

• Are the three classes pretty much designed to only work together? Then test them at the same time.

Also consider that TDD is not the same as Unit Testing. The tests in TDD don't have to be pure unit tests. As long as you can run them in an automated way the tests will do a lot of good. Where I work our test suite is a mix of pure unit tests and command line tools which are executed and verified for an expected return value.

Final note: in the great majority of cases the performance hit from having a pure interface base class won't matter much.