Boy Meets World

Mike is currently…

getting whipped at Halo

[ subversion book ]

obligatory book plug

[ syndicate ]

rss 2.0 feed for boy meets world

[ contact ]

drop me a line

[ about ]

this is mike mason's weblog

[ eskimoman.net ]

original web pages

Thu, 29 Jan 2004

This is an archived blog post. I've switched to using WordPress as my blogging software and have not migrated all my old posts. I believe strongly in not letting an old link die, so this page continues to work. Please do visit mikemason.ca/blog to read newer posts.

Unit Testing is about Going Faster

Extreme Programming is about taking all the best practices in software development, and cranking them up as high as they’ll go. Spinal Tap had amplifiers that went up to 11 – we have XP. Testing is generally agreed to be a “good thing”, and so with XP we test all the time, by writing unit tests that exercise every piece of code. Test Driven Development encourages us to write the tests before the code, thus driving the design by asking questions about what the code should do – what do we want to test?

A few nights ago I had a discussion with a colleague about the code he’d written that day. He was excited and happy because he knew exactly where he’d wanted to take a piece of code, and had pretty much just written it straight off. He was concerned, though, that he’d not used TDD to develop the code. My response was to ask him why he felt that he needed to use TDD if he was so confident about how he wanted the code to look.

XP, and therefore Unit Testing, is about delivering working software quickly. That means you need to be able to write the code quickly, get it to work (avoid and fix defects) and to be able to change and maintain the code in future. The fastest way to deliver working software is to write correct code, straight off, in one sitting, to a known set of requirements. Most programmers can’t write code that’s perfect, and most customers change their minds about the features they want (this is a good thing – we’re embracing change). Your response as a programmer to the reality of imperfect code is to write unit tests to help check your work. How many tests you write should depend on how confident you feel about the code — if it’s similar to something you’ve done in the past, maybe two or three tests including edge cases will be enough for you to be happy. Later, if you realise your code had bugs in it, you’ll learn that you should have written more tests, and take that experience forwards when coding in future. Similarly, if someone else modifies the code and breaks it, you’ll learn that you didn’t include enough tests to make that code maintainable, and do it differently next time.

Proponents of TDD would argue that we’re never sure of the code to write, or the features we really need (as opposed to those we think we need). They’d point out that untested code will always have bugs in it, and will always be broken by future modifications. I think TDD’s very powerful and use it myself frequently, although not exclusively. As with any other tool it should be evaluated for the context in which it’s to be used.

TDD helps you move faster if you’re unsure of what to code, but that wasn’t the situation faced by my colleague. I’d argue that he should do enough testing to be comfortable, and still move fast. Finding the right balance between unit testing and speed of development requires experience, skill, and good taste.

Posted 12:42, 29 Jan 2004.

[ permalink ]

Fri, 09 Jan 2004

Predictions for 2004

At GeekSpeek yesterday (kinda like GeekNight but with curry instead of pizza, and no computers) Tim Bacon asked us all what 2004 might yield for the computing industry. Here’s what we came up with.

.NET development will become much more attractive, because Visual Studio will gain refactoring support. IDEs continue to be a major factor in attracting programmers to a particular technology. IntelliJ Arora is looking great and Eclipse is quite a capable IDE (but seems to be lacking some direction — their stated goal isn’t “to be better than IntelliJ”, they’re building a platform). JetBrains, the people behind IntelliJ, are also working on a bringing refactoring support to the C# world. Some of my colleagues have stated that they’re most efficient whilst coding in Java, not because it’s the best language, but because it has IntelliJ.

Subversion will become the de-facto standard for version control. I’m always talking about this, but Subversion is currently in beta and will have a 1.0 release in February of this year. SourceForge will begin to support Subversion, following in the footsteps of Tigris and CodeHaus who already offer Subversion hosting.

Apple’s iPod will become the must-have accessory for anyone with enough disposable income to afford one. Techies across the planet all salivate over Apple hardware, yet when it comes to actually parting with hard cash, I for one am less eager. I’d love an Apple computer, but can’t really justify it. An iPod is different – I really should have bought one instead of a cheaper clone. iPods have mass market appeal, they’re releasing a cheaper, 4 gig model, and so I really hope this will be the year of Apple.

Posted 16:31, 09 Jan 2004.

[ permalink ]

[ tim bacon ]

musings of an xp coach

[ ian bourke ]

enhancing core competencies since 1976

[ martin fowler ]

a cross between a blog and a wiki

[ alan francis ]

agile != good

[ paul hammant ]

part of the problem…

[ darren hobbs ]

the blog formerly known as pushing the envelope

[ mike roberts ]

on life and technology

[ chris stevenson ]

skizz-biz

[ joe walnes ]

joe's new jelly

[ rob baillie ]

oracle

Registered plugins: SmartyPants, antispam, bloglinks (v0.2), calendar (v0+6i), pluginfo (v1.0), and userstatus (v0.1)
This work is licensed under a Creative Commons License.