|Oct 25, 2007||–||
Visualizing Complexity and Coverage
At CITCON Europe in Brussels last week one of the sessions I enjoyed was on CRAP4J and other metrics for bad code. (I've put my notes up on the CITCON wiki.) Today Kevin reminded me that Clover 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 here. This is a pretty neat looking approach... but honestly? I don't really like it.
|Nov 18, 2005||–||
What's the Use of Coverage
There is a discussion on the JUnit list about whether coverage tools are valuable.
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.
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.
|Feb 9, 2005||–||Failures in Unit Testing This morning on the Agile Testing mailing list someone pointed out Mike Clark's blog entry "Failures in Unit Testing". more »|
|Sep 7, 2004||–||Oozing Confidence Mike Clark writes about his visit to Agitar's office: “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.” more »|
|Sep 2, 2004||–||Pragmatic Project Automation Ever since I bought into Martin Fowler's line 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 Mike Clark for his new book, Pragmatic Project Automation. more »|
|Apr 1, 2004||–||
eXtreme Feedback for Software Development
“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.” — William Blake
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. more »
|Mar 15, 2004||–||Eating Our Own Dog Food — Using Agitator™ on Itself 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™ 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. more »|
|Feb 2, 2004||–||Selecting Developer Testing Metrics 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: more »|
|Dec 27, 2003||–||Managed Developer Testing 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. more »|