<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Software is too expensive to build cheaply... &#187; testing</title>
	<atom:link href="http://twasink.net/blog/tags/testing/feed/" rel="self" type="application/rss+xml" />
	<link>http://twasink.net/blog</link>
	<description>Robert's Rambling Ruminations Regarding Reality</description>
	<lastBuildDate>Fri, 16 Jul 2010 06:57:24 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>RSpec, JRuby and Story Testing Java Code</title>
		<link>http://twasink.net/blog/2008/02/rspec-jruby-and-story-testing-java-code/</link>
		<comments>http://twasink.net/blog/2008/02/rspec-jruby-and-story-testing-java-code/#comments</comments>
		<pubDate>Wed, 13 Feb 2008 00:37:05 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[Ruby]]></category>
		<category><![CDATA[bdd]]></category>
		<category><![CDATA[rspec]]></category>
		<category><![CDATA[story testing]]></category>
		<category><![CDATA[testing]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=215</guid>
		<description><![CDATA[I&#8217;ve long been interested in decent ways of expressing tests in a human-readable format. Not just any humans, but BAs and business reps in particular &#8211; the kind of people who will not be interested in slugging through piles of language syntax. I tried Fit sometime ago, and was impressed, but when I came back [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2008/02/rspec-jruby-and-story-testing-java-code/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Testing EJBs without a container</title>
		<link>http://twasink.net/blog/2007/01/testing-ejbs-without-a-container/</link>
		<comments>http://twasink.net/blog/2007/01/testing-ejbs-without-a-container/#comments</comments>
		<pubDate>Sun, 28 Jan 2007 07:57:49 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[ejb]]></category>
		<category><![CDATA[testing]]></category>
		<category><![CDATA[unit testing]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=205</guid>
		<description><![CDATA[One of the more annoying aspects of testing EJBs has always been the fact you need to bundle them up in a JAR (and often an EAR) and deploy them to a server to thoroughly test them. This process drags out the development of unit tests, and makes life generally painful.
As of EJB 3, however, [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2007/01/testing-ejbs-without-a-container/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Interfaces with EJB3</title>
		<link>http://twasink.net/blog/2007/01/interfaces-with-ejb3/</link>
		<comments>http://twasink.net/blog/2007/01/interfaces-with-ejb3/#comments</comments>
		<pubDate>Sat, 27 Jan 2007 21:54:49 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[coding standards]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[ejb]]></category>
		<category><![CDATA[patterns]]></category>
		<category><![CDATA[testing]]></category>
		<category><![CDATA[wotif]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=204</guid>
		<description><![CDATA[Starting last October, we went through a process of upgrading the main application at Wotif to be running under Java EE 5 (not just Java SE 5). The biggest part of this was upgrading from EJB 2 to EJB 3.
One of the things I noticed was that EJB3 gives you a lot of choices for [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2007/01/interfaces-with-ejb3/feed/</wfw:commentRss>
		<slash:comments>8</slash:comments>
		</item>
		<item>
		<title>JBR&#8217;s Postulate 1</title>
		<link>http://twasink.net/blog/2005/09/jbrs-postulate-1/</link>
		<comments>http://twasink.net/blog/2005/09/jbrs-postulate-1/#comments</comments>
		<pubDate>Fri, 02 Sep 2005 07:22:01 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[testing]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=162</guid>
		<description><![CDATA[From the JUnit mailing list, courtesy of J.B &#34;JUnit Recipies&#34; Rainsberger
JBR&#8217;s postulate 1. For every testable design that requires exposing elements &#8220;just for testing&#8221;, there exists an equivalent testable design that does not require exposing elements &#8220;just for testing&#8221;.
]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/09/jbrs-postulate-1/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>It&#8217;s a bird, it&#8217;s a plane&#8230; it&#8217;s a super call?</title>
		<link>http://twasink.net/blog/2005/08/its-a-bird-its-a-plane-its-a-super-call/</link>
		<comments>http://twasink.net/blog/2005/08/its-a-bird-its-a-plane-its-a-super-call/#comments</comments>
		<pubDate>Fri, 12 Aug 2005 07:27:06 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[junit]]></category>
		<category><![CDATA[patterns]]></category>
		<category><![CDATA[testing]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=156</guid>
		<description><![CDATA[Martin Fowler wrote about the Call Super smell. This occurs when you are allowed to override a method in a parent class, but you must (as opposed to can) call the parent implementation in your method.

As Martin says, this is a code smell. Why? Because it&#8217;s easy to forget, and if you forget it, you [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/08/its-a-bird-its-a-plane-its-a-super-call/feed/</wfw:commentRss>
		<slash:comments>8</slash:comments>
		</item>
		<item>
		<title>Text files, test data, and the Jakarta Commons BeanUtils</title>
		<link>http://twasink.net/blog/2005/07/text-files-test-data-and-the-jakarta-commons-beanutils/</link>
		<comments>http://twasink.net/blog/2005/07/text-files-test-data-and-the-jakarta-commons-beanutils/#comments</comments>
		<pubDate>Sun, 31 Jul 2005 21:41:43 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[testing]]></category>
		<category><![CDATA[tip]]></category>
		<category><![CDATA[toolbag]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=154</guid>
		<description><![CDATA[Earlier, I wrote about testing only one thing at a time. A little one-liner I tossed out in that was using text files to load object graphs in your test cases. I thought I&#8217;d elaborate on that a bit more.

The technique I use here is based heavily off the Jakarta Commons Bean Utils package. If [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/07/text-files-test-data-and-the-jakarta-commons-beanutils/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Testing pattern: don&#8217;t test too much at once</title>
		<link>http://twasink.net/blog/2005/07/testing-pattern-dont-test-too-much-at-once/</link>
		<comments>http://twasink.net/blog/2005/07/testing-pattern-dont-test-too-much-at-once/#comments</comments>
		<pubDate>Thu, 28 Jul 2005 22:59:11 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[economics]]></category>
		<category><![CDATA[patterns]]></category>
		<category><![CDATA[testing]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=152</guid>
		<description><![CDATA[This has been said before, I know, but it&#8217;s worth re-iterating: a test should test one thing, and one thing only.
First, some scope definition. Using Kent Beck&#8217;s terminology, I&#8217;m talking about developer tests, not acceptance tests. Also, by one thing, I mean that there should be only one thing that breaks the test (which is [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/07/testing-pattern-dont-test-too-much-at-once/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Testing patterns: don&#8217;t assert without cause</title>
		<link>http://twasink.net/blog/2005/05/testing-patterns-dont-assert-without-cause/</link>
		<comments>http://twasink.net/blog/2005/05/testing-patterns-dont-assert-without-cause/#comments</comments>
		<pubDate>Mon, 30 May 2005 11:01:48 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[patterns]]></category>
		<category><![CDATA[testing]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=142</guid>
		<description><![CDATA[One thing that I see a lot of with JUnit tests are &#8220;cascade failures&#8221;. That is, one change causes lots of tests to break. This is often (not always) associated with tests that assert things they shouldn&#8217;t.

To quote the JUnit cookbook
bq. In the case of an unsuccessful test JUnit reports the failed tests in a [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/05/testing-patterns-dont-assert-without-cause/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Learn in the quiet times</title>
		<link>http://twasink.net/blog/2005/05/learn-in-the-quiet-times/</link>
		<comments>http://twasink.net/blog/2005/05/learn-in-the-quiet-times/#comments</comments>
		<pubDate>Fri, 13 May 2005 22:33:45 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[learning]]></category>
		<category><![CDATA[testing]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=139</guid>
		<description><![CDATA[I had a comment lodged on an older article recently. The poster was complaining about the poor quality of the JWebFit sub-project of JWebUnit In particular, he was complaining about how it meant their project wasn&#8217;t delivered on time. There&#8217;s an anti-pattern here.

First, I&#8217;ll acknowledge that the JWebFit documentation is very poor. In fact, I [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/05/learn-in-the-quiet-times/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Differences cause problems</title>
		<link>http://twasink.net/blog/2005/03/differences-cause-problems/</link>
		<comments>http://twasink.net/blog/2005/03/differences-cause-problems/#comments</comments>
		<pubDate>Mon, 07 Mar 2005 16:45:07 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[testing]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=115</guid>
		<description><![CDATA[This is obvious, but differences between environments cause problems. You can expect bugs to cluster around them.

Case in point: on my current project, we use a hand-maintained schema for production (and manual testing), but our unit tests go against one that is generated from the Hibernate schema. Naturally, we are seeing bugs related to differences [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/03/differences-cause-problems/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
	</channel>
</rss>
