<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Unit testing interface implementations</title>
	<atom:link href="http://blog.paulmoser.co.uk/index.php/2007/02/25/unit-testing-interface-implementations/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.paulmoser.co.uk/index.php/2007/02/25/unit-testing-interface-implementations/</link>
	<description>So much to learn but so little time</description>
	<lastBuildDate>Fri, 26 Dec 2008 01:15:09 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Contract Tests with TestNG: update</title>
		<link>http://blog.paulmoser.co.uk/index.php/2007/02/25/unit-testing-interface-implementations/comment-page-1/#comment-12740</link>
		<dc:creator>Contract Tests with TestNG: update</dc:creator>
		<pubDate>Fri, 22 Aug 2008 23:00:01 +0000</pubDate>
		<guid isPermaLink="false">http://blog.paulmoser.co.uk/index.php/2007/02/25/unit-testing-interface-implementations/#comment-12740</guid>
		<description>[...] functionality of abstract classes works properly in all concrete subclasses. Certainly this has been mentioned before, generally under the name Abstract Tests or Contract Tests. Also, the idea seems [...]</description>
		<content:encoded><![CDATA[<p>[...] functionality of abstract classes works properly in all concrete subclasses. Certainly this has been mentioned before, generally under the name Abstract Tests or Contract Tests. Also, the idea seems [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ilya Bobir</title>
		<link>http://blog.paulmoser.co.uk/index.php/2007/02/25/unit-testing-interface-implementations/comment-page-1/#comment-6608</link>
		<dc:creator>Ilya Bobir</dc:creator>
		<pubDate>Sat, 15 Dec 2007 07:31:51 +0000</pubDate>
		<guid isPermaLink="false">http://blog.paulmoser.co.uk/index.php/2007/02/25/unit-testing-interface-implementations/#comment-6608</guid>
		<description>It constantly gives me an error.  Please check the server logs. =)</description>
		<content:encoded><![CDATA[<p>It constantly gives me an error.  Please check the server logs. =)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ilya Bobir</title>
		<link>http://blog.paulmoser.co.uk/index.php/2007/02/25/unit-testing-interface-implementations/comment-page-1/#comment-6607</link>
		<dc:creator>Ilya Bobir</dc:creator>
		<pubDate>Sat, 15 Dec 2007 07:30:11 +0000</pubDate>
		<guid isPermaLink="false">http://blog.paulmoser.co.uk/index.php/2007/02/25/unit-testing-interface-implementations/#comment-6607</guid>
		<description>For some reason I can not submit the rest of my post :(</description>
		<content:encoded><![CDATA[<p>For some reason I can not submit the rest of my post <img src='http://blog.paulmoser.co.uk/wp-includes/images/smilies/icon_sad.gif' alt=':(' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ilya Bobir</title>
		<link>http://blog.paulmoser.co.uk/index.php/2007/02/25/unit-testing-interface-implementations/comment-page-1/#comment-6606</link>
		<dc:creator>Ilya Bobir</dc:creator>
		<pubDate>Sat, 15 Dec 2007 07:26:48 +0000</pubDate>
		<guid isPermaLink="false">http://blog.paulmoser.co.uk/index.php/2007/02/25/unit-testing-interface-implementations/#comment-6606</guid>
		<description>Suites can be connected to form a tree.  A suite for the interface contract can be added as a child to the suite that tests the class.

About telling which implementation of the interface to test, it is quite easy with JUint 3 where you are creating suites yourself.  You can just add a method to the suite that will take an implementation factory and will propagate it into all contained tests.  Then you need to do a call to supply the factory in addition to attaching the interface test suite as a child to your class test suite.</description>
		<content:encoded><![CDATA[<p>Suites can be connected to form a tree.  A suite for the interface contract can be added as a child to the suite that tests the class.</p>
<p>About telling which implementation of the interface to test, it is quite easy with JUint 3 where you are creating suites yourself.  You can just add a method to the suite that will take an implementation factory and will propagate it into all contained tests.  Then you need to do a call to supply the factory in addition to attaching the interface test suite as a child to your class test suite.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul</title>
		<link>http://blog.paulmoser.co.uk/index.php/2007/02/25/unit-testing-interface-implementations/comment-page-1/#comment-6576</link>
		<dc:creator>Paul</dc:creator>
		<pubDate>Wed, 12 Dec 2007 20:14:00 +0000</pubDate>
		<guid isPermaLink="false">http://blog.paulmoser.co.uk/index.php/2007/02/25/unit-testing-interface-implementations/#comment-6576</guid>
		<description>I can&#039;t comment on how well this works in practice as since I wrote the post I&#039;ve been working solely with Ruby.

In the past I&#039;ve alway tried to avoid suites as test cases inevitable accidentally get left out however in this case either way you&#039;d have  to remember to add an entry to something, either the suite or the interface testcase.

As I&#039;ve not used suites much I&#039;m not sure how  go about telling the generic test which implementation of  the interface to test, or I may have misunderstood what you meant.

One other small benefit that has just come to mind of having all the implementations of an interface listed in the test for the interface is that if you change the interface you just need to run the test for it to discover which classes are broken rather than having to remove all compiled class files and compiling everything to pick up which classes were dependent on the interface.</description>
		<content:encoded><![CDATA[<p>I can&#8217;t comment on how well this works in practice as since I wrote the post I&#8217;ve been working solely with Ruby.</p>
<p>In the past I&#8217;ve alway tried to avoid suites as test cases inevitable accidentally get left out however in this case either way you&#8217;d have  to remember to add an entry to something, either the suite or the interface testcase.</p>
<p>As I&#8217;ve not used suites much I&#8217;m not sure how  go about telling the generic test which implementation of  the interface to test, or I may have misunderstood what you meant.</p>
<p>One other small benefit that has just come to mind of having all the implementations of an interface listed in the test for the interface is that if you change the interface you just need to run the test for it to discover which classes are broken rather than having to remove all compiled class files and compiling everything to pick up which classes were dependent on the interface.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ilya Bobir</title>
		<link>http://blog.paulmoser.co.uk/index.php/2007/02/25/unit-testing-interface-implementations/comment-page-1/#comment-6568</link>
		<dc:creator>Ilya Bobir</dc:creator>
		<pubDate>Wed, 12 Dec 2007 01:27:40 +0000</pubDate>
		<guid isPermaLink="false">http://blog.paulmoser.co.uk/index.php/2007/02/25/unit-testing-interface-implementations/#comment-6568</guid>
		<description>Don&#039;t you think that enumerating all the interface implementations in the interface test is a bit wrong?
It seems to me it would be more correct to have some kind of a generic test suite that tests the interface contract and use it as a part of a test suite for each implementation.</description>
		<content:encoded><![CDATA[<p>Don&#8217;t you think that enumerating all the interface implementations in the interface test is a bit wrong?<br />
It seems to me it would be more correct to have some kind of a generic test suite that tests the interface contract and use it as a part of a test suite for each implementation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Screened Twenty</title>
		<link>http://blog.paulmoser.co.uk/index.php/2007/02/25/unit-testing-interface-implementations/comment-page-1/#comment-1146</link>
		<dc:creator>Screened Twenty</dc:creator>
		<pubDate>Tue, 22 May 2007 00:22:37 +0000</pubDate>
		<guid isPermaLink="false">http://blog.paulmoser.co.uk/index.php/2007/02/25/unit-testing-interface-implementations/#comment-1146</guid>
		<description>Hello

We&#039;ve got a non-profit site here with an article on Unit Testing in general, located at: http://coderslog.com/Unit_Testing_101

Hoping to get examples on there soon. The site itself is a journal of common code/configurations and other hard to find information. Should come in handy for building high performance large scale java applications and such.</description>
		<content:encoded><![CDATA[<p>Hello</p>
<p>We&#8217;ve got a non-profit site here with an article on Unit Testing in general, located at: <a href="http://coderslog.com/Unit_Testing_101" rel="nofollow">http://coderslog.com/Unit_Testing_101</a></p>
<p>Hoping to get examples on there soon. The site itself is a journal of common code/configurations and other hard to find information. Should come in handy for building high performance large scale java applications and such.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
