On Wed, Jan 5, 2011 at 6:41 PM, John Zabroski <[email protected]>wrote:
> > 5. I have a hard time understanding statements like "The difficulties in > unit testing OO code is coaxing objects into the correct state to test a > particular property." Difficulty in unit testing OO code is best documented > in Robert Binder's tome [1], which is easily the best text on testing I've > ever read and never gets cited by bloggers and other Internet programmarazzi > (after all, who has time to read 1,500 pages on testing when you have to > maintain a blog). Moreover, you should not be mocking objects. That will > lead to a combinatorial explosion in tests and likely reveal that your > object model leaks encapsulation details (think about it). Mock the role > the object plays in the system instead; this is kind of a silly way to say > "use abstraction" but I've found most people need to hear a good idea 3 > different ways in 3 different contexts before they can apply it beyond one > playground trick. > > > 7. Difficulty in testing objects depends on how you describe object > behavior, and has nothing to do with any properties of objects as compared > with abstract data types! For example, if object actions are governed by an > event system, then to test an interaction, you simply mock the event queue > manager. This is because you've isolated your test to three variants: (A) > the state prior to an atomic action, (B) the state after that action, and > (C) any events the action generates. This is really not any more > complicated than using QuickCheck, but unfortunately most programmers are > only familiar with using xUnit libraries for unit testing and they have > subdued the concept of "unit testing" to a common API that is not > particularly powerful. Also, note earlier my dislike of the argument that > "The difficulties in unit testing OO code is coaxing objects into the > correct state to test a particular property."; under this testing > methodology, there is no "particular property" to test, since the state of > the application is defined in terms of all the object's attributes *after* > the action has been processed. It doesn't make much sense to just test one > property. It's called unit testing, not property testing. > One small update for pedagogic purposes: Testing properties is really just a form of testing called negative testing; testing that something doesn't do something it shouldn't do. The testing I covered above describes positive testing. Negative testing is always going to be difficult, regardless of how you abstract your system and what language you use. Think about it!
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
