<?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: I Want a Platypus Too</title>
	<atom:link href="http://third-bit.com/blog/archives/1517.html/feed" rel="self" type="application/rss+xml" />
	<link>http://third-bit.com/blog/archives/1517.html</link>
	<description>Data is ones and zeroes &#124; Software is ones and zeroes and hard work.</description>
	<lastBuildDate>Fri, 03 Feb 2012 17:07:30 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Jan</title>
		<link>http://third-bit.com/blog/archives/1517.html#comment-1698</link>
		<dc:creator>Jan</dc:creator>
		<pubDate>Tue, 06 May 2008 10:18:59 +0000</pubDate>
		<guid isPermaLink="false">http://pyre.third-bit.com/blog/archives/1517.html#comment-1698</guid>
		<description>Testing (beyond Unit Testing) really goes hand in hand with deployment. To test a system it needs to be running in reasonably realistic environment.

However that means testing is tied to your deployment platform. If you&#039;re willing to take the hit the system can very tight like Microsoft Visual Studio Team System.

But then you have moved away from the &#039;lowest common denominator&#039; approach that is hallmark of good software.

Something that might hit a sweet spot (an idea I tried implementing for TRAC, but then the sun came out) is a unified logging system. Just like TRAC supports very handy wiki links to parts of your code. I part-build a system that allows links back from log files (presented inside TRAC&#039;s wiki system) back to the code that scribed them.

...everyone needs logging!</description>
		<content:encoded><![CDATA[<p>Testing (beyond Unit Testing) really goes hand in hand with deployment. To test a system it needs to be running in reasonably realistic environment.</p>
<p>However that means testing is tied to your deployment platform. If you&#8217;re willing to take the hit the system can very tight like Microsoft Visual Studio Team System.</p>
<p>But then you have moved away from the &#8216;lowest common denominator&#8217; approach that is hallmark of good software.</p>
<p>Something that might hit a sweet spot (an idea I tried implementing for TRAC, but then the sun came out) is a unified logging system. Just like TRAC supports very handy wiki links to parts of your code. I part-build a system that allows links back from log files (presented inside TRAC&#8217;s wiki system) back to the code that scribed them.</p>
<p>&#8230;everyone needs logging!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Greg Wilson</title>
		<link>http://third-bit.com/blog/archives/1517.html#comment-1697</link>
		<dc:creator>Greg Wilson</dc:creator>
		<pubDate>Sat, 03 May 2008 00:29:36 +0000</pubDate>
		<guid isPermaLink="false">http://pyre.third-bit.com/blog/archives/1517.html#comment-1697</guid>
		<description>@Pekka: I think there&#039;s a misunderstanding: I&#039;m not trying to test DrProject itself, I&#039;m trying to provide tools in DrProject that will help people with the testing of whatever application(s) they&#039;re using DrProject to help develop.</description>
		<content:encoded><![CDATA[<p>@Pekka: I think there&#8217;s a misunderstanding: I&#8217;m not trying to test DrProject itself, I&#8217;m trying to provide tools in DrProject that will help people with the testing of whatever application(s) they&#8217;re using DrProject to help develop.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pekka Laukkanen</title>
		<link>http://third-bit.com/blog/archives/1517.html#comment-1696</link>
		<dc:creator>Pekka Laukkanen</dc:creator>
		<pubDate>Sat, 03 May 2008 00:25:48 +0000</pubDate>
		<guid isPermaLink="false">http://pyre.third-bit.com/blog/archives/1517.html#comment-1696</guid>
		<description>Since you probably have generic interfaces (web, database, etc.) you should be able to use existing open source test tools. If your system is testable you shouldn&#039;t need much more.</description>
		<content:encoded><![CDATA[<p>Since you probably have generic interfaces (web, database, etc.) you should be able to use existing open source test tools. If your system is testable you shouldn&#8217;t need much more.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Greg Wilson</title>
		<link>http://third-bit.com/blog/archives/1517.html#comment-1695</link>
		<dc:creator>Greg Wilson</dc:creator>
		<pubDate>Fri, 02 May 2008 21:56:01 +0000</pubDate>
		<guid isPermaLink="false">http://pyre.third-bit.com/blog/archives/1517.html#comment-1695</guid>
		<description>@Pekka: I agree systems should be designed for testability; I was wondering what tools like DrProject can provide to help with the actual testing.</description>
		<content:encoded><![CDATA[<p>@Pekka: I agree systems should be designed for testability; I was wondering what tools like DrProject can provide to help with the actual testing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pekka Laukkanen</title>
		<link>http://third-bit.com/blog/archives/1517.html#comment-1694</link>
		<dc:creator>Pekka Laukkanen</dc:creator>
		<pubDate>Fri, 02 May 2008 21:48:39 +0000</pubDate>
		<guid isPermaLink="false">http://pyre.third-bit.com/blog/archives/1517.html#comment-1694</guid>
		<description>Adding support for testing mainly means making your system testable. It is surprisingly easy when you think about it before the implementation but hard to do after the fact. For web systems it is often enough to add clear and non-changing identifiers for all your widgets (including labels). I recommend reading Bret Pettichord&#039;s excellent paper Design for Testability for more information. You can get it from http://www.io.com/%7Ewazmo/papers/design_for_testability_PNSQC.pdf</description>
		<content:encoded><![CDATA[<p>Adding support for testing mainly means making your system testable. It is surprisingly easy when you think about it before the implementation but hard to do after the fact. For web systems it is often enough to add clear and non-changing identifiers for all your widgets (including labels). I recommend reading Bret Pettichord&#8217;s excellent paper Design for Testability for more information. You can get it from <a href="http://www.io.com/%7Ewazmo/papers/design_for_testability_PNSQC.pdf" rel="nofollow">http://www.io.com/%7Ewazmo/papers/design_for_testability_PNSQC.pdf</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>

