2010-03-22 at 9:40am
If you haven’t done anything about the looming Digital Economy Bill, go read this and do something.
Rewired State vs. Digital Economy Bill - need we take a stand?
The preliminary results of the data.gov.uk format verifier exercise have been written up by Charles Arthur on The Guardian’s Technology Blog. He is very right: government getting entangled with geeks is hilarious - in our world, we don’t have PMQs and press releases and all that. We have bug trackers. We have unit tests - they pass or they fail, and they tell you pretty quickly what is wrong.
I am currently not at all sure how involved I should get with government data initiatives as a hobbyist developer. I don’t want my work to be used as a tool to boost government PR when the government’s other hand is doing all it can do to basically sell out Internet users to the recording industry. The government need to decide whether they want the support of David Geffen or the geeks of the land. If refusing to be involve with government data projects can do anything to stop the Digital Economy Bill, I’ll stop attending hack days and the like in a snap. On the other hand, the government are working with people I know and like (people like Jeni Tennison and John Sheridan), and I don’t doubt that - PR aside - many in the government are honestly trying to do a good job to make government data more useful, available and usable. It is in our best interests for the government to make data available - both for the government (the Rewired State-type people can help build tools and services that make public services more usable and cheaper to deliver) and for citizens (because we can hold the government to account). For democracy (and capitalism) to work, you need more, not less, information and data. The Internet does have the ability to increase the amount of information available, to contextualize it better, to hopefully produce more informed, enlightened citizens - so we can have a democracy more like that of Rawls or Habermas and less like that of The X-Factor or the ignorant armies clashing by night
image from Arnold’s Dover Beach.
If I were to build something that is going to provide a PR win for the government, does that mean I am helping the government’s overall digital strategy, including the draconian Digital Economy Bill? What should our response as developers be? A boycott? Do we have a responsibility here? I don’t want the BarCamp/Rewired State type crowd to be playing the J. Robert Oppenheimer role in all this - geeks are very easy to corrupt. It might be easier if we just said no until the government got their house in order. But if we do say no, then we can’t necessarily guide them to implement all the open data stuff they are doing right (for that stuff to work, it really needs to be done in collaboration with the community). Opinions welcome.
Change all the words, the issues remain the same: a cynic’s guide to software testing
Every so often, I come across a presentation or article about testing and methodology. I almost always regret reading it. We all have to do testing, right? You don’t need to sell me on it. I’m fine with it. I’m even fine with test-driven development, and I try to adhere to it. In Ruby and Rails, I use RSpec and Cucumber. I’ve tried out Celerity and Culerity, and I like them. Good stuff. On the rare occasions that I use Python, I use unittest, I guess. In Scala, I’ve recently been discovering the joy of testing with Specs (see sbt-growltest). If you took me off to Guantanamo and the only way to avoid getting waterboarded was to write Java, I’d probably use JUnit. And NBehave for .NET. PhpUnit for PHP. You get the gist. I try to write my tests, but I won’t bite your head off about it.
But when I read these articles from the Agile community or whatever, I always feel they are just jiggling the words around. No, we shouldn’t just do testing, we should do unit testing. No, we should do test-driven development. We need to get test-infected. Hold on, no, we need to do behaviour-driven development. TDD. BDD. No wait, I need to do Design by Example. Or Domain Driven Design. I need more XP. I need Scrums. I need fixtures. No, wait, I need factories. I need another different unit-test framework with shitty non-existent documentation. I need design by contract. I need coaching from a certified Agile Coach. I need a few hundred new patterns. I need to stop thinking of my tests as unit tests. They don’t test anything as mundane as classes and methods, they test units. Or, better yet, behaviour. Or whatever the trendy new social-science-derived (or, more often, thesaurus-derived) word for ‘class’ is this week.
No, what I need is for you to fuck off and let me write some code. Yes, mummy, I will write my unit tests. Now let me get on with it. While the lifehackers fiddle with GTD, the programmers fiddle with TDD. We rejig the system over and over in the belief that it is going to make us better people. If only we get the formula right, our souls will be saved, and maybe our names will adorn the golden pages of the Pattern Writers, and we shall be like Test Gods among the fallen. Writing unit tests won’t be boring drudgery (or organising my to-do list) will somehow magically turn into a magical and exciting experience if only I get the right combination of libraries. You don’t believe me? I was bloody well photoshopping Duke - you know, the cute little Java mascot - so he would have a green nose while on the train the other day. So that when the little Growl pop-up showed me my tests passed, I’d have a green-nosed Duke, and when the tests failed, I’d get a red-nosed Duke. I know that I suck, okay?
Worse is now that the XP and Agile community have basically won - there are a few hold-outs sure, but who doesn’t believe that something broadly agile is better than something waterfall-ish? At most, all you can find are a few people who think Agile needs to be tempered with a teeny bit of up-front planning - is that agile consultants have to come up with new shit to sell. It is like Microsoft or Apple or whatever - you convert someone over to Office. But once you’ve done that, you’ve got to keep them on the upgrade path. It isn’t enough that we are all writing specs and tests, and collecting user stories and all that. So now we need the Agile++ 2010 Professional Upgrade. Well, no thanks. I am perfectly happy with my (lack of) religion, and I’m perfectly happy with my methodology - I don’t need yours, thanks. Sometimes, the worst thing about winning is that you no longer have any lands to conquer, as Hans Gruber, the leading bad guy in Die Hard said of Alexander the Great. You’ve won the fight, and now you have to enjoy the peace of it all. If you have a financial stake in people sucking at software development, well, you have a financial motivation to keep selling them extra steps on the road to salvation. Did I just compare Agile coaches to the Church of Scientology?
Anyway, I should probably explain my testing heresies.
In a typical Rails project, I tend to write two types of test: unit tests and integration tests. My unit tests are usually testing the models - specifically testing the more complex validations, custom methods I add to models, especially those which encode business rules - because, well, bad shit happens if the application spits out the wrong figure and someone actually goes to try and bill their clients with the wrong numbers. Like court-judgment-going-out-of-business type bad shit. The sort of bad shit which means one has to go and collect dole money rather than build Rails applications. I build these with RSpec. Most of them are absolutely critical tests. Many are based on bugs that have been fixed - so-called regression tests.
I also write integration tests. These are important because the app needs to present all this data to people, and they need to be able to click around on the website. I use Culerity for this. It rocks.
I don’t bother with controller tests at all - primarily because that involves huge amounts of mocking and stubbing pain. Why don’t I do this? Simple cost-benefit analysis. I’ll kind of know whether the controllers are working when my big clunking Culerity HtmlUnit JRuby browser simulator comes along and spams my test server with HTTP requests and it fails to answer them sanely. I could write a load of tests for my controllers but that is extremely painful and has diminishing returns. If my controllers don’t work, I will find out about it pretty quickly. In the rare event that a controller-related problem makes its way into production, I’ll fix it. These browser tests - integration test, whatever - do occasionally test more than one controller. A user logs in, changes his password, adds a job, generates a report and then logs out. That kind of thing. If you like to talk the lingo, they are technically integration tests. Sometimes they just test one behaviour though - just mercilessly trying out lots of different things on one page - all the different Ajax controls.
If we boil it down, I need to test the business domain objects (they are in a PostgreSQL database) and I need to test the browser. So, just to irritate the Agile cultists, I shall refer to the former as “model tests” and the latter as “browser tests”. No complicated theology required to distinguish whether they are unit tests or integration tests or functional tests or whatever. The first lot tests that the business domain objects are doing the right thing, and that, oh, jobs in the system can’t be delivered before they have finished production and that they can’t be assigned to manufacturers who have gone out of business or whatever. The second type of tests - the browser tests - are to make sure that when you click on all those links and fill in all those forms, they go to the right place, and all the little Ajax doodads do the right things.
This is not a comprehensive listing of all the types of tests that need to be done. Other types of tests can be easily slotted in to this schema - but only if you need them. Not if a post on Reddit tells you that you need to do them. Or some Agile consultant tells you that you need to do them. Or because a manager - who only last week was telling you that XML was the future of everything because he read it in an industry mag - is now sold on it. Most of this is just common sense. You don’t need fancy labels for it, any more than you need to specifically note that scratching an itch is an insance of Itch-Driven Scratching.
But, you know, I guess I should probably give a name to this testing methodology. I mean, everything has to have a name, or it isn’t truly a real thing, right? I christen this methodology “Bullshit Free Testing”. It only has three rules:
1. Testing - even TDD - is great, but only if it makes the lives of the developers and/or the users better. Prefereably both. Anything else is excessive.
2. You don’t need testing religion - do what you need to do to sleep at night, follow your common sense. If you need to test aspects of your application that you currently aren’t, go ahead. You don’t need any fancy labels or tools or frameworks for them.
3. Now shut the fuck up about testing and methodology and eat, drink and be merry, for tomorrow… we have to write more bloody tests.
