Yup, DI would have been my pick for implementing this. Sure you add a dependancy on a DI framework, but I think it pays off in the long run. The sort of unit tests you describe make the tests brittle, and add NO value to the actual problem you are trying to solve.
On Mon, Jun 6, 2011 at 4:51 PM, Tristan Reeves <tree...@gmail.com> wrote: > Yeah... > I think the problem is that all the tests were done on the base class and > none on the actual class. > But there shouldn't have even been a base/sub class pair. > > There was only one class, and the author then proceeded to split it into 2 > justifying the decision by saying that he needed one for production (with a > 0-param constructor) and one for testing (with a 3-param constructor which > he could pass mocks into). > > Then all this extra uber-weirdness flows from that. To me it's certainly a > case of the code driving the tests (you wouldn't even NEED those tests if > you hadn't split up your code). > > And the reason for the split for the mocks was that the author sees this > method as more meritorious than the many creational OO patterns around, > including DI. > > Thanks for the feedback. > Tristan. > > On Mon, Jun 6, 2011 at 3:46 PM, Scott Baldwin <carpenoctur...@gmail.com>wrote: > >> Hi Tristan, I would argue that this sort of testing is a natural part of >> TDD. It seems as though the author is testing "HOW" the class is >> implemented, not that the class implements the functionality that it was >> created to perform. At some point you have to trust your compiler, if you >> derive one class from another, you should never need to test that an >> instance of the derived class is an instance of the base class. >> >> Your Tests should be driven by functionality not implementation, and your >> implementation should be able to be refactored without impacting >> functionality (and therefore tests). >> >> On Mon, Jun 6, 2011 at 1:59 PM, Heinrich Breedt < >> heinrichbre...@gmail.com> wrote: >> >>> The biggest benefit of proper test naming is that it forces you to think >>> what you are testing. IMHO of course. >>> Resharper allows you to have multiple naming styles. >>> On Jun 6, 2011 1:35 PM, "Stephen Price" <step...@littlevoices.com> >>> wrote: >>> > I follow the suggested naming from The Art of Unit testing by Roy >>> Osherove. >>> > >>> > MethodBeingTested_Inputs_ExpectedResult >>> > >>> > ie: >>> > >>> > Constructor_PassInDependencies_IsNotNull >>> > CreateInstance_PassValidJobId_CreatesInstance >>> > >>> > or whatever. I just make it up as I go along, but by following the >>> > three part template you can tell from the name what is being tested, >>> > what the inputs are and what the expected output is. The thing you are >>> > testing is a black box and that naming tells you all you need to know >>> > about the test, it shouldn't be doing anything else. I group the tests >>> > per class being tested. >>> > >>> > The only annoying thing about this naming is that you have to ignore >>> > Resharper's default naming rules. It doesnt like the underscores. I >>> > must sit down and figure out if there's a way to modify the rules to >>> > allow underscores for unit tests. Anyone done this? >>> > >>> > cheers, >>> > Stephen >>> > >>> > On Mon, Jun 6, 2011 at 10:42 AM, Heinrich Breedt >>> > <heinrichbre...@gmail.com> wrote: >>> >> As an exercise, try making the method name articulate what you are >>> testing. >>> >> Use underscore for space. Don't be afraid to use longish sentence >>> >> >>> >> On Jun 6, 2011 12:32 PM, "Tristan Reeves" <tree...@gmail.com> wrote: >>> >>> ClassForUseInheritsBaseClass >>> >>> On Mon, Jun 6, 2011 at 6:22 AM, Heinrich Breedt >>> >>> <heinrichbre...@gmail.com>wrote: >>> >>> >>> >>>> Just wondering, what is the name of the test? >>> >>>> On Jun 5, 2011 5:06 PM, "Tristan Reeves" <tree...@gmail.com> wrote: >>> >>>> > Hi list, >>> >>>> > I'll describe the situation in as little detail as possible. >>> >>>> > >>> >>>> > There's some code in which a class BaseClass, and a class >>> ClassForUse : >>> >>>> > BaseClass are defined. >>> >>>> > >>> >>>> > BaseClass is used in a unit test that calls its constructor with >>> mocks. >>> >>>> > ClassForUse is used in production with a 0-param constructor which >>> >>>> > calls >>> >>>> the >>> >>>> > base constructor with hard-coded arguments. >>> >>>> > >>> >>>> > Forgetting (for now) any issues with all this (and to me there are >>> >>>> plenty), >>> >>>> > we then find the following unit test: >>> >>>> > >>> >>>> > [Setup] >>> >>>> > var _instance = new ClassForUse(); >>> >>>> > >>> >>>> > [Test] >>> >>>> > Assert.That(_instance is BaseClass); >>> >>>> > >>> >>>> > ...to me this is totally insane. But I seem unable to articulate >>> >>>> > exactly >>> >>>> the >>> >>>> > nature of the insanity. >>> >>>> > >>> >>>> > A little further on we have (pseudocode) >>> >>>> > [Test] >>> >>>> > Assert _instance._MemberOne is of type A >>> >>>> > Assert _instance._MemberTwo is of type B >>> >>>> > Assert _instance._MemberThree is of type C >>> >>>> > >>> >>>> > where the members are (if not for the tests) private members set >>> by the >>> >>>> > 0-param constructor which pushed them into the base constructor. >>> (all >>> >>>> hard >>> >>>> > coded). >>> >>>> > >>> >>>> > So...is this really insane, or is it I who am crazy?? It's made >>> more >>> >>>> > perplexing to me because the author of this code says it's all a >>> >>>> > natural >>> >>>> > result of TDD. And I am far from a TDD expert. >>> >>>> > >>> >>>> > I would love some feedback about this Modus Operandi. esp. any >>> refs. It >>> >>>> > seems obviously wrong, and yet I am unable to come up with any >>> >>>> > definitive >>> >>>> > argument. >>> >>>> > >>> >>>> > Thanks, >>> >>>> > Tristan. >>> >>>> >>> >> >>> >> >> >> >> -- >> Scott Baldwin >> Senior Developer - QSR International <http://www.qsrinternational.com/> >> >> blog: http://sjbdeveloper.blogspot.com >> > > -- Scott Baldwin Senior Developer - QSR International <http://www.qsrinternational.com> blog: http://sjbdeveloper.blogspot.com
