This post originated from an RSS feed registered with Java Buzz by Carlos Perez. Original Post: Liskov's Substitution Principle and JUnit Testing Feed Title: .:Manageability:. Feed URL: http://www.manageability.org/blog/stuff/rssDisabled?portal_status_message=Syndication+is+Disabled Feed Description: Random thoughts on the manageability of complex software. Latest Java Buzz Posts Latest Java Buzz Posts by Carlos Perez Latest Posts From .:Manageability:.

I guess we have all heard about Liskov's Substitution Principle?  Well if you haven't, here's a reference and the take on that principle:

FUNCTIONS THAT USE POINTERS OR REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT

So if I were to apply it to unit testing the it should be pretty simple.  If I got a test that tests a base class or an interface, then that same test should work with any subclass or implementor of the interface.  That's just plain obvious, but here's a question "How do you build reusable JUnit tests that exploit the Liskov principle?".  In other words, I don't want to have to rewrite the same tests for subclasses and implementors.

Fortunately, I don't have to expend any brain power on this.  That's because the folks (I think it's Adam Murdoch) who put together the Commons VFS project have a ingenious setup going.  VFS is an abstract api that works across different kinds of file systems like FTP, JARs, SMB, WebDav and the like.  What they developed was a test harness based on JUnit to test all the different implementations without having to rewrite all the tests for each implementation.

I'll try to give you a quick summary, but you'll need to read the code to get more detail.  He's got organized a set of tests classes that are supposed to work across all implementions for like testing for URI, Naming, Content, Read, Write, and URL .  What's done is all the individual test methods are collected by the ProviderTestSuite class, this TestSuite is configured with a different ProviderConfig for each implementation.  There's even some negotiation as to what capabilities are to should be tested for or not. It's just too cool!

Definitely a must read for any serious "Test Infected" practitioner. Matter of fact is so good that the test harness itself should have its very own Apache project!

[update] Some people may wonder, "Can't I just subclass the TestCase?". This framework allows you to reuse multiple TestCases without having to subclass from each and every one of them.  The framework would be most applicable for interfaces where it's common to implement multiple interfaces.