Tristan Reeves 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.
Heya,
I'm no TDD ninja so I can't really speak for convention/etc, but it
seems the test is making sure that the derived class is a child of the
parent class, and then goes on to the compiler/language features more
than the actual functionality of the code itself, which could be argued
as somewhat unnecessary.
--
Les Hughes
[email protected]
