[Haskell-cafe] Type System vs Test Driven Development

[John Zabroski]

On Wed, Jan 5, 2011 at 6:41 PM, John Zabroski <johnzabroski at 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110105/a70674da/attachment.htm>