Am I using dependency injection, interfaces, unit testing, in the correct manner?
-
I've recently been having doubts about the way I've been approaching certain aspects of OO design in my projects (C#), and am looking for some advice. I use Castle Windsor IoC/DI framework, where dependencies are injected via class constructors. I also use a mocking framework (Moq) for my unit tests. To support both frameworks I tend to find myself doing one of two things: - creating an interface for every class, even if it's internal, or unlikely to have more than one concrete implementation (such as helper classes) - or, I'll make such a class "mockable", which requires giving it a parameterless constructor, and marking its members as "virtual". Both of these approaches feel like I'm writing additional code just to satisfy these two frameworks (particularly unit testing), but it does mean I can test a class in isolation, without it calling into potentially complex helper class functionality (which is the whole point of a unit test isn't it?). My projects are typically self-contained desktop applications with no public API. Some articles I've read suggest that I should therefore not be using things like DI and interfaces, and I shouldn't even be unit testing internal classes. If I followed the latter advice then none of my code would be covered! (If you're wondering, I'm able to unit test internal classes because I use the "InternalsVisibleTo" attribute in my assemblies). I'm now wondering if I'm taking the "separation of concerns" aspect of OO too far? Am I right to be using dependency injection with internal classes that will only ever have one concrete implementation (e.g. a "helper" class)? Or should I ditch DI and just instantiate such dependent classes? The latter would of course create a strong-coupling, making unit testing more difficult, especially if that helper class contained complex functionality, did database work, etc. I hope I've made my concerns clear. To summarise, I guess I would like to know if I'm not using DI for its intended purpose, and whether my approach to unit testing and mocking is correct.
-
I've recently been having doubts about the way I've been approaching certain aspects of OO design in my projects (C#), and am looking for some advice. I use Castle Windsor IoC/DI framework, where dependencies are injected via class constructors. I also use a mocking framework (Moq) for my unit tests. To support both frameworks I tend to find myself doing one of two things: - creating an interface for every class, even if it's internal, or unlikely to have more than one concrete implementation (such as helper classes) - or, I'll make such a class "mockable", which requires giving it a parameterless constructor, and marking its members as "virtual". Both of these approaches feel like I'm writing additional code just to satisfy these two frameworks (particularly unit testing), but it does mean I can test a class in isolation, without it calling into potentially complex helper class functionality (which is the whole point of a unit test isn't it?). My projects are typically self-contained desktop applications with no public API. Some articles I've read suggest that I should therefore not be using things like DI and interfaces, and I shouldn't even be unit testing internal classes. If I followed the latter advice then none of my code would be covered! (If you're wondering, I'm able to unit test internal classes because I use the "InternalsVisibleTo" attribute in my assemblies). I'm now wondering if I'm taking the "separation of concerns" aspect of OO too far? Am I right to be using dependency injection with internal classes that will only ever have one concrete implementation (e.g. a "helper" class)? Or should I ditch DI and just instantiate such dependent classes? The latter would of course create a strong-coupling, making unit testing more difficult, especially if that helper class contained complex functionality, did database work, etc. I hope I've made my concerns clear. To summarise, I guess I would like to know if I'm not using DI for its intended purpose, and whether my approach to unit testing and mocking is correct.
I'd guess that any meaningful answer has to be based on the reasons you are using the techniques. Interfaces and a framework in a team environment and managed in a central way can be, as I found, a very good way of managing the code people write and also a extremely useful mechanism that enables the interaction of code written in different languages and by different teams. The ability to have another person write a test based on an interface is also very useful. If you're working by yourself some of the benefits interfaces can bring as just mentioned might be regarded as wasted coding time but perhaps bring benefits that are worth the extra code at design and debug time and also in introducing some discipline. However if you're writing code that you expect others to have to work with in the future you're probably contributing to their being able to understand it relatively quickly - though are probably demanding a fair level of expertise from those future people by your selection of framework etc. Also if your code is part of a generic platform used across applications then using interfaces etc. probably contributes to that. However if its for a specific instance then as you suggest you may be adding generality that's not required. From another perspective i.e. yours, rather than 'the company' are you learning skills and methods that improve your standards - it can get very boring doing the simple things without new approaches. I suppose you've got to way the pros and cons on each technique from say a client, company(over say a N year period) and personal perspective to reach a real conclusion.