Timeline for How to unit test without mocks and not be tied to a concrete implementations of an interface
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 14, 2014 at 18:28 | comment | added | Dave S | @RobertHarvey To clarify, the question was how to test using real objects instead of mocks. Normally I use mocks (and no IoC container in unit tests!) | |
| May 14, 2014 at 16:43 | comment | added | Robert Harvey | You don't need an IoC container to mock them, so I don't understand your statement about modifications. If you change the implementation in your real application (say, for performance reasons), but the contracted behavior stays the same, then your tests will not change, IoC container or not. I assume that, if you do use an IoC container in your tests, you will be configuring the container with mock objects, not the real ones. | |
| May 14, 2014 at 16:42 | comment | added | Dave S | @DougM This is exactly my question, I cannot use an IoC container, so I am forced to hard-code my concrete classes. | |
| May 14, 2014 at 16:41 | comment | added | DougM | @DaveS: If you're using an IoC container, you're not really testing a unit, you're testing a bunch of units. | |
| May 14, 2014 at 16:40 | comment | added | Dave S | Only in that if change the class that I use as the concrete implementation in my real application, I need to modify all of my unit tests. If I mock them, I only need to change the mocks if the interface changes. | |
| May 14, 2014 at 16:34 | comment | added | Robert Harvey | Is that a problem? | |
| May 14, 2014 at 16:33 | comment | added | Dave S | This was my point, I shouldn't be using an IoC container. This means that I have to hard code all of my concrete implementations in to my unit tests. | |
| May 14, 2014 at 16:20 | history | answered | Robert Harvey | CC BY-SA 3.0 |