Showing posts with label Series. Show all posts
Showing posts with label Series. Show all posts

Monday, 7 January 2013

My Life in Computer Games: Part 3

This is a series of posts which chronicles my life as measured by the computer games I’ve played; you can find parts 1 and 2 here and here. Let’s finish the journey…

Super Metroid

Image courtesy of Power Cords

So far I’ve been listing games in chronological order, so you might find it strange that I describe a game that was released on the SNES in 1994. The reason is that I discovered this game during my “emulator phase” after finishing university; I never owned a SNES so I decided to see what that console had to offer, and this ended up being one of my favourites.

Super Metroid was not what I was expecting from Nintendo; the company that produced Mario and Zelda, how did they also make this dark, atmospheric game with a design inspired by the Alien films? From the beginning the mood kicked in; exploring what looked like a dead planet with no life signs until you were spotted and things kicked into action, this game was an excellent adventure with memorable bosses, the feeling that if you just looked a bit further you’ll find the next upgrade and an exciting climax ending in a mad dash to escape before everything exploded around you.

Wii Sports

Image courtesy of Fusion Gamer and IGN

Things were changing. Consoles kept pushing for better graphics and more power to produce the same kind of games that we’d already played many times over but this time in high definition. Meanwhile I was starting to settle down, just moved in with my then girlfriend (now wife) and was getting bored of the same kind of gameplay experiences. Enter the Nintendo Wii and the one game which, although not the greatest by a long shot, explained precisely what the Wii was about: Wii Sports.

There isn’t really much to say about it; it’s simply a collection of mini-games focused on tennis, boxing, bowling and golf but it’s the way you play them using the Wiimote and motion controls that makes it different. No other console had done motion controls like this, or at least this simply before; even my wife wanted to play games with me – and somehow she can still beat at boxing every time! For it’s time the Wii was a breath of fresh air to me because it made games fun again.

Super Mario Galaxy

Image courtesy of Super PolyPixel

I bought a Nintendo Wii because it was the perfect party games machine which would get my friends involved but also for another reason; I’m a hardcore gamer at heart and wanted to play proper Nintendo games again. And Super Mario Galaxy was the next game I got for it.

In essence it evolves the formula laid down years ago by Super Mario 64; Mario collects stars to open more levels, fights Bowser, saves Princess Peach (again!) etc. etc. But this time in space! Which actually opens up new ideas because gravity plays a part now; Mario could literally run around a small planetoid and not fall off it, or jump to a nearby object to fall into that gravity well. Once again I was amazed with the ingenuity of Nintendo who never seem to run out of creative ideas.

I also distinctly remember this as one of the few games where I didn’t have to battle with the camera controls; the fact that you could manoeuvre Mario in all kinds of planes made me think this would be awkward but I can’t remember a time where things got in the way, the camera just followed him almost perfectly.

World of Goo

Image courtesy of Edge

This most recent generation of consoles brought something new to the mix; having internet connectivity meant that games could be downloaded to the console for the first time ever. World of Goo was my first ever downloaded, unboxed game.

To describe World of Goo is a bit difficult. Essentially it is a puzzle game where you have to connect goo balls together into structures and help the remaining goo balls to escape the level via a pipe – sounds similar to Lemmings, doesn’t it? But the game as a whole is far more than that; it has an artistic vision to it, playful and not taking itself too seriously. There is something of a plot even, told via signposts you see in each level, though not strictly a linear story, more based around themes than anything else. And it has an amazing soundtrack.

The problem in describing this game is that my basic words don’t do it justice; I think it is simply one of those games you have to experience for yourself.

Metroid Prime Trilogy

Image courtesy of Pure Nintendo

One regret I had in never owning a Gamecube was that I never got to play Metroid Prime, a game that so many people had misgivings about (“Metroid in 3D? In the first person? Impossible!”) yet was actually critically acclaimed and ended up being one of the best games on that system. Fortunately I did get to play it on the Wii, plus it’s two sequels and with enhanced motion controls, all in one package.

In terms of adventure I felt that Metroid Prime was better than Super Metroid. It had the same atmosphere of Super Metroid and the same sense of adventure but felt much more immersive. The addition of the scan visor also meant that plot details could be viewed (or not if you didn’t want to), so you would read journal entries from the enemy describing how “The Hunter” (a.k.a. you) was slowly infiltrating their bases. And I thank Nintendo for adjusting it to use the Wiimote and create a real first-person control scheme.

Metroid Prime 2: Echoes was the Gamecube sequel and followed in roughly the same footsteps as Prime but introduced that old gameplay staple of the “dark world”: splitting the world into both light and dark  meant double the size of the levels and some ingenuity of puzzles. Personally I found this game difficult; I still enjoyed it but every time you entered the dark world it would sap away at your health, forcing you to find shelter in special “safe zones”. This meant things were more tense when you’re trying to escape enemies whilst also desperately trying to find the next safe zone. Plus there were some sections which almost had me pulling my hair out in frustration; in general, it was harder than Prime.

Metroid Prime 3: Corruption was the true Wii sequel to the trilogy and it showed; designed completely with the Wiimote in mind it added certain actions like flicking the nunchuk in a whip-like fashion and using the Wiimote in certain situations by having to twist it this way and that, plus the graphics were much improved. Overall it was a solid sequel and altogether one of the best deals I’ve purchased.

The Legend of Zelda: Skyward Sword

Image courtesy of G4

And so to my most recent game which I’m still trying to complete after a year! (Not because I’m bad but trying to find the time to devote to it is tricky for me now).

There is one reason why this game is great: pretending the Wiimote is a sword, like everyone imagined they would do when they first heard about the Wii. Swinging in a particular direction makes Link swing exactly the same way, which actually adds some strategy to the usual hack-and-slash action. For instance, I could swing horizontally but the enemy could block that direction; only a vertical attack would work. Things get interesting when enemies keep dodging and blocking your attacks forcing you to adapt as well.

Apart from the sword your other items have motion controls too; swing you Wiimote like a whip to use the whip, pull back your bow string as you would expect, push your shield hand forward to perform a shield bash attack, and so on. Finally Nintendo made good on their promise of motion controls being the future.

The End?

And that’s my life so far. Like I mentioned in part 1 I’m not sure I’ll be able to keep playing lengthy games anymore, partly due to lack of interest and partly due to time constraints. I’ve got a few games on my phone which may be more manageable, but I’m guessing I will now wait until my children are old enough to want to play computer games too before I start again.

Friday, 14 December 2012

My Life in Computer Games: Part 2

This is a series of posts which chronicles my life as measured by the computer games I’ve played; you can find the first part here. Let’s continue the journey…

Perfect Dark

The N64 was starting to run out of steam but, like every console at the end of its lifecycle, it had a few last gems to dish out. One of them was Perfect Dark, the spiritual successor to Goldeneye.

It was basically the same kind of gameplay that Goldeneye introduced but in a different setting and tightened gameplay; it still had the mission difficulty of its predecessor but crammed in so many more features, allowed you to play in a higher resolution (640 x 480!) and even had voice samples – even if the voice acting was terrible at least it added a bit more to the atmosphere having guards complain about being shot.

Once again though the multiplayer was where it truly shined, not only by adding more weapons and options but by adding bots, allowing up to 12 players at once – 4 human, 8 computer controlled. This really changed the pace of the matches; Goldeneye had a more measured, strategic pacing but because Perfect Dark bots never stood still for longer than a second you always had to be on the run making things a bit more frantic; it is how I imagine PC multiplayer games like Doom and Quake to be.

Banjo Tooie

Image courtesy of Wallpaper Pimper

In 1998 Rare released they’re take on the 3D platformer, Banjo-Kazooie. I loved that game but I have far fonder memories of it’s sequel Banjo-Tooie (despite the ridiculous name).

Whereas the first game had big worlds to play in, this one had massive worlds; when playing through the first level I thought it would be a bit bigger, but when I got to the highest point and looked down I could see everything before me! That must have been quite an achievement for the N64. Not only were the levels huge but they were interconnected; unlike other games where each level/world was it’s own distinct area, this game connected each level at strategic points to give the illusion of it being a far bigger world. In fact some of the games puzzles relied on having to move about between levels; Chuffy the Train is one example.

Banjo-Kazooie also tried to have it’s own “Lock-on Technology” moment by introducing “Stop ‘N’ Swop”, the idea being that once you finished the first game you could unlock secrets that would carry over to the sequel, though it never really worked out in the end. Banjo-Tooie did make reference to it but it was entirely self-contained in it’s own game. Shame.

Metal Gear Solid 2

Now this is a bit different! I never actually owned this since I never had a PS2 but my friend did and we spent ages playing through it. I had seen trailers of it and it looked amazing! Everyone was hyping this game up. So when we started it instead of playing as the legendary Solid Snake we had… a girly, floppy haired man with girlfriend issues. Eh?

It turns out it was all part of a ruse. All the E3 trailers showed Solid Snake back on form but actually the focus was not on him for most of the game: only if when starting a new game did you say you never played the original (like we hadn’t) did you skip the well know tanker part and instead went straight to the meat of the game playing as new spy Raiden. I can kind of understand it now; by changing the perspective you see the most important character in a new light. Still, it left me and my friend a bit perplexed initially, especially when I told him there was a whole other part of the game that he hadn’t experienced.

Nonetheless it was a really great game. The graphics were fantastic, the stealth gameplay excellent, the boss battles massively over the top and the cutscenes well presented, even if on the long side – I’m sure half the game was devoted to just watching it. My highlight though was towards the end when the game tried to play tricks on you, suggesting you “turn the console off now” or the “Fission Mailed” screen; for a game which played it straight most of the time it left us a bit shocked as to what to do.

Half Life

“They’re waiting for you Gordon, in the test chamber…”

Image courtesy of Giant Bomb

I was never really into playing PC games as it seemed each game I bought required a brand new set of hardware, which gets expensive quickly. But a few have caught my eye throughout time and this was one them.

Half Life tells the story of a scientist who has to escape the confines of a research facility once an accident happens and aliens start arriving. So far, so typical science fiction. What made this PC shooter stand out from the others though was it’s narrative and the fact that you were part of it; no cutscenes, no ever seeing what Gordon Freeman looked like, everything was played from your perspective.

There were also no levels, instead the entire facility was a level. The opening sequence demonstrated this brilliantly; as you were heading to work on the tram system you would see everyone else going about their jobs, passing through security sections, watching things move about. Despite the aging graphics it felt real, like this was a fully functioning place.

The enemy AI was fantastic too. Initially you met various aliens which felt reminiscent of Doom but eventually you met the Marines who were really smart; it took a lot of clever thinking to outsmart them sometimes.

Start Wars: Jedi Knight II

There have been a bazillion games based on Star Wars but how many of them can you remember that were even slightly good? This one, in my opinion, was one of the best because finally I could be a Jedi; not doing goody-goody two-shoes tasks like diplomacy like the prequel films would have you suggest, but doing what all kick-ass Jedis do by hacking and slashing Stormtroopers with a lightsaber.

Overall I just liked this game; the force powers were focused and the lightsaber duals were fun. The initial few levels forced you to play with weapons which was a shame but it was the lightsaber that stole the show.

Halo: Combat Evolved

Image courtesy of Pocket-Lint

A new kid came on the block; Microsoft thought they could do this video games thing just as well as Sony and Nintendo so invented the XBox, a huge black console which would leave a legacy. But every console needs a “killer app” to sell units, especially one that no-one had ever heard of, and that is what Halo became.

Lots of people played it for its multiplayer but I played it for its engaging story, the clever AI and most importantly its co-operative play. Me and a friend played through the co-operative game religiously and for once it made a difference; it wasn’t just about who could shoot more enemies but it helped with your strategy and we both looked for each others backs. It also has one of the best climatic endings for a game I’ve seen.

Half Life 2

Image courtesy of Voodoo Extreme VE3D

I played this version on the XBox and thought it was a great sequel to the original. The scope expanded from the Black Mesa facility to City 17, an unknown European city where the remaining humans were being rounded up by the invading alien forces. The opening in this game worked in a similar vein to the original, but this time focused on the humans milling around, listless and hopeless.

The real star of the show though was the physics and infamous “Gravity Gun”. This was probably the best weapon in the game yet didn’t fire a single bullet: instead it let you pick up nearly any object and fling it with force and anything you wanted. The Ravenholm section was the best example of this: flinging buzzsaws at the zombies and slicing them in half never got boring.

I also really liked the technology powering the game; having the characters watch you and lip synch perfectly was quite something I thought.

Next Time

The last part focuses on recent years, particularly the Wii. Stay tuned!

Friday, 30 November 2012

My Life in Computer Games: Part 1

I’m coming to a realisation that has slowly been dawning on me for a while now: I’m going to give up playing computer games. For someone who has been playing them since childhood that’s quite a big thing to say, but it is for several reasons.

First and foremost I do not have the time anymore. I’ve got a full-time job and a family to support so free time for me is extremely precious. I’m currently playing The Legend of Zelda: Skyward Sword, but I’ve been doing that since Christmas 2011! And I still haven’t finished! So far I think I’ve clocked up about 40 hours gameplay time but that is very much spread out across a year, playing maybe a couple of hours a week at best. Finding the time for anything more involving than Angry Birds is simply difficult these days.

But it’s not just a matter of finding the time anymore, I actually don’t feel that bothered about computer games anymore. In the limited free time I have left I would rather actually be doing something constructive (such as writing this blog) and learning more about programming. I’m still interested in how computer games are made – I found the code reviews that Fabien Sanglard did on the Quake and Doom game engines really interesting – and I still appreciate them – I think Halo 4 looks amazing. But playing them? Meh.

So I thought I would make a list of all the memorable games I’ve played during my life so far and reminisce, which is going to span a few posts.

The ZX Spectrum

When I first asked my parents for a computer to play computer games I thought I would be getting a Nintendo or a Sega console. Instead what I got was a ZX Spectrum +2, so not quite what I was expecting.

In the end it did shape my entire career by introducing me to programming, but as a game machine all I remember was having to load tapes which took minutes – and also provided a lovely whining noise and hallucinogenic loading screen – only for me to play it for 30 seconds and give up because I didn’t find it entertaining. Maybe the next one will be better… (wait another 5 minutes to load the next tape).

A ZX Spectrum loading a program. Wow, my head hurts…

So I gave up on the Spectrum and got myself a Sega Master System, which then led to a Sega Mega Drive, which then led to…

Sonic the Hedgehog

Back in the 16-bit days you were either with Nintendo or Sega, Mario or Sonic. I chose Sonic and have many happy memories of those games, because they were fast!

Sonic the Hedgehog 2 was my personal favourite, the video above showing one of my favourite levels due to the sheer speed you can crank up to – so fast that the screen sometimes can’t even keep up with you!

But the real gem of the series was Sonic 3 and Sonic & Knuckles. Both individual games on their own were great, but the “lock on” technology that Sonic & Knuckles brought made them combined into an amazing experience – extending the Sonic 3 game, or by joining Sonic 2 to it you could turn an old game into a brand new experience.

Recently I actually wondered how they even did the “lock on” bit; how do you turn one game into three games? And how do you take an old game which wasn’t even designed for this kind of thing and make it into what is effectively a brand new game? Turns out that actually it was a clever ROM trick, by joining ROM chips together to make a new one; this long forum post explains it in far more detail.

The 32-bit Years

After the Mega Drive I got a Sega Saturn – not sure why in retrospect and not a PlayStation which was the latest hotness at the time. There were some good games such as Sega Rally and NIGHTs Into Dreams but this was the advent of 3D graphics and things were just starting out. One game caught my attention though which made me rethink everything…

GoldenEye

Need I say more? Oh, alright then

I remember going round to my friend’s house and they were playing GoldenEye. I had a go – the Nintendo 64 controller looked a bit weird to hold – but I started playing it and I realised quickly that I was completely hooked on the multiplayer. Every console before the N64 supported two players but this one could support four, meaning that multiplayer shooters actually made sense outside of a PC.

So I got an N64 with GoldenEye as my first game for it. The single player missions were great with lots of challenges added as the difficulty ramped up, but my single defining memory of this game was spending nearly all my free time between A-Level lectures playing deathmatch games against my friends. And beating them. Over and over again.

Super Mario 64

Now that I had a N64 I wondered what other games to play on it, so of course I got the N64 killer app: Super Mario 64.

Now before then I hadn’t actually played a Mario game before but this game was great. I remember just wandering around the castle hub-world doing all sorts of acrobatics simply because I could and the analog stick finally let me move around in 3D which made sense. Although I have to admit the camera controls did suck.

Throw a dinosaur four times my size into a bomb? No problem!

I also came to realise that games that Nintendo made really were top quality; they were fun, inventive and imaginative.

The Legend of Zelda: Ocarina of Time

This game came out during Christmas 1998 and was snapped up by just about everyone at the time. I was very lucky to get this on Christmas Day and spent the next two weeks solid becoming immersed in it.

Just like Mario I had never played a Zelda game before so I never experienced the sense of adventure previous games conjured up, and this did feel like a real adventure. It introduced concepts like “locking-on” to your target during combat so you could always see them (something every game afterwards copied) and split the world into two times: current and future, meaning you played as Young Link and Adult Link. And you got to ride a horse!

Looking back I simply remember the variety of the gameplay, the sense of scope (looking into the distance at the volcano or riding across Hyrule field), and the final climatic battle with Ganondorf.

The Legend of Zelda: Majora’s Mask

The sequel to Ocarina of Time, this was like a Zelda game and also not like one at the same time. With the benefit of hindsight I think this had a lot more emotional depth than Ocarina.

The main selling point of this game was that you had to save the world from destruction in just three days (game-time, not real), but of course you couldn’t do everything in that kind of timeframe. This meant that a “Groundhog Day” concept was used: you could relive the same three days over and over again to make progress and also watch the lives of each inhabitant of the world happen over and over again, making notes of key points in time when they would do certain actions. It was a bit harder than Ocarina and there was an added sense of urgency (what with an evil-looking and ever looming moon constantly visible in sky) but still worth playing.

That doesn’t look promising. Image courtesy of http://www.ogeeku.com

The emotional depth I mentioned though was something I wasn’t expecting; every character had a backstory and it was your job to help them. One little girl’s father had turned into a monster yet she tried to shield him from the world to protect him. A baby had lost his father and brought depression to everyone around him. Probably the most poignant one was having to re-unite a wife and husband – the longest of all the side quests; you eventually did but only just in time, by which point the moon was nearly about to crash into the world – you brought them back together long enough for them both to properly say goodbye to each other. This adventure was not about stopping a singular enemy, rather it was about healing the wounds of the people of the world.

Next Time

There’s still a lot more to go, so stay tuned for the next part.

Monday, 24 September 2012

Becoming a Father: One Year On – Part 4

This is the fourth part of my retrospective on my first year as a new father – though I’m starting to lag behind a bit now as my son is now nearly a year and a half old!

To view all the parts, please click on one of the links below:

  1. The Beginning
  2. The First Two Weeks
  3. Getting the Hang of Things

This post focuses on…

The Accident

Looking back now, the first six months of my son’s life were actually quite uneventful. I would hear stories of his little friends picking up bugs and colds but he seemed as healthy as you could hope, which is something to be thankful for. He never had so much as a sniffle. When he was around 7 months old though he would be paying a visit to the hospital.

One morning my wife was carrying him down the stairs when she lost her footing and slipped, sliding on her back down several of them. It left her a bit bruised and for an adult that would kind of be the end of it – just shrug it off, since it wasn’t that serious – but my son was crying uncontrollably. We couldn’t figure out why as we checked him all over and couldn’t see any marks or bruises anywhere, but he simply wasn’t himself. Our initial thought was that the incident was too much of a shock for him, but after about an hour our instincts told us to get him checked out. As this was a Sunday calling the doctor was out of the question, so a trip to A&E it was.

After waiting for hours that afternoon we had several doctors check him out and the overall conclusion was that he was just in shock still. We did consider maybe a broken bone but pressing on any part of him seemed to illicit crying so no-one could tell. In the end we took him home and gave him Calpol to help him sleep through the night.

The next morning while I was at work my wife texted me to say she was taking him to our GP to get him seen again as he still wasn’t right, who then referred him back to the hospital to get an X-ray on his right leg. Around 4pm I got a call saying that he had a hairline fracture on his right femur and would need to be put in traction, which meant of course staying in the hospital. And that was the start of the week-long “holiday” on the children’s ward.

I left work early to run home and pick up a few overnight things for my wife and son and went straight to the hospital to see them. He was on baby morphine to help him with the pain and still was not himself. My wife was now constantly blaming herself for a) inflicting this on him, even though it was an accident that she could not have prevented, and b) not spotting his broken bone sooner, despite not having X-ray vision herself.

I watched him as the nurses put him in traction, basically by lying him in bed and wrapping bandages and splints around both legs then tying them to pulleys hanging above his bed; the aim was to keep the leg straight so that it would heal faster – there is no magic cure for broken bones, you simply have to let your body heal itself. Fortunately it was only a hairline fracture and, given his age and constant body development, he would heal a lot faster than an adult (he was well on the mend in a week, whereas it might take me months to heal the same wound).

I stayed with them for a few hours before leaving them for the night; my wife would be staying with him around the clock whilst I would still have to go to work each day. That night was actually the first time ever that I was separated from my son; as I walked past his bedroom at home that night I looked into it and it was empty for the first time, which made me feel more alone that I expected.

The Sleepover

So far it is all sounding doom and gloom, isn’t it? Well let me reassure you by showing you what my son looked like for the rest of the week.

As you can see after his first night in hospital he was pretty happy with life. And wouldn’t you be when you have toys surrounding you in your bed and CBeebies on tap? If anything it was harder on my wife, which I will get to.

As I still had to do my day job I was responsible for ferrying items to and from home for them and visiting them first thing in the morning before work and straight after work before going home. I would then get the luxury of sleeping at home, ready to start the routine all over again.

My wife on the other hand stayed with our son 24/7. He got a room on the ward meaning my wife could sleep on a sofa-bed with him. For five days in a row she lived on the ward with him. By the fourth day she was almost at breaking point and when the weekend finally came so I could take over she vomited on the way home through sheer exhaustion. When I did my weekend shift straight after work on the Friday night I could finally understand what it was like; the ward was never truly quiet, always having staff roaming around and coming in to do observations on my son, day and night. There was even another child on the ward who sounded a lot worse than our son; I would periodically hear uncontrollable screaming from down the corridor, so I don’t know how that child’s parents managed to survive.

But we did it for him because as parents that is simply our job; to put him before ourselves. And he seemed to be having a whale of a time, getting visits from his grandparents regularly and only getting bored now and again. Let’s face it, he could have been a lot worse.

Coming Home

After just over a week (and my wife having a weekend of sleeping at home while I took over) he finally got discharged. He was also getting sores from the bandages on his legs so had to come out of traction anyway but his leg had almost healed completely, we just needed to be careful how we positioned it and keep him on his back. My wife took him for check-up X-rays and a month later he was given the all clear.

In fact now we forget that it ever happened. He is so active and runs around all over the place that it is hard to imagine that his leg was ever broken; people even now ask us how his leg is and we have to think for a second as to what they mean.

Plus, as the doctor at the hospital pointed out to me, it is safe to assume that this will be the first of many accidents he may experience in his lifetime as kids will always get into scrapes in their continual quest to have fun.

Next time: One Year Old…

Friday, 14 September 2012

Testing Framework Review: xUnit.net

In a previous post I reviewed NUnit. For my last post in this series I will focus on xUnit.net. xUnit.net is a newer open source framework that is gaining some traction. From the xUnit.net website on CodePlex:

xUnit.net is a unit testing tool for the .NET Framework. Written by the original inventor of NUnit, xUnit.net is the latest technology for unit testing C#, F#, VB.NET and other .NET languages. Works with ReSharper, CodeRush, and TestDriven.NET.

xUnit.net is a developer testing framework, built to support Test Driven Development, with a design goal of extreme simplicity and alignment with framework features. It is compatible with .NET Framework 2.0 and later, and offers several runners: console, GUI, MSBuild, and Visual Studio integration via TestDriven.net, CodeRush Test Runner and Resharper. It also offers test project integration for ASP.NET MVC.

xUnit.net is even used internally by some high profile Microsoft projects such as:

Integration

xUnit.net is a separate project meaning that direct Visual Studio integration support is not provided. However Visual Studio 2012 will allow different frameworks apart from MSTest to be used as the primary unit testing framework – this includes TFS builds too.

In the meantime, the following steps are required:

Download from NuGet

NuGet provides three packages for xUnit.net:

Adding these packages to a Visual Studio project is very simple as NuGet will automatically download the latest versions and insert the correct project references required.

Project Items and Snippets

Unlike MSTest which provides project items and snippets with the IDE, xUnit.net does not provide any by default. However these items are not difficult to create yourself if required and the CodePlex project page even explains how to create snippets for xUnit.net.

Standalone

Although some initial setup is required one possible benefit is that xUnit.net is a standalone framework – it can be run anywhere without requiring installation, simply by copying the correct files.

Team Build

TFS 2012 will be able to use the same Unit Test plugin model that Visual Studio 2012 uses meaning in the future it will be a lot easier to integrate xUnit.net into the Team Build process.

Until then though it is possible to use xUnit.net within Team Build but only via a custom build activity and translating the xUnit.net XML output into MSTest results. This webpage explains how it is possible to do it, though the process looks quite longwinded to me.

Writing Tests

Tests are written like this in xUnit.net:

   1: using System;
   2: using System.Collections.Generic;
   3: using System.Linq;
   4: using System.Text;
   5: using Xunit;
   6: using Xunit.Extensions;
   7:  
   8: namespace SampleCode.xUnit
   9: {
  10:     // Classes do not require attributes, xUnit.net does not care
  11:     public class CalculatorTests
  12:     {
  13:         // A "fact" is a test without any parameters    
  14:         [Fact]
  15:         public void Add_AddOneAndTwo_ReturnsThree()
  16:         {
  17:             var result = Calculator.Add(1, 2);
  18:  
  19:             // Many asserts are provided by default, API style is simple and concise
  20:             Assert.Equal(3, result);
  21:         }
  22:     }
  23: }

There are a much wider variety of assertions provided by xUnit.net by default compared to MSTest. A full list can be found here.


Data Driven Tests


Data driven tests in xUnit.net are known as theories. They are test methods that have parameters and can accept input from a number of sources. A theory looks like this:




   1: [Theory]
   2: [InlineData(1, 2, 3)]
   3: [InlineData(3, 4, 7)]
   4: [InlineData(30, 10, 40)]
   5: public void Add_AddDataValues_ReturnsExpectedResult(int first, int second, int expected)
   6: {
   7:     var actualResult = Calculator.Add(first, second);
   8:  
   9:     Assert.Equal(expected, actualResult);
  10: }

Out of the box xUnit.net can accept input from the following sources:



  • Inline data
  • Property data
  • Excel spreadsheet
  • OleDb connection
  • SQL Server database

Running Tests


Until Visual Studio 2012 comes out xUnit.net tests cannot be run directly via the IDE but there are a number of other options available.



The console runner is the most basic test runner available and works from the command line.



The GUI runner is a simple standalone application with it’s own user interface and is not as full featured as the NUnit GUI runner but is capable enough. Instead of a tree view like the NUnit GUI runner this test runner presents a flat list of tests but they can be filtered down by search terms, assembly and/or trait values.


One aspect that is different from the NUnit GUI runner is that although this runner will detect and reload test assemblies when rebuilt it will not automatically run the selected tests again, unlike NUnit.


MSBuild


Unlike MSTest and NUnit, xUnit.net provides it’s own custom MSBuild task which allows direct integration into the build process. A project file can then use it similar to this:




   1: <UsingTask 
   2:     AssemblyFile="..\packages\xunit.1.9.1\lib\net20\xunit.runner.msbuild.dll" 
   3:     TaskName="Xunit.Runner.MSBuild.xunit" />
   4: <Target Name="AfterBuild">
   5:     <xunit Assembly="$(TargetPath)" />
   6: </Target>

Build output then looks similar to the following:


------ Build started: Project: SampleCode, Configuration: Debug Any CPU ------
SampleCode -> C:\TalentQ\Experiments\UnitTestAnalysis\SampleCode\bin\Debug\SampleCode.dll
------ Build started: Project: SampleCode.xUnit, Configuration: Debug Any CPU ------
SampleCode.xUnit -> C:\TalentQ\Experiments\UnitTestAnalysis\SampleCode.xUnit\bin\Debug\SampleCode.xUnit.dll
xUnit.net MSBuild runner (32-bit .NET 4.0.30319.269)
xunit.dll: Version 1.9.1.1600
Test assembly: C:\TalentQ\Experiments\UnitTestAnalysis\SampleCode.xUnit\bin\Debug\SampleCode.xUnit.dll
Tests: 4, Failures: 0, Skipped: 0, Time: 0.041 seconds
========== Build: 2 succeeded or up-to-date, 0 failed, 0 skipped ==========

The MSBuild task can be configured like the console runner meaning that XML/HTML results can also be saved too. See the documentation for more details.


Another useful thing is that, because it integrates into MSBuild, any failed tests will appear as errors in the IDE error list so by definition this would make it a failed build. The only slight oddity though is that, in its current form (version 1.9.1), double-clicking the errors in the error list does not take you to the correct source code as line numbers given are referring to the project file not source files.


Additional Runners


xUnit.net also provides these test runners as standard:



Performance


Performance of running tests seems to be faster than MSTest, even with a significant number of tests to execute.


Reports


Apart from the output represented by various test runners, an XML report can be produced by either the console or MSBuild runner. Once in an XML format, this can then be transformed into another format, e.g. a HTML file to make it human readable or a *.trx (MSTest) output file so that Visual Studio can understand it.


Fortunately xUnit.net is able to do this transformation for you as long as you provide the XSLT stylesheet to use. Out of the box the following stylesheets are provided:



  • HTML – transforms the XML report into a HTML, human-readable report
  • NUnit – transforms the XML report into the same format that NUnit uses

Documentation


This in my opinion is where xUnit.net falters. Because this is a newer framework documentation is thin on the ground, especially when compared to NUnit. Usually though the features are simple enough to figure out and there is sample code provided in the CodePlex repository, but you may also have to do some searching around on the internet for an explanation of some things.


Extensibility


One of the big selling points of xUnit.net is its extensibility which is far greater than either MSTest or NUnit. Some examples are:


Report Transformations


By default the console runner can provide XML, HTML or NUnit report output, but this is actually configurable by defining further command line switches mapped to a suitable XSLT stylesheet to transform in into another format (e.g. *.trx (MSTest) format).


xUnit.net Extensions


The entire xUnit.net extensions assembly is a perfect example of its extensibility. For instance [Theory] methods are actually specialised [Fact] methods that do some additional work.


More Assertions


If there are not enough assertion functions for your liking you can implement more by extending the Assertions class rather than having to write your own wrappers for it. For example:




   1: public static class MyAssertions 
   2: {
   3:     // By using extension methods you can add more assertions
   4:     public static void Test(this Assertions assert)
   5:     { 
   6:         Assert.True(true);
   7:     }
   8: }
   9:  
  10: // By deriving from TestClass a modifiable Assert class becomes available 
  11: public class CalculatorTests : TestClass 
  12: {
  13:     [Fact]
  14:     public void CustomAssert()
  15:     {
  16:         // This is our own assertion method
  17:         Assert.Test();
  18:     }
  19: }

My Opinion


This is a tricky one. Whereas I felt that NUnit was miles ahead of MSTest, the difference between NUnit and xUnit.net is a lot smaller. To be fair you could pick either one and be extremely productive so it all comes down to nit-picking.


Both NUnit and xUnit.net have their benefits and each have a few disadvantages but in the end, after much careful thought, I’ve decided to use xUnit.net as my primary test framework for the following reasons:



  1. I like the fact that XSLT stylesheets are provided with the framework so I don’t have to define my own HTML report format based on the XML output. And if I wanted to change the layout of the report I would at least have something to modify as a base.
  2. Overall the MSBuild task is a great way of integrating xUnit.net into the build process. Whereas MSTest and NUnit could be run as a task the fact was that they were just starting a new process; the only way you would know your tests had failed was by checking the exit code of the test runner, which wouldn’t tell you anything useful.
  3. The extensibility of framework is a real plus point. I haven’t needed to extend any features yet – consider that a testament to the basics it got right – but it’s nice to know that it is there if needed.
  4. Finally I just feel that it has a lot of potential. It may have some niggles to iron out but I feel confident that they will be.

All of the above are very minor points; like I said I could have just as easily went with NUnit, but xUnit.net just edged ahead in my opinion.

Sunday, 26 August 2012

Testing Framework Review: MSTest

Recently I wrote about what I learned from Test Driven Development (TDD) and for the most part glossed over the issue of which testing framework to use. In that post I said that I didn't like MSTest and ended up preferring xUnit.net, but was I too quick to judge? Was that a snap decision? Had I really investigated all the features of each framework?

As I am the sole TDD knowledge base at work currently I was also asked to write up an objective analysis of each the major frameworks that I was considering. I therefore thought this would be a good opportunity to share my findings to the world in case anyone else found them useful.

So I shall write three new posts giving my full review of the following .NET test frameworks I looked at and tried out: MSTest, NUnit and xUnit.net. I'm sure there are others out there but these were the ones I kept seeing through internet research on a regular basis. I shall try and present the facts as best I can but you will also see my opinions sprinkled throughout.

This first post will be focused on...

MSTest

MSTest is the testing framework from Microsoft and is built into some previous versions Visual Studio but is included as standard with Visual Studio 2010, which is the version I will be referring to from here on out. You can see the reference documentation here.

Integration

Because MSTest is built into Visual Studio itself, integration between Visual Studio and MSTest is very tight. Straight from the IDE you can:
  • Create a test project
  • Create a test class
  • Use code snippets provided to define a test method
  • Run tests using commands/shortcuts and view the results in an IDE tool window
  • View report/result files.
Also, TFS 2010 has the option built-in to run MSTest assemblies as part of a Team Build process and it understands the MSTest result file format so it can be included in the build output.

A possible downside of deep integration though is that MSTest cannot run standalone without Visual Studio installed, unlike other frameworks. For instance, if a Continuous Integration (CI) build server were set up you would have to install the entire IDE just to use MSTest. It is possible to just find the necessary assemblies required for MSTest to force it to be standalone, as this blog post describes, but you would also have to fiddle around with the registry to include certain references which could be more painful than it is worth.

Writing Tests

So what do unit tests look like with MSTest? Here is a simple example:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace SampleCode.MSTest
{
    // Denotes a Test Class for MSTest to look for
    [TestClass]
    public class CalculatorTests
    {        
        // Denotes a Test Method for MSTest to run
        [TestMethod]
        public void Add_AddOneAndTwo_ReturnsThree()
        {
            int first = 1;
            int second = 2;

            var result = Calculator.Add(first, second);

            // MSTest assertion
            Assert.AreEqual(3, result);
        }        
    }
}

MSTest provides several assertion methods via the Assert class, though it does not seem as feature complete as other frameworks.

Methods provided are:
  • AreEqual
  • AreNotEqual
  • AreSame
  • IsInstanceOfType
  • IsNotInstanceOfType
  • IsNull
  • IsNotNull
  • IsTrue
  • IsFalse
There are also specialised StringAssert and CollectionAssert APIs.

Exception assertions must be done using the [ExpectedException] attribute. Other frameworks have moved on from this approach, making MSTest a bit antiquated in this area. Below is an example of how to test that something has thrown an exception:

[TestMethod]
[ExpectedException(typeof(ArgumentNullException))]
public void ExceptionTest()
{
    TestMethod(null);
}

It is possible to make your own assertions but you will have to define your own Assert class to provide additional assertions. For example, this blog post explains how to define an Assert.Throws() method to replace the clunky syntax for exception checking shown above for a more functional, fluid approach.

Data Driven Tests

Originally I thought that MSTest was not able to use data driven tests - that is tests which require input from an external source - but I was wrong. MSTest does support data driven tests but not in the same way as most other frameworks.

Below is an example of such a test:

[TestMethod]
[DataSource("Microsoft.VisualStudio.TestTools.DataSource.CSV", "|DataDirectory|\\Add_DataDrivenTestCases.csv", "Add_DataDrivenTestCases#csv", DataAccessMethod.Sequential)] 
[DeploymentItem("SampleCode.MSTest\\Add_DataDrivenTestCases.csv")]
public void Add_DataDriven_ReturnsCorrectResult()
{
    var first = Convert.ToInt32(TestContext.DataRow["First"]);
    var second = Convert.ToInt32(TestContext.DataRow["Second"]);
    var expectedResult = Convert.ToInt32(TestContext.DataRow["Result"]);

    var actualResult = Calculator.Add(first, second);

    Assert.AreEqual(expectedResult, actualResult);
}

Note the following:

  1. MSTest does not support parameters in test methods like other frameworks do.
  2. A [DataSource] attribute is used to define where the input data comes from. This example uses a CSV file but XML and databases are supported too.
  3. Because parameters are not supported, all data input has to be extracted from a TestContext class (which you have to define yourself). Getting each column of the file actually returns an object, meaning you have to do yet more work to convert values into something meaningful.
In comparison to other frameworks (which I will highlight in future posts) this feature feels incredibly clunky to me. I used Visual Studio's IDE tools to auto-generate this test method for me as I doubt I would remember the syntax for it each time. It should also be noted that you cannot have inline data - that is data defined as constants such as what NUnit supports.

Running Tests

Running tests in MSTest is incredibly easy. Simply right-click in a test code file and click "Run Tests" for the Test Window to appear, such as below:



From this window you can view detailed results of each test.

For a data-driven test, only one row appears in this window yet it is run multiple times for each row in the data source, which can appear confusing. Viewing the detailed results of a data-driven test will show the individual results though.

It is also possible to run MSTest via an MSBuild task, e.g. as an after-build step. This is done by simply executing the MSTest console application using the <Exec> task like this:

<Target Name="AfterBuild">
    <Exec Command='"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\mstest.exe" /testcontainer:"$(TargetPath)"' />
</Target>

Build output then appears as follows:

------ Build started: Project: SampleCode.MSTest, Configuration: Debug Any CPU ------
  SampleCode.MSTest -> C:\Experiments\UnitTestAnalysis\SampleCode.MSTest\bin\Debug\SampleCode.MSTest.dll
  Microsoft (R) Test Execution Command Line Tool Version 10.0.30319.1
  Copyright (c) Microsoft Corporation. All rights reserved.

  Loading C:\Experiments\UnitTestAnalysis\SampleCode.MSTest\bin\Debug\SampleCode.MSTest.dll...
  Starting execution...

  Results               Top Level Tests
  -------               ---------------
  Passed                SampleCode.MSTest.CalculatorTests.Add_AddOneAndTwo_ReturnsThree
  Passed                SampleCode.MSTest.CalculatorTests.Add_DataDriven_ReturnsCorrectResult
  2/2 test(s) Passed

  Results               Add_DataDriven_ReturnsCorrectResult
  -------               -----------------------------------
  Passed                SampleCode.MSTest.CalculatorTests.Add_DataDriven_ReturnsCorrectResult
  Passed                SampleCode.MSTest.CalculatorTests.Add_DataDriven_ReturnsCorrectResult
  Passed                SampleCode.MSTest.CalculatorTests.Add_DataDriven_ReturnsCorrectResult
  3/3 test(s) Passed

  Summary
  -------
  Test Run Completed.
    Passed  5
    ---------
    Total   5
  Results file:  C:\Experiments\UnitTestAnalysis\SampleCode.MSTest\TestResults\petermonks_ACHILLES 2012-08-14 10_42_21.trx
  Test Settings: Default Test Settings
========== Build: 2 succeeded or up-to-date, 0 failed, 0 skipped ==========

Performance

Performance of running tests seems a little slower than other frameworks as MSTest saves all results to file meaning IO time is consumed a lot. This didn't cause any problems with my simple test suite but this might be significant if hundreds of tests are being run at once.

Extensibility

Since .NET 4 and Visual Studio 2010, MSTest has been able to be extended to some degree although doing so is hard work. For example, this blog post explains how to extend MSTest to use inline data-driven tests that have parameters, such as:

[TestMethod]
[Row(1, 2, 3)]
[Row(4, 5, 6)]
public void ParameterTest(int x, int y, int z)
{
    // Test code here...
}

However from this post it looks incredibly long-winded to implement and setup, whereas other frameworks have this ability as a built-in feature.

My Opinion

So these are the facts I researched, what do I think about MSTest now?

Overall I am still of the opinion that I was right to not use it. Having tried other frameworks, which I will give my review on in future posts, I can see that MSTest is clunky to use and not as fully featured as other frameworks. The only Unique Selling Point I can see with it is that it is built into Visual Studio so it is easy to get started with it and integrate it with other Microsoft tools, something we do require at work as we want to use TFS Build to get test results. But seeing as Visual Studio 2012 is going to include the new Unit Test Adapters to allow other test frameworks to be used instead, even this is starting to become a moot point. 

I've also noticed that some open-source Mircosoft projects don't even use MSTest and use something else. Maybe it is because they are trying to keep everything self-contained in these projects, but I read it as not even some developers in Mircosoft would consider using their own test framework.

So MSTest isn't for me. Next time I shall review NUnit.