On Sun, Jun 5, 2011 at 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. > > It's testing the compiler, and not the code? And there are compiler test suites already... > 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. > -- Meski "Going to Starbucks for coffee is like going to prison for sex. Sure, you'll get it, but it's going to be rough" - Adam Hills
