james mckay dot net

Unit testing is one of the programming disciplines that, to my mind at least, sets apart the reputable developers from the cowboys. Test driven development has become increasingly popular over the past few years, and for many teams, it’s becoming as fundamental a discipline as using source control. It’s an idea that sounds almost like a no-brainer at first: you write a bunch of methods that feed test data into your code and examine the result, and they report either success or failure. Then when you start extending and modifying your code, you can re-run your tests to check that everything still works as it’s supposed to, and you haven’t broken any dependencies.

Yet of all the programming disciplines that I’ve had to get to grips with over the years, unit testing has probably been one of the most difficult. Setting up your project to facilitate automated testing involves quite a lot of groundwork. You have to configure a test environment, perhaps with a test database or other form of test data source, and you also have to completely re-think the way you write your code. It requires greater discipline — it’s all too easy to think “Stuff that,” and slip into the old mindset of just slapping down your code and testing it manually. Some legacy code may seem almost impossible to test, especially if it is a Big Ball of Mud with long, multi-purpose methods and no clear separation of concerns. Then there is the question of what to do with external dependencies — components that are beyond the control of your unit tests, such as third party web services, input devices, and even the current date and time.

If you’re wrestling with problems such as these, Roy Osherove’s book, The Art of Unit Testing, is a must-read. Most treatments of unit testing that I’ve come across only cover the topic at a fairly basic level, but this one picks up where they leave off. I was pleased to see some good solid chapters on stubs, mocks and dependency injection, for instance: these are essential tools needed to break external dependencies. I was also pleased to see a whole chapter devoted to working effectively with legacy code; another whole chapter is devoted to the political and organisational implications of introducing unit testing into your organisation.

The book assumes a basic familiarity with object oriented programming and design patterns (which every working developer should understand properly anyway) but it isn’t a difficult read, and it explains things very clearly. Code samples are given in C#, but developers working with other languages will also find much in it of benefit. There are plenty of suggestions that may not have occurred to you, and you’ll end up much more aware of the “tricks of the trade.”

My only disappointment was that four major, and potentially thorny, aspects of the subject — database, UI, web and thread-related testing — were only given a brief overview in the second half of Appendix B. Of course it could be argued that these were outside the scope of this book — indeed, Osherove argues that unit testing in some of these areas in particular have a relatively low return on investment — and in others, unit testing frameworks and methodologies are still very much in their infancy. However, I was hoping for a somewhat more extensive treatment of these aspects of the subject and it was a little bit disappointing that they only got six pages.

But this doesn’t detract from the value of the book. Whether unit testing is your “thing” or not, it is very much a must-read for every working .NET developer, and indeed for developers working with other languages too. It deserves to be as much a classic as books such as Code Complete, Design Patterns, or Martin Fowler’s Refactoring.

Comment on this »

Posted at 08:00 on 29 September 2009.
Tagged: best practices, Books, Roy Osherove, The Art of Unit Testing, Unit testing

The Sams Teach Yourself … in 24 hours series gets a bit of a bashing from some people. The criticism is that you can’t learn to be a programmer, let alone a good one, in only 24 hours, and by publishing books with titles such as these, they cheapen our craft. People wander into a bookshop, pick up a copy of Teach Yourself PHP in 24 hours or something, and the next day they are copying and pasting SQL injection vulnerabilities from all over the web into what they hope will be The Next Facebook. Or so the thinking goes.

Now people who say this kind of thing have a valid point. You can’t learn to be a good programmer overnight — it takes years of experience, trial and error, constantly honing your skills, and so on, and I don’t think you’ll ever reach a point where you stop learning. However, I don’t think it’s fair to turn this point into a criticism of books such as the 24 hours series. To be sure, these books won’t turn you into an expert programmer in a weekend, but if you think that’s what they’re all about, you’ve completely misunderstood the title. Their aim is to give you enough knowledge to bootstrap your understanding of the subject in that period of time to a point where you can actually start to Get Things Done, and then give you a platform to build on.

In that respect, I think they play a very important role. Whenever I come to a completely new technology, I see a mysterious black box, with everything hidden away behind a facade of whatever user interface you have, and if that happens to me as a particularly techno-savvy type, it’s certainly going to happen to lesser mortals as well. However, I often find that it just takes a little bit of an idea of what’s going on under the hood for me to get started finding my way around it in earnest. Somehow, the first part of the learning curve often seems the steepest.

There’s another reason why they’re important too. Computer programming these days — certainly, programming in the Real World — often requires you to get a handle on new technologies and languages very quickly. It’s a fast paced world, with new technologies coming out left, right and centre, and if you don’t keep up you’ll fall behind. Add a few over-enthusiastic sales guys into the mix, convincing the clients that you’re the world’s greatest SharePoint expert on the basis of the fact that you threw a default installation of MOSS 2007 onto a server and set up a couple of custom lists, and things get all the more interesting. Very often, you need to get up to speed with something in only 24 hours.

In this respect, I’ve found the 24 hours books to be some of the best introductory texts on computer programming related subjects that you can get. I originally learned XML from Michael Morrison’s Teach Yourself XML in 24 hours. I have two books on UML: Martin Fowler’s UML Distilled and Joseph Schmuller’s Teach Yourself UML in 24 hours, and I find Schmuller’s book the easier and clearer of the two to follow. It doesn’t particularly dumb the subject down either — both books cover the same material in similar depth. Given that Martin Fowler is one of the best tech writers around today, that speaks quite favourably for Joseph Schmuller.

I somehow wonder if there’s an element of snobbery involved in criticising books such as these. It seems to me that most of the criticism comes from very experienced and knowledgeable computer science-y types — the kind of people who think that Scheme is the best language to start with for teaching programming to ten year olds. It’s a bit like the world of church music: some traditionalist classical musicians get very dismissive of modern Charismatic worship albums. You can easily understand why: if you’ve spent several years studying for multiple degrees in music or computer science, no doubt working up a massive student loan in the process, you aren’t going to take too kindly to the idea that someone can be just as successful in your field without having gone to the same amount of expense and trouble.

So don’t be embarrassed about reading books in the 24 hours series. Everyone has to start somewhere with new technologies, and for getting started, these books are every bit as good as any.

Comments closed (2) »

Posted at 08:00 on 17 October 2008.
Tagged: 24 hours, Books, UML, XML

I was late home this evening because I was sorting out a problem for one of our clients. One particular database table has a couple of triggers that update some tables in other databases. It turned out that someone had renamed one of these other databases but had forgotten all about the triggers, which were throwing errors as a result. Fortunately, it didn’t take too long to track down the problem and fix it.

This kind of thing is very easy to do if you have a lot of database interdependencies and stored procedures like this. Databases are by nature very tightly coupled to your other applications and systems, and making major changes to them calls for nerves of steel at times. They are frequently accessed not only by the applications that you know about but often by several that you don’t, especially in larger organisations. With that in mind, any smart advice and help that you can get is most definitely welcome.

This is why Refactoring Databases by Scott Ambler and Pramod J Sadalage (Addison-Wesley Signature Series) is a book that I highly recommend to any developer (or DBA) working with databases in any capacity. It has a lot of useful advice on how to handle different scenarios that you may come across (including political ones), as well as details about the precise mechanics of specific refactorings, and shows you that with a disciplined, iterative, step by step approach, backed up by a suite of unit, integration and regression tests, it needn’t be all that scary.

Comments closed (1) »

Posted at 23:39 on 14 July 2008.
Tagged: Books, databases, refactoring

Since I started taking JavaScript seriously just over a year ago, I’ve found myself a bit disappointed with most of the online resources for it that are knocking around. The main ones seem to concentrate solely on the basics, and tend to be aimed at beginners — people who are happy to write code in a purely procedural manner and just want the basic information needed to get the job done, even if it does mean writing gratuitous amounts of copy and paste code.

Personally, I’ve felt a bit disappointed by this. I’ve said before that I think of JavaScript as the new Scheme — so with that in mind, anything that treats it as if it were merely client-side PHP will naturally be something of a disappointment. Perhaps this is a case of quidquid latine dictum sit, altum viditur on my part, but I like to use closures, lambdas, iterators, generics, Linq and so on in my code to maximum effect. I am also firmly of the opinion that every professional developer needs to be familiar with these concepts too — after all, they show that you have the kind of mind that can handle the complexities of software development, and won’t stumble over the FizzBuzz problem.

So when I came across Pro JavaScript Techniques by John Resig on Thursday, I thought it sounded like a breath of fresh air. Resig is something of a JavaScript guru: he is the lead developer of jQuery, and really knows his stuff, so I expected it to hit the mark in this respect. I promptly ordered it through Amazon.co.uk, and it arrived pleasingly promptly yesterday lunchtime.

The book certainly does not disappoint. Following a short introductory chapter, it gets right down to business with a chapter on the more advanced features of the language such as closures, currying, scoping rules, and how to make full use of JavaScript’s somewhat unorthodox, prototype-based approach to object oriented programming. This is followed by advice on how to write reusable code, unit tests for your scripts, and how to enforce good code conventions with tools such as JSLint. The rest of the book focuses on the practicalities of real world JavaScript as it works in the browser, with chapters on the DOM, events, CSS and forms, and Ajax, and ties it altogether with several practical examples including an image gallery, an Ajax search box, an Ajax wiki, and a Google Reader style "never ending" WordPress theme. He treats the subject in a fair amount of depth, about as thoroughly as you can in 350 pages, covering gotchas and issues with common browsers along the way, and points to resources on the web where you can find out further information.

This isn’t a book for complete JavaScript novices — it assumes a certain amount of familiarity with the language, and is written more from a perspective of adopting professional best practices and producing high quality code rather than from simply getting you up and running quickly, so at least some experience of JavaScript is necessary. However, it is not a difficult read, and a competent developer with at least some basic JavaScript experience should find it fairly accessible.

The only downside to it is that as it is now two years old, there are already one or two omissions that date it somewhat: it does not cover Internet Explorer 7 or Safari for Windows, for instance, and it still recommends testing your code against Internet Explorer 5.5, which has since pretty much fallen off the radar. However, all the content is still applicable today, and no doubt will remain so for quite some time to come. Personally, I would recommend it to any professional web developer who wants to improve their JavaScript skills. (And if you are a professional web developer, you jolly well should be improving your JavaScript skills.)

Comments closed (1) »

Posted at 22:06 on 16 February 2008.
Tagged: Books, JavaScript, John Resig, jQuery