<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
<channel>
<title>Developer Testing: Managed Developer Testing</title>
<link>http://www.developertesting.com/</link>
<description>Developer Testing - A place to gain and share knowledge.</description>
<copyright>Copyright 2008</copyright>
<lastBuildDate>Thu, 25 Oct 2007 13:12:30 -0800</lastBuildDate>
<generator>http://www.movabletype.org/?v=3.16</generator>
<docs>http://blogs.law.harvard.edu/tech/rss</docs> 

" lastn="15">
<item>
<title>Visualizing Complexity and Coverage</title>
<description><![CDATA[<p>At <a href="http://www.citconf.com/">CITCON</a> Europe in Brussels last week one of the sessions I enjoyed was on CRAP4J and other metrics for bad code. (I've put <a href="http://www.citconf.com/wiki/index.php?title=Crap4J_and_other_metric_tools">my notes</a> up on the CITCON wiki.) Today Kevin reminded me that <a href="http://www.atlassian.com/software/clover/">Clover</a> has a similar metric for identifying risky code, a tag cloud that uses complexity to size the tag and the coverage level to color it. They have posted a sample using Lucene <a href="http://downloads.atlassian.com/software/clover/samples/lucene/project-risks.html">here</a>. This is a pretty neat looking approach... but honestly? I don't really like it.<br />
</p>]]></description>
<link>http://www.developertesting.com/archives/month200710/20071025-VisualizingComplexityAndCoverage.html</link>
<guid>http://www.developertesting.com/archives/month200710/20071025-VisualizingComplexityAndCoverage.html</guid>
<category>Jeffrey Fredrick</category>
<pubDate>Thu, 25 Oct 2007 13:12:30 -0800</pubDate>

</item>
" lastn="15">
<item>
<title>What&apos;s the Use of Coverage</title>
<description><![CDATA[<p>There is a discussion on the <a href="http://groups.yahoo.com/group/junit/">JUnit list</a> about whether coverage tools are valuable. </p>

<p>I ran a coverage tool on a project of mine last night and found that almost all the coverage gaps were in boilerplate code. An interface required me to return false in a whole bunch of classes. </p>

<p>The duplication was already bothering me. The duplication plus coverage gaps bothered me enough to extract a common base class. Coverage was back up to almost 100% and I liked the new design better.</p>

<p>Go figure.</p>]]></description>
<link>http://www.developertesting.com/archives/month200511/20051118-WhatsTheUseOfCoverage.html</link>
<guid>http://www.developertesting.com/archives/month200511/20051118-WhatsTheUseOfCoverage.html</guid>
<category>Kevin Lawrence</category>
<pubDate>Fri, 18 Nov 2005 14:16:34 -0800</pubDate>

</item>
" lastn="15">
<item>
<title>Failures in Unit Testing</title>
<description><![CDATA[This morning on the <a href="http://groups.yahoo.com/group/agile-testing/">Agile Testing mailing list</a> someone pointed out Mike Clark's blog entry <a href="http://www.clarkware.com/cgi/blosxom/2005/02/08#ADTUnitTesting">"Failures in Unit Testing"</a>.]]></description>
<link>http://www.developertesting.com/archives/month200502/20050209-FailuresInUnitTesting.html</link>
<guid>http://www.developertesting.com/archives/month200502/20050209-FailuresInUnitTesting.html</guid>
<category>Jeffrey Fredrick</category>
<pubDate>Wed, 09 Feb 2005 10:48:00 -0800</pubDate>

</item>
" lastn="15">
<item>
<title>Oozing Confidence</title>
<description><![CDATA[<a href="http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Monitor/Devices/OozingConfidence.rdoc">Mike Clark writes</a> about his visit to Agitar's office: &ldquo;I got an opportunity to visit Alberto's project a few weeks back and witness first-hand those infamous lava lamps. You really can't miss them. When I walked in, the red lamp was bubbling. And yet the managers weren't beating the programmers about the head and shoulders, as some might fear. Indeed, I didn't sense any sort of panic or condescension. What I did sense was confidence.&rdquo;]]></description>
<link>http://www.developertesting.com/archives/month200409/20040907-OozingConfidence.html</link>
<guid>http://www.developertesting.com/archives/month200409/20040907-OozingConfidence.html</guid>
<category>Managed Developer Testing</category>
<pubDate>Tue, 07 Sep 2004 18:42:51 -0800</pubDate>

</item>
" lastn="15">
<item>
<title>Pragmatic Project Automation</title>
<description><![CDATA[Ever since I bought into Martin Fowler's <a href="http://www.martinfowler.com/articles/continuousIntegration.html#N100F5">line</a> that "Imperfect tests, run frequently, are much better than perfect tests that are never written at all" I've had the ideas of developer testing and automation inexorably linked in my mind. And of course like any sort of believer I'm always on the lookout for tools to help convince and convert my more reluctant friends. How thankful I am then to <a href="http://www.clarkware.com/">Mike Clark</a> for his new book,  <a href="http://www.pragmaticprogrammer.com/starter_kit/au/">Pragmatic Project Automation</a>.]]></description>
<link>http://www.developertesting.com/archives/month200409/20040902-PragmaticProjectAutomation.html</link>
<guid>http://www.developertesting.com/archives/month200409/20040902-PragmaticProjectAutomation.html</guid>
<category>Jeffrey Fredrick</category>
<pubDate>Thu, 02 Sep 2004 14:37:50 -0800</pubDate>

</item>
" lastn="15">
<item>
<title>eXtreme Feedback for Software Development</title>
<description><![CDATA[&ldquo;<i>The road of excess leads to the palace of wisdom ... for we never know what is enough until we know what is more than enough.</i>&rdquo;&nbsp;&mdash;&nbsp;William Blake<br />
<br />
One of the main themes of eXtreme Programming (XP) is that if an activity is beneficial and worth doing, it should be done to the extreme. If testing is a good thing, for example, we should be testing all the time; in XP this translates to customers doing functional testing and developers writing lots of unit tests and running them several times a day - even several times in a 10-minute period in the most extreme cases.]]></description>
<link>http://www.developertesting.com/archives/month200404/20040401-eXtremeFeedbackForSoftwareDevelopment.html</link>
<guid>http://www.developertesting.com/archives/month200404/20040401-eXtremeFeedbackForSoftwareDevelopment.html</guid>
<category>Alberto Savoia</category>
<pubDate>Thu, 01 Apr 2004 07:48:28 -0800</pubDate>

</item>
" lastn="15">
<item>
<title><![CDATA[Eating Our Own Dog Food &mdash; Using Agitator&trade; on Itself]]></title>
<description><![CDATA[In start-up companies, especially in the area of software, the expression "eat your own dog food" means that you should use in-house the products or service that you are planning to sell to other people. At Agitar we take eating our own dog food very seriously. One of the first things I did when we founded the company was to buy a can of Alpo&trade; dog food for everyone in engineering and put it on their desks to remind them how important it is for us to be users of our own technology.]]></description>
<link>http://www.developertesting.com/archives/month200403/20040315-EatingOurOwnDogFood.html</link>
<guid>http://www.developertesting.com/archives/month200403/20040315-EatingOurOwnDogFood.html</guid>
<category>Alberto Savoia</category>
<pubDate>Mon, 15 Mar 2004 14:47:41 -0800</pubDate>

</item>
" lastn="15">
<item>
<title>Selecting Developer Testing Metrics</title>
<description>The first step in deciding what metrics to use is to specify clearly what results we want to achieve and what behaviors we want to encourage. In the context of developer testing, the results and behaviors that most organizations should target are the following:</description>
<link>http://www.developertesting.com/archives/month200402/20040202-SelectingDeveloperTestingMetrics.html</link>
<guid>http://www.developertesting.com/archives/month200402/20040202-SelectingDeveloperTestingMetrics.html</guid>
<category>Alberto Savoia</category>
<pubDate>Mon, 02 Feb 2004 21:33:49 -0800</pubDate>

</item>
" lastn="15">
<item>
<title>Managed Developer Testing</title>
<description>This Developer Testing Note introduces the concept of Managed Developer Testing, a set of management practices supported by automated tools which I believe are essential to make a developer testing effort successful.</description>
<link>http://www.developertesting.com/archives/month200312/20031227-ManagedDeveloperTesting.html</link>
<guid>http://www.developertesting.com/archives/month200312/20031227-ManagedDeveloperTesting.html</guid>
<category>Alberto Savoia</category>
<pubDate>Sat, 27 Dec 2003 21:17:43 -0800</pubDate>

</item>


</channel>
</rss>