Mark’s Testblog

Can you believe this horse shit?  Yes, you read correctly.  DRM that requires you to be online.  At all times.  Not at all irritating.  Check the calendar, folks — it’s not the first of April.

I’ve already had enough of the likes of Securom messing up my (paid for) games.  My trials and tribulations included misfiring versions of Fallout 3 (randomly stopped working and required a reboot) and Race Driver: GRID (I had to eject the disc prior to starting the game every single time).

Unfortunately, Ubisoft’s latest ‘solution’ looks far more invasive.  Do these companies honestly believe that penalising their paying customers will lead to improved sales?  It’s a guaranteed road to ruin.  There’ll likely be a cracked (read: superior) version on torrent sites within the week of release — possibly a day zero effort.  I don’t advocate game piracy, but I could swear that certain game publishers do.

Along similar lines: I’m already fed up with the amount of games that require extra bullshit.  Every single extra step that I have to take is a barrier between me and your game.  Recently, many games are starting to demand a Windows Live account, even when I don’t care about it.  Batman was bad enough for it, but GTA IV on the PC requires me to sign up for a Windows Live account and then constantly nags me to sign up for the Rockstar Social Club.  This adds an extra two screens to click through every goddamn time I want to launch the game.  I don’t want to watch some user generated bollocks video about a clown on a moped, I just want to play the game.

I feel like William Shatner in “I can’t get behind that”.  Leave me the hell alone!

Here’s the old way of playing a game you’ve recently purchased:

1. Install
2. Click on shortcut to launch game

Sounds pretty good to me.

When the logic of a test method remains constant but the data varies, data-driven testing is a great tool.  It allows you, the test author, to write compact code and to add new test cases rapidly.  Unfortunately, data-driven tests have a disadvantage: The inputs are often less readable.

A simple example

Let’s take an example; testing Rob Conery’s PagedList implementation.  A page is basically a slice of the data returned by a linq query.  If more data exists beyond the ‘slice’ represented by the PagedList<T> instance, its “HasNextPage” property should return true to indicate that it is available.  Now, suppose we want to test whether a particular page has a next available page.  Three things spring to mind that can influence the result: The page size, the current page index and the number of items in the list.

Here’s a quick data-driven test for HasNextPage:

As you can see, the method itself is readable, but the parametrised values fed in via the [TestCase] attribute are not.  It’s really hard to keep everything in your head and remember what each number maps to in the function, especially when the method parameter types are all identical.  If you have a list of 20 [TestCase] attributes, you start wondering what’s for your tea and forget that the second value is the (checks image) page size.  Mince.  Mince for tea.

Hmm, if only we could those TestCases more readable; something like object initializers would be ideal.

A simple trick: Subclass TestCase

My friend Hughel helped me come up with this one and it works quite well.  Simply subclass the TestCaseAttribute class and add your own properties to represent the test parameters.  It gets a little bit hairy when you have to access the Arguments array directly (especially since Attributes can be weird), but in practice, it works fine.   In most of the tests, we’re only interested in parametrising three things, so it’s simple to add them as properties.

The end result

Finally, we apply these attributes to our data-driven test, significantly improving the readability!

I would hasten to add that I don’t recommend using this approach willy-nilly — only when you have a large amount of tests that are parametrised by the same data types, causing the test cases to become hard to follow.  I’ve used the [TestCaseSource] attribute and the [TestCase] attribute a lot in the past and most of the time it’s not a problem.