On 9/15/06, Jeff Brown <[EMAIL PROTECTED]> wrote: > > I'm not sure about this one. It looks like the embedding for the test > fixture needs (the enumeration data) needs to provide a lot of logic. > There are some particular test patterns I'd like to abstract: > > 1. What happens when calling Current before MoveNext. > 2. What happens when calling Current after MoveNext returns true. > 3. What happens when calling Current after MoveNext returns false. > 4. What happens when calling Current after Reset. > 5. What happens when calling MoveNext after Reset.
It is an example not a complete unit test. The example is to show the idea. Of course if this where for an actual unit test all those things would be addressed. > > I can easily cook up the pattern the test input must satisfy in some > kind of Tester class. I can also verify the results quite easily > because the specification of IEnumerable is known. IMHO pushing > verification down to a class like IEnumerationData partly defeats the > purpose of the Tester. In particular, the caller would have to cook up > several IEnumerationData's with different implementations of > MakeANewTestSubject to ensure that all of the interesting cases get > covered. It's also coupled to the particular sequence of requests > issued by the Tester. I assume you meant to write IEnumerator not IEnumerable. This is a pattern cooked up just for that (not really, a pattern is something that has been created least three times independently, patterns are recorded not authored). It is not just about the results it is about the setup. IEnumerator does not expose enough control and information to drive the test and verify that what was supposed to happen happened. To prevent the test fixture from coupling to this knowledge IEnumerationData was created. It has knowledge of the type providing the IEnumerator. This knowledge allows it control and information for verification. Delegation of these types of tasks is not a new thing. It is used with test doubles all the time. A type of test double is a mock. Test fixtures delegate to test doubles control and verification. > > Ideally I want to be able to extend the Tester to cover new scenarios > without having to modify its inputs in any way. Why? How could it possibly do anything new and different without new and different inputs? > > It might be helpful to think of a related testing approach. We could > annotate a test method with the expected input and output domains of a > given operation. For stateful objects we could annotate the various > transitions among states. Then we have MbUnit go ahead and cook up test > input based on the annotations and verify the results. > > So an interesting way to write a test fixture would be to describe the > state machine of the object under test... This sounds complex and error prone. Have I missed something? -- Jay Flowers ---------------------------------------------------------------------- http://jayflowers.com --------------------------------------------------------------------- --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MbUnit.User" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/MbUnitUser -~----------~----~----~----~------~----~------~--~---
