I'm TDDing a larger (delegating) class, and it got fugly.
First of all... I tried to set up too complicated a fixture, I think, and it took way too long.
The reason why? I think the cause of the problem was I was trying to use "pseudo-real" data to drive the tests. But it doesn't seem to work when talking about "delegator" types, because the inputs and outputs for delegators should actually be simpler...... I *think*.
I believe what ended up happening was the creation of Integration tests instead of unit tests, because in the end the data I was feeding in was meant to elicit proper outputs from delegatees instead of just the SUT (the delegator).
Who's driving this bus?
I'm confused, though, as to what to think. TDD is supposed to drive the development of your "system under test". In this case, I'm talking about a delegating class that either aggregates, or has as policies previously TDD'ed classes/components.
What does this mean about using "specific examples" to drive development, in this case? In other words... what type of "specific example" would be needed to TDD a delegator type?
Do I need to just fall back and test that the "depended-on components" are called, through stubs/spies/mocks?
? ? ?
I realize the end result *should be* an algorithm in code form, which utilizes the delegatee classes. There's just a disconnect in my brain somewhere about what type of "specific example" would drive this development.
And I leave for Philadelphia tonight at 10PM.