At Storm we like our developers to be polyglot programmers. We believe knowing a wide range of languages, APIs and toolsets makes for better programmers and ultimately, better deliverables for clients. It means we can pick the most appropriate tool for a task and deliver an excellent final product. As the old saying goes, ‘if your only tool is a hammer, everything looks like a nail’ – and that’s bad.
So, what have I learnt this year to add to my programming arsenal?
As part of my dive into unit testing Rails applications I was keen to set up a tool to give me code coverage stats. Code coverage represents the % of your source code that your unit tests exercise. 100% code coverage is a good goal to have and the earlier you hit it, the more likely you’ll find testing a worthwhile endeavour. Whilst 100% coverage doesn’t guarantee that you’ve tested every permutation in your app, not having 100% coverage guarantees there are bits where daemons may be lurking.
I’ve been getting up to speed with writing unit tests for Rails applications today. My setup currently consists of RSpec tests being automatically run by autotest when I save a file. This is a really nice workflow as you get instant feedback on failing tests. Couple that with the autotest-growl gem to receive Growl notifications on failure and you’ve got a pretty funky setup.
However, autotest decided it wanted to re-run my tests over and over again, even if I hand’t saved a file in my project. This had me very confused for quite a while until some Googling led me to ‘autotest -v’ which shows you which files had changed. The culprit: test.log.