chris clarke

Using an SVN client with Team Foundation Server

chris.probably — Fri, 16 Nov 2007 18:52:37 +0000

Tim Goodwin blogs about SvnBridge. Its a tool for being able to use Subversion clients with Team Foundation Server. I quite like the idea of creating good interfaces to bad systems, however it would be much easier if people stopped making bad systems.

Mocking Concrete Classes in JMock 2

chris.probably — Thu, 15 Nov 2007 10:44:22 +0000

In JMock 1 you extended the cglib version of MockObjectTestCase but in JMock 2 its different. You need to change the Imposteriser used by the Mockery:

Mockery context = new Mockery();

context.setImposteriser(ClassImposteriser.INSTANCE);

Tool Support For JavaScript

chris.probably — Mon, 06 Aug 2007 00:57:04 +0000

Oh dear, what happened to my clever navigation and code-completion? The IDE support for JavaScript is still catching up with Java, if you have only small amounts of JavaScript you’ll be fine with TextMate or something similar. But for large class-based projects you’ll need something else.

The best thing at the moment is IntelliJ, its currently the only thing out there that can navigate across a codebase. With Aptana or Eclipse, if the method exists in another file it cannot navigate to it and you’re forced to resort to searching in files ending with *.js. Second best is Eclipse 3.3 with the JSEclipse 2.0 pre-release installed. (I’m really impressed with Eclipse 3.3 - its improved in several places - but I especially like the Quicksilver style Ctrl-3 shortcut).

How hard can unit-testing JavaScript be?

On the surface of things JavaScript seems to have a lot of the same tools that Java has for unit-testing. JSUnit is the JavaScript equivalent of JUnit and JSMock the equivalent of JMock.

The syntax of JSUnit is fine, its pretty much as you’d expect and conforms to the XUnit conventions. The key bit that’s missing is the fast feedback. When working on a class you want to be able to run the test often so you can see the immediate effects of changes you’ve made and the let the test tell you exactly whats wrong. To run a test with JSUnit, I need to open the JSUnit test runner in a browser, load my test page and then run it. Once I’ve run it, assuming its failed I get a list of tests that failed - but not the reason they failed, I need to double-click - then I get an alert telling me why the test failed. It really interrupts your flow, especially when you’re flipping between multiple classes. If you’re using an IDE with a Browser Preview tab, you can get around this problem with a little JavaScript along the lines of:

var currentLocation = ""   window.location;

window.location = "file:///.../testRunner.html?testpage="   currentLocation  "&autoRun=true";

(Sorry plus signs don’t seem to show up - hopefully you can get the general idea).

I’ve got this working in Eclipse by installing the EclipseHTMLEditor plugin and including the following common bit of code in all JSUnit tests:

var currentLocation = ""   window.location;

if (currentLocation.indexOf("cacheBuster") < 0) {

  window.location = "file:///.../testRunner.html?testpage="   currentLocation  "&autoRun=true";

}

Now a test can be run by just clicking on its Preview tab.

Making a Mockery

JSMock is kind of good - at least someone’s written a mocking framework for JavaScript. As soon as you start to use it - you realize that it is by know means a mature piece of software.

It doesn’t give you any kind of useful messages, for example it will say ‘Unexpected Arguments’ but won’t tell you what the actual arguments were against the expected arguments. Similarly for an unexpected invocation, it won’t tell you what has been called and what was expected to be called. The other missing piece is support for literal objects - JSMock gets it wrong if you pass a literal object as an argument. This is basic stuff - thankfully the code is still quite small and I’ve found myself adding a lot of these features myself just to be able to use it.

The cool thing about JSMock is that because JavaScript is such a flexible language you don’t need to put your method calls in strings like in JMock 1 and you can keep using literal language (unlike in JMock 2):

  server.expect().request('/index.jsp', {

    method: 'get',

    parameters: { userId: 'fred' },

    onSuccess: function () {}

  });

Another cool thing is that if I have static objects as collaborators I can mock those too:

var mockThing = mockControl.createMock(Thing);

// substitute the mock Thing for the real Thing

Thing = mockThing;

Sloppy Code equals Buggy Code ?

chris.probably — Thu, 26 Apr 2007 22:35:28 +0000

Having witnessed a lot of bugs recently, big and small, in some legacy code - there seems to be some patterns emerging. The root causes of the bugs are often found deep inside big classes, often with some suspicious looking commented-out code and the odd TODO floating nearby. Even when implementing new features, I’ve found myself spending most of my time trawling through these larger species of classes trying to work out what they are doing. I find myself deleting chunks of commented out code and tripping over scary looking TODO’s saying things like ‘Fix this when I figure out what it should do’ or ‘Hack - fix me’. These bigger, sloppier classes are minefields for potential bugs and quicksand for productivity.

Having read Ivan and Nat’s attempt at a Real-time Sloppographer, from the Scrapheap Challenge at SPA 2007, I was inspired to come up with a similar utility for measuring Sloppiness in the way it had affected me.

mostLikelyToBeBuggyTop10.py is a quick bit of python I wrote to measure sloppiness based on the things I’ve encountered:

size - bigger files get more sloppy points
TODOs - more TODOs, more sloppy points
does it have a Test? - if not - more sloppy points
number of comments - maybe slightly controversial - but the more comments, the more sloppy points - i’ve found files with big chunks of commented out code so it’s useful for me

# mostLikelyToBeBuggyTop10.py

import os, re, sys

todoPattern = re.compile('Todo|TODO')

commentPattern = re.compile('//')

excludePattern = re.compile('Test.java')

def howBuggyIs(javaFile):

    lines = open(javaFile).readlines()

    numberOfLinesMetric = len(lines)

    numberOfCommentsMetric = len([l for l in lines if commentPattern.search(l) and not todoPattern.search(l)])

    numberOfTodosMetric = len(todoPattern.findall(''.join(lines)))

    wouldBeTestName = os.path.basename(javaFile).replace('.java', 'Test.java')

    hasTest = len([f for f in javaFilesCopy if f.endswith(wouldBeTestName)]) > 0

    buggyMetric = numberOfLinesMetric (numberOfTodosMetric * 50) (numberOfCommentsMetric * 10)

    if not hasTest:

        buggyMetric *= 10

    return buggyMetric

def bugMetric(x, y):

    return howBuggyIs(y) - howBuggyIs(x)    

if __name__ == "__main__":

    if len(sys.argv) == 1:

        print 'Usage: python mostLikelyToBeBuggyTop10.py path [excludePattern]'

        print '    e.g.    '

        print '                python mostLikelyToBeBuggyTop10.py .'

        print '                python mostLikelyToBeBuggyTop10.py src/java Test'

        sys.exit(1)

    if len(sys.argv) == 3:

        excludePattern = re.compile(sys.argv[2])

    javaFiles = []

    for root, dirs, files in os.walk(sys.argv[1], topdown=False):

        javaFiles.extend([os.path.join(root, name) for name in files if name.endswith('.java')])

    javaFilesCopy = list(javaFiles)

    javaFiles.sort(bugMetric)

    javaFiles = [f for f in javaFiles if not excludePattern.search(f)]

    for mostBuggy in javaFiles[:10]:

        print mostBuggy

Sorry, some characters don’t show up, such as ‘+’, but you can get the original here: mostLikelyToBeBuggyTop10.py

Build-o-matic plugin screens

chris.probably — Mon, 01 Jan 2007 17:37:16 +0000

Latest screens from build-o-matic plugin for intellij:

Logging in:

After logging in:

(The black box saying ‘quick-cruise’ is the build-o-matic build being monitored : it goes red for last build failed, green for success and black if it can’t find the build-o-matic server (this is because I didn’t have a build-o-matic running when i took these screenshots))

(The two tiny icons are the pictures of the people who are currently logged in (me and no-one))

After I break the build:

A picture of our builds (Uh-oh - looks like the e2e build has crashed and the branch build is broken!):

Where can I get this plugin?

Coming soon - currently integrating with main build-o-matic source.

Is there an eclipse version?

Yes - but it’s no where near as good - only has the status bars.

Comments and feature-suggestions welcome

Eclipse vs. IntelliJ : Final Showdown (sort of)

chris.probably — Fri, 29 Dec 2006 02:23:25 +0000

Having used both Eclipse and IntelliJ for a while now - I’ve decided to have my own showdown between the two IDEs. Similar to JK, I’ll be recording every fault, brilliance, missing feature, annoyance and crash in this blog entry. After a month or two of using both - I’ll decide which one has further to go to become King of all Java IDEs.

I’ve gravitated between the two of them for a while and I’m probably one of the few who’s yet to make their mind up. Rather than knee-jerking between the two I’ll also be looking for ways around things, and seeing exactly how hard it would be to just dig in and code a plugin for “But (Eclipse/IntelliJ) doesn’t have feature X”.

No HTML editor in eclipse - easily solved, installed webtools.
No widen selection (Apple-w) in eclipse - not a big thing but a feature that you get really used to in IntelliJ
Lack of an easy way to create a test in IntelliJ - solved by downloading the Test Dox plugin (available from the IntelliJ Plugin Repository) - now I just hit Alt-Shift-T on a class and it takes me to the corresponding test, or offers to create one in the absence of an existing test.

Self-deleting script accident

chris.probably — Sat, 16 Dec 2006 20:35:13 +0000

I was working on a build which kept generating loads of files but not cleaning them afterwards. This was causing tests to fail because of stuff hanging around between builds.
So, I wrote a script which deletes files that are local and not in the Subversion repository.

#!/bin/bash

echo Deleting all local files not in Subversion repository:
echo
svn st | grep ? | awk '{ print "deleting... " $2; }'
echo
svn st | grep ? | awk '{print $2; }' | xargs rm -rf
echo Remaining differences to repository:
echo
svn st

Only problem was, because the script was not added to Subversion - it deleted itself.