« Why I Always Ask To See Code | Main | Language of the year: 2010 »

December 28, 2009

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00e54fb013da88340128768b1553970c

Listed below are links to weblogs that reference Contract Tests in JUnit 4:

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Chris Vest

Do you prefer this inheritance based scheme to jUnit Theories?

Oleg

Great example, thank you.

One off topic question - what plug-in do you use to run tests? I like the way its UI is minimized at the bottom of workspace. Also it looks like it's able to run only changed tests, right?

Ben Rady

Oleg,

The plug-in used to run the tests in this screencast is called Infinitest.

http://improvingworks.com/products/infinitest/

It not only runs changed tests, but selects an optimized subset of tests to run based on what you've changed (a feature not particularly apparent in a simple example like this). It's available with both a free and commercial license.

Ben Rady


Using JUnit theories for something like this seems to me like it would violate the Open-Closed Principle, because in order to test a new type of list, youd have to go into the test and change it to include the new type.

Is there a way to use theories for this that doesnt suffer from that problem?

Jens Dietrich

Interesting. I had a related problem where I had to write abstract contract tests but the classes to be tested only become known at runtime (through dependency injection). I ended up writing my own test runner that works with test classes that have a constructor with one parameter, like MyTest(List). I.e., the actual object to be tested is passed to the test case when it is instantiated. If you are interested, the project is treaty: http://code.google.com/p/treaty/, the respective code can be seen here:
http://code.google.com/p/treaty/source/browse/tags/release2.1.1/treaty-eclipse-voc-junit/src/net/java/treaty/eclipse/vocabulary/junit/TestRunner.java

Emerson Farrugia

(I haven't watched Rainsberger's presentation yet, so maybe this question is addressed in there. Apologies if it is.)

The problem with making test classes inherit from one another is that you're limited by single inheritance. Say you've got a FileRepository class and a ReadableRepository interface, and you've written test classes for both. A ReadableFileRepository extends FileRepository and implements ReadableRepository. Is there a simple way to write a test class containing ReadableFileRepository specific tests, which also runs the test cases for FileRepository and ReadableRepository?

Thanks,
Emerson

The comments to this entry are closed.