Posts Tagged ‘ Tools ’

Is 100% test coverage a BAD thing?

I’m a huuuge advocate of TDD and high test coverage, and I will often go to great lengths to ensure this, but is 100% such a good thing?

I recently heard Tim Lister talking about risk in software projects and the CMM (powerpoint slides).

The ‘ultimate’ level of CMM ensure that everything is documented, everything goes through a rigorous procedure, blah blah blah. Amusingly, Tim pointed out that no CEO in their right mind would ever want their organization to be like that as they would not be effectively managing risk. You only need this extra stuff when you actually need this extra stuff. If there’s little risk, then this added process adds a lot of cost with no real value – you’re just pissing away money.

This also applies for test coverage. There are always going to be untested parts of your system but when increasing the coverage you have to balance the cost with the value.

With test coverage, you get the value of higher quality software that’s easier to change, but it follows the Law of diminishing returns. The effort required to get from 99% to 100% is huge… couldn’t that be spent on something more valuable like adding business functionality or simplifying the system?

Personally, I’m most comfortable with coverage in the 80-90% region, but your mileage may vary.

2004
10/07
CATEGORY
Software
TAGS


7 comments

REST and FishEye

The latest version of FishEye now has a REST API (oh and an XML-RPC API too, which is less interesting).

I’m happy partly because FishEye is a great tool and this will allow integration with other tools – things we are seeing more and more with its natural friends like JIRA, DamageControl and Confluence.

But what I’m really glad to see is that they made the decision to go with REST rather than just stick with the usual suspects SOAP or XML-RPC. Looking at the actual API for FishEye, REST seems like a no-brainer as all of the calls are queries.

On the last system I worked on, we were struggling with SOAP and switched to a simpler REST approach. It had a number of benefits.

Firstly, it simplified things greatly. With REST there was no need for complicated SOAP libraries on either the client or server, just use a plain HTTP call. This reduced coupling and brittleness. We had previously lost hours (possibly days) tracing problems through libraries that were outside of our control.

Secondly, it improved scalability. Though this was not the reason we moved, it was a nice side-effect. The web-server, client HTTP library and any HTTP proxy in-between understood things like the difference between GET and POST and when a resource has not been modified so they can offer effective caching – greatly reducing the amount of traffic. This is why REST is a more scalable solution than XML-RPC or SOAP over HTTP.

Thirdly, it reduced the payload over the wire. No need for SOAP envelope wrappers and it gave us the flexibility to use formats other than XML for the actual resource data. For instance a resource containing the body of an unformatted news headline is simpler to express as plain text and a table of numbers is more concise (and readable) as CSV.

REST is something I hadn’t really considered until recently and is by no means a golden-hammer, but in our case it worked out better than SOAP and XML-RPC.

2004
09/17
CATEGORY
Software
TAGS

2 comments

How to host your own private CVS repository

Here’s a quick way to host your own remote private CVS repository, accessible via SSH.

All you need is an SSH enabled shell account on a UNIX box that has the CVS client installed. If the box doesn’t have a cvs client installed, you should be able to download a binary (or compile source) and place it in your local path. If you have webspace somewhere, chances are you’ve got everything you need.

Assuming, the server is foo.myserver.com, your username is myuser and your home dir on that server is /home/myuser, here are the steps:

* SSH to foo.myserver.com
* mkdir /home/myuser/cvsroot
* cvs -d /home/myuser/cvsroot init

Now, you can access your private CVS repository from anywhere using the CVSROOT :ext:myuser@foo.myserver.com:/home/myuser/cvsroot.

2004
05/25
CATEGORY
Geek
Software
TAGS
2 comments

Making JUnit friendlier to AgileDox

Here’s a little trick to make JUnit display your test results in a similar way to AgileDox.

Override TestCase.getName() in your unit test…

public String getName() {
return super.getName().substring(4).replaceAll("([A-Z])", " $1").toLowerCase();
}

… and your test runner results are transformed from this …

… to this …

To make this easier, stick it in an abstract TestCase and inherit from that instead.

2004
01/30
CATEGORY
Software
TAGS



12 comments

Toywatch: Whiteboard Photo

Mike Brown pointed me to Whiteboard Photo – a simple little tool for converting crappy photos of whiteboards into something usable. It even distorts the image to compensate for the perspective the photo was taken at.

!http://www.websterboards.com/media/products/BeforeAfter.jpg!

A mere $249 – good value for money.

2003
07/31
CATEGORY
Geek
Software
TAGS

3 comments

Agiledox

Chris Stevenson, fellow team-member, has started Agiledox, a small project to collect ideas and tools for automating documentation.

It is typical in agile projects that the code and design changes so quickly that the documentation (if any) never keeps up. We are using Agiledox on our current project to help give us all a high-level map of what the system does at all times.

When practicing *collective code ownership* it is vital that all developers know how the entire system works, not just _their_ bit (they have no bit). With bigger systems that are constantly evolving it is unlikely that any one person knows how it all works, so it’s nice to have a higher level roadmap of the system to look around before drilling into some code. Of course, this is no substitute for good communication – but it helps.

The first deliverabe in Agiledox is Testdox . It autogenerates documentation from testcases. Wow! How?

Simple. All it does is look at a test class and all the test method names and convert them from camal case Java names to sentences. Genius!

You may laugh, as I did. But I was amazed at what it produced for our project.

There’s a catch though. It worked for us because we are well disciplined in the way we write tests. For a start, we were already in the habit of writing test case method names that describe what a class should _do_ rather than what all the methods are. Don’t moan that this low emission petrol isn’t great when you’re trying to put it in a deisel engine.

Run Testdox through WebStart.

Here’s a handful of docs generated for our project. Sweet huh?

h3. MenuModel

* View can be bound to a model
* Two views can be bound to one model
* Model contains menu text
* Model contains menu text after it is renamed
* View is populated from prepopulated model
* Model can be cleared
* Model can contain separator

h3. CsvTableModel

* Column definitions are read from first row
* Values can be read from rows
* Column definition values return underlying value
* Model can be reloaded
* Column can be marked as date

h3. NewOrderFinder

* Order with fills are returned
* Old orders and old fills are filtered out
* Old orders with new fills are not filtered out
* Assumed legs are filtered out
* Last check is maintained
* Spread components are grouped together

2003
06/18
CATEGORY
Software
TAGS




Comments Off on Agiledox