On Wed, Jan 5, 2011 at 6:41 PM, John Zabroski <johnzabroski@gmail.com> 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!