By Miško Hevery Unit Testing as the name implies asks you to test a Class (Unit) in isolation. If your code mixes Object Construction with Logic you will never be able to achieve isolation. In order to unit-test you need to separate object graph construction from the application logic into two different classes The end goal is to have either: classes with logic OR classes with "new " operators. House . In your JUnit test-case you simply instantiate the class House , set it to a particular state, call the method you want to test and then assert that the class' final state is what you would expect. Simple stuff really...class House { private boolean isLocked; private boolean isLocked() { return isLocked; } private boolean lock() { } class House { private final Kitchen kitchen = new Kitchen(); private boolean isLocked; private boolean isLocked() { return isLocked; } private boolean lock() { } House it is not possible to instantiate House without the Kitchen . The reason for this is that the new operator of Kitchen is embedded within the House logic and there is nothing we can do in a test to prevent the Kitchen from getting instantiated. We say that we are mixing the concern of application instantiation with concern of application logic . In order to achieve true unit testing we need to instantiate real House with a fake Kitchen so that we can unit-test the House in isolation. class House { private final Kitchen kitchen; private boolean isLocked; public House(Kitchen kitchen) { this.kitchen = kitchen; } private boolean isLocked() { return isLocked; } private boolean lock() { } new operator from the application logic. This makes testing easy. To test we simply new -up a real House and use a mocking framework to create a fake Kitchen . This way we can still test House in isolation even if it is not a leaf of an application graph. new operators gone? Well, we need a factory object which is responsible for instantiating the whole object graph of the application. An example of what such an object may look like is below. Notice how all of the new operators from your applications migrate here.class ApplicationBuilder { House build() { return new House( new Kitchen(new Sink(), new Dishwasher(), new Refrigerator()) ); } } ApplicationBuilder to construct the object graph for you application and then fires of the application by calling a method which does work.class Main { public static void(String...args) { House house = new ApplicationBuilder().build(); house.lock(); } } new operator) unit-testing becomes impossible for anything but the leaf nodes in your application. Without Dependency Injection the only kind of testing you can do is scenario-testing, where you instantiate the whole application and than pretend to be the user in some automated way.
@Josh
ReplyDeleteWe (Resolver Systems) use a combination of both - although we probably do a bit too much mocking in unit tests.
I often find that dependency injection just adds *another* layer that also needs to be tested though.
@fuzzyman
ReplyDeleteYeah, I'm pretty familiar with mocking too much (both in the context of testing and regular life) ;)
I'm a Java guy so I'm using Spring for all of my injection needs (which is pretty well tested).
Layers are great so long as they add flexibility and don't get in your way.
ah I see what you are getting at. Well, with the ask approach, I believe what he basically means is that the constructor just says that I need this, and it is up to who ever is using that class to provide it. You can go one step higher and plug in a framework which provides all of these, or you might have to, in your main class, construct the object graph creating all the base and calling these constructors which ask for these things.
ReplyDeleteSo in that way, it moves away from a registry pattern. True you can use a registry pattern to satisfy this as well, but it allows you to inject mocks and ignore objects which you don't care about.
Of course, you could just use Guice or Spring which allows easy dependency injection and managing dependencies which create your object graph, and why wouldn't you ? It makes life so much easier :D