Month: January 2009

Posted on

Behaviour driven development on user interfaces with Automation peer

Testing user interfaces is usually a pain in the butt. No matter how cool your UI is, it will often boil down to a brain-cell killing process clicking the same buttons over and over again. Thanks to the Geek Gods of .Net though, there are ways to automate this, and it’s not even that tough to do.

In this post, we’re going to use Automation peers to expose a button to a unit test, and have the test start the application, click the button, and confirm that the button does what it’s meant to do. We’re going to use MbUnit to write the test, and NBehave to make the tests nice and clear.

Continue reading “Behaviour driven development on user interfaces with Automation peer”

Posted on

VS and SVN – Ignoring user specific files

Visual studio tends to create files that you don’t usually want to keep under source control, such as generated files, user option files, and so on. To avoid having to clean up every time you try to Add files, you can tell TortoiseSVN to ignore certain file name patterns. The following is what I usually use:

**/bin bin **/obj obj *.suo

You can set these patterns in the “Global ignore pattern” text box in the main screen of the TortoiseSVN settings dialog.

Posted on

Size does matter

Write better JavaScript. Check out The Little Book of JavaScript!

A good user experience requires responsiveness. Speed. Web pages that don’t make you wait more than a couple of seconds while they load, or even worse, load in bits and pieces and reorganize themselves in front of the user; “that’s the way these things work” isn’t good enough an excuse. Your users don’t want to know how your site works (even if your site is about how the internet works – they want to read about the problems, not experience them), they just want to get things done and move on. As Eve says in Gaiman’s The Sandman Vol. 6: Fables and Reflections, “Some people have real problems with the stuff that goes on inside them … sometimes it can just kill the romance”.

Two of the culprits these days seem to be huge JavaScript and CSS files. They’re by no means the only causes, but they can cause trouble at times. Delays when loading a CSS file result in the dreaded flash of unstyled content on some browsers. Problems loading a JavaScript file… well, let’s just say it ain’t pretty. The delivery of these files can be slowed down by a number of factors. File size is one of them; a 168kb file will download considerably more slowly than a 6kb one.

This is made worse by the use of multiple JavaScript and/or CSS files. Separating functionality or styles in a sensible way is heaven-sent when it comes to maintenance, but the way the web works means that it’s a lot easier to download one largish file than several small ones. Multiple files mean that the browser must make multiple requests to the server, and each request carries a small overhead since the server has to include a certain amount of information with each response it makes. To top it off, most browsers are configured to open a limited number of connections to a server at any one time – IE8 allows up to 6 concurrent downloads on broadband, while Firefox allows 8; these connections must be shared between the JavaScript, style, images, and other embedded files. This can cause the downloads to be queued up on pages with a lot of stuff on them.

What we need, then, is a small number of reasonably sized files: how do we get to that?

Continue reading “Size does matter”

Posted on

Version control for the masses

Version control is one of those weird, geeky things that never really gained much ground in non-geek fields, despite the fact that it’s blindingly useful. Even educational institutions (at least the ones I’ve been able to observe) seem to prefer to omit so much as a mention of it in their technical courses. I can’t really give a reason for this, but it does at least give me the excuse to write a post about version control and kick it off with a rant.

So what’s this version control thing?

Version control (or source control) is nothing more arcane than keeping copies of your work as you make changes to it. On the surface, it’s all straight-forward; make a copy of every file you have before you make any changes to it. That way, if you seriously mess up, you can always fall back to something that worked before, or at least compare your broken copy with one that used to work so you can figure out where it went off kilter. Your client wants the image he told you to throw away two days ago? No problemo – out comes the backup. Accidentally deleted half your thesis and closed the word processor? No problem – out comes the backup.

Now, in the real world, it’s not so easy. Unless you have an iron will, a black belt in filing, and a zen-like ability to name files in a sensible way, you’ll be swamped with a huge number of backups with similar looking names. Something that’s impossibly difficult to find, might as well not exist at all. We want to get the goodies, but really need to keep all those backups out of our way. Luckily there are like, loads of version control systems out there to do the heavy lifting for you.

The rest of this post will be about how to set up a version control system for a single user. We’ll use Subversion, because it’s free, works great, and because I like it. Since we want to keep things as slick as possible, we’re not going to use raw Subversion though – we’re going to use TortoiseSVN, which is also free, also works great, and has nice coloured icons to boot. This neat tool lets you do most of the stuff you want Subversion for, but it lets you do it from Windows Explorer, rather than the command line.

Continue reading “Version control for the masses”