Test Readability - Part 1

First, a disclaimer: I admit to being a bit of a sucker for Kent Beck's view that tests should read like a story.

Readable tests are good.  Readable tests are important, if the tests are to self-document. My question is is there such a thing as 'too readable'?  That's rhetorical by the way - of course there isn't.  What can be overdone is the work involved in obtaining the clarity we're looking for.  This post is the first of a series on how I do it.  Hopefully I'm not being a total idiot.


I use Hamcrest.  Perhaps too much at times, in fact.  I like to look at my tests and see the following:

Meeting meeting = sut.doStuff();
assertThat(meeting, startsAt(midnight()));
assertThat(meeting, endsAt(oneAm()));

Add to that the benefit that when it fails, you get nice messages like:

expected: a meeting starting at midnight
got: <result of Meeting.toString()>

instead of a message-less AssertionError (yes, I know I can specify a message, but that's even less readable to my mind). Of course, the down side of some of this readability is the extra code required to create the matchers. For the most part I find that a small price to pay to avoid this:

Meeting meeting = sut.doStuff();
assertEquals(0L,meeting.getStart().getTime());
assertEquals(3600000L, meeting.getEnd().getTime());

Note I say for the most part.  Sometimes, the code involved in creating the matchers is quite bulky, requiring as it does both a description method and the actual matching logic.  Where do you draw the line?  80/20 rule, DRY, write-twice-refactor, all have their place.  My view (as I've said above) is that there is a lot of value in readable tests, and knocking together matchers for them is mostly boilerplate and very little actual work.  Worth the time, in all but the most extreme cases, which is why I say I may like Hamcrest a little more than I should.

A second disclaimer:  I am a testability nerd - an interested amateur, but evangelical none the less.  Those who have asked me for code reviews feel the pain on occasion, but hopefully this helps explain my reasoning.

Notes to Self (Starting a Company)

So I've decided on a couple of things I'd do if/when I start my own [software] company:


1. Hire great people
Goes without saying, but get this right and the rest follows. Get it wrong and you're screwed before you even start.


2. Make it really easy to try stuff out
I mean really, really easy.  
This covers things like 20% time and study time, but it also covers the much-less-seen act of lowering the barrier for projects.  I have worked in telecoms, healthcare, manufacturing, banks, tech companies and others, and all but one them required you to have hardware sign-off, purchase orders and approvals before you could host (say) a web server.  That kills any kind of innovation stone dead.  
In the one that didn't require budget to start, new proposals generally take the form of working demos instead of  paperwork requesting hardware and developer time.  If the demos impress, then budget/dedicated hardware/developer time can be awarded later.


3. Make all the cool stuff you have discoverable
Did one of the guys in your burgeoning company write an awesome library for testing your new tech?  Now that you've grown a bit, do all the new guys know about the library?
You may write some excellent software that's internally useful, but unless everyone that needs to can find out about it, it's next to useless.  Note I'm not talking about API docs.  They're for when you already know it exists and just to figure out how to use it.
Even internal coolness needs to be promoted.  I've worked for companies that have tens of thousands of lines of internally-useful stuff that people only find out about because they come across it in someone else's code.  Internal talks are good for this, as well as a centralised portal, but the bigger the pool of resources gets, the less useful either approach becomes.


4. Meetings as a last resort
Meetings are more often than not a productivity killer.  That's not to say that the idea of meeting is a bad one, just that the majority have become gigantic timesucks that people hold because they feel they should.
For a developer, having long runs of uninterrupted time is crucial.  No-one produces their best work in isolated 30-minute segments.  I try to limit my meetings to a 15-minute stand-up in the morning so everyone on the team knows where they are, and calls with remote team members as and when necessary.
I say "try" as it seems the rest of the company are onto me and try to foil my plans.  My pet hate - the weekly status update meeting.  If it truly is "just so we can keep up to date with your progress", I can send you an email, or even better you can look on our issue tracking tool (or Gantt charts if your tastes run to the perverse).
Thus the strategy will be if you want to call a meeting, you have to justify it.  Defend your decision to evict people from the zone - if the meeting truly is important and can't be done another way, it shouldn't be hard.


I'll probably add some more to this, but it'll do for now.

Dodgy delimited files

Very often, I see files that are supposedly x-delimited, but that then have x in the fields. Obviously this is an issue. Sometimes some "kind" soul wraps only the affected values in quotes, instead of selecting a better delimiter or limiting their data (or even quoting every field, or just every instance of that column).

Thanks.

This awk script turns a comma-delimited file with quoted comma-containing fields into a pipe-delimited file with commas in non-quoted fields.

awk -F '["]' '{for (i=1; i <= NF; i+=2) {gsub(",","|",$i)} print }' file.csv

256 Colours with Vim and PuTTY

This is more for my own edification, and is really a collation of other stuff I found:

Step 1: Configuring PuTTY

When creating your session, under Window -> Colours, check the top 3 box es:

• Allow terminal to specify ANSI colours
• Allow terminal to use xterm 256-colour mode
• Bolded text is a different colour

Under Connection -> Data, make sure Terminal-type string is xterm-256color, or xterm

Step 2: Configuring Vim

In your .vimrc add the following:

if &term =~ "xterm"
 set t_Co=256
 if has("terminfo")
   let &t_Sf=nr2char(27).'[3%p1%dm'
   let &t_Sb=nr2char(27).'[4%p1%dm'
 else
   let &t_Sf=nr2char(27).'[3%dm'
   let &t_Sb=nr2char(27).'[4%dm'
 endif
endif