Friday, December 12, 2008

Test Lookup

Kris Kemper has a nice blog entry on finding tests related to code you are changing that lines up well with a concept I've been pondering today.

I have a colleague who asked me to look over a rather large C# software system, made up of many (>20) .NET projects. In the best agile way, he is relying on his elegant structure and well-named/concise tests to serve as the documentation for anyone who might try to understand the code.

Being self-aware, my colleague understands that he is too close to the subject to be able to determine "understandability" of the code by others. So he asked me - an outsider - to take a look. I think he was also hoping that if I - as a supposedly post-technical project manager - could understand it then he could brag that his code was so understandable that "even a PM can understand it". (Reminds me of those old Life cereal commercial where Mikey, who never likes anything, likes the cereal and his siblings declare "Even Mikey likes it !")

So I picked a class at random. Nice short methods, but reading the code didn't give me as much insight as I hoped. Then I thought... ah the tests. I'll read the tests. So I right clicked, searched for usages, and navigated to the location that had "unittests" in the name. Then I thought - wouldn't it be nice if I could right click on a method name, or a class name, and - instead of asking for usages - I could ask for tests.

That got me to thinking - what would constitute a test? A unit test that simply invokes a method or instantiates a class may just be using it for setup or for supporting scaffolding. But then wouldn't that be a smell? Shouldn't that irrelevant setup junk be in a setup, or injected or...

Anyway, Kris gets to much of these points... my main extending thought is simply - wouldn't it be nice if the tools could help us navigate to tests and sniff out those smells (rather than force them by removing the method, as Kris's technique suggests)?

2 comments:

Kris said...

I don't know of any tool that does what you want. It would be easy to do in ruby, since I can record the exact lines the execute. It could probably be done in java using aspects or some reflection calls.

The only bad thing that I would imagine is that it would slow the build down quite a bit if you collect that information at that time.

Doing it in a regular build would give the most up to date information, but if it did slow it down, it could be run in a seperate pipeline from the regular dev checkin.

Sidu said...

Old hat :)
Ctrl + Shift + T (IntelliJ Idea + Testdox, Java)
Ctrl + Shift + Down Arrow (TextMate + RSpec bundle, Ruby)

I tried taking a shot at implementing this on VS2008, but it has the most gods-awful plugin API ever. Perhaps the Re-Sharper API would be better suited?