Reducing Unit Testing Friction…

June 26, 2008

Gears.jpgIt doesn’t matter if you’re a TDD purist or a test-as-you-go guy, having a quick way to execute the tests that you’ve created is critical to them actually getting run as regularly as they need to be. To that end, here is the current setup that I’m using to make this as easy as possible.

Everyone knows that I’m a sucker for a new tool but this tool has been with me for quite a while and I’m skeptical that anything will be able to replace it. TestDriven.Net is the foundation of a great workflow when it comes to unit testing and it’s truly worth the small amount that Jaime asks for his efforts. He’s a great guy and it’s a great tool – go buy it and install it immediately.
So now that you have it installed, there a couple of settings in Visual Studio that help make that test/code/test cycle even tighter.

Keyboard shortcuts

Once you have TestDriven installed, you’ll notice some extra options in the context menus when you right-click on class files, projects and even in code. These will allow you to run tests in various fashions but I’m a lazy man and I hate moving my fingers off the keyboard so I’ve added a few shortcuts to Visual Studio. In the options menu for “Keyboard”, I bind Control-1 to “TestDriven.NET.RunTests”, Control-2 to “TestDriven.NET.ReRunWithDefault”, and Control-3 to “TestDriven.NET.ReRunWithDebugger”. The way this helps me is that I am able to use Control-1 to execute the test that the cursor currently resides in (if you’re in between tests or on the fixture itself, it will run all in that fixture). If it doesn’t pass, I can hop over to the code that’s being tested, make the changes and then just press Control-2 to see if the test passes. No back and forth between the two. The last shortcut is helpful because it allows me to set a breakpoint where I am (using F9 of course) and rerun the test so that it will hit that breakpoint. Again, no back and forth.

Output window

Every time you execute a test, the tool bar will give you a quick look at the status but the output window will be your friend when things don’t quite execute as planned. All the output gets piped here but you don’t need it in your face so be sure that the “Show Output window when build starts” is unchecked but also be sure that you have it collapsed just below your code file. output window.jpg This way if you do have need to see what is in the output, you can just press Control-Alt-O and it will pop up with focus. (Pressing Escape will cause it to hide again and leave us in our code.)

I still haven’t quite figured out how to bind to the “Run All Tests” so if you have a suggestion, I’d love to hear it. However, I do still find it helpful that a “Run All Tests” will execute again when using the rerun shortcuts and I use that quite a bit right before commits. (If you’re not religious about running ALL tests before a commit, I hereby grant your co-workers permission to knee-cap you.)

Because unit tests only provide benefit when they are actually run, we need to do everything that we can to tighten the code/test loop and make executing the right thing at the rightht time as easy as possible.


David O’Hara is a Principal Consultant with Improving Enterprises in Dallas, Texas.

Advertisements

Announcement: NDDNUG – Automated Unit Testing

July 29, 2007

I’m going to have another chance to refine my “real world unit testing” talk. I’ll be presenting at the North Dallas .Net User Group this Wednesday (August 1) at 6:30pm. The topic will cover unit testing, dependency injection and mocks/stubs using NUnit and RhinoMocks. The talk is VERY demo intensive and should be fun as well as informative. You can sign up here to attend – the pizza is free and the talk will certainly be interesting.

UPDATE: Here are the files I used for my presentation: PowerPoint and source.


Automated Unit Testing with Visual Studio 2005 Presentation

June 15, 2007

The talk went pretty well – I believe there were about 175 people registered so it was quite a turnout. I didn’t have a chance to get thru to all of my demos but I think that I at least got folks started in the right direction. Sadly, the dependency injection portion of the talk took the biggest hit and it’s really the most important part, in my opinion, since it’s what allows you to deal with “real” code. Maybe that just means I’ll have to give the talk again. 🙂 Regardless, I’m posting the AUT PowerPoint and the solutions ZIP (this has the starting version as well as the completed version).

Thanks to everyone who showed up for the talk. Feel free to comment below and if you have pics or anything, please let me know. I’d love to see them.


Announcement: DDNUG – Automated Testing with Visual Studio 2005

June 6, 2007

Apparently, they’re going to continue to allow me to get up in front of people and talk since it turns out I’m not half bad at it. I’ll be presenting a the Dallas .NET User Group on June 14th so head over and sign up – the pizza is free and, at worst, you’ll get to laugh and heckle me. The talk is being billed as programmer testing since I’m not going to stick to strict Test Driven Development (I’ll explain why in the talk). I’ll cover the basics and principles as well as MSTest, NUnit, RhinoMocks, and TestDriven.Net. Heck, I may even grab someone and doing a quick round of the TDD Pairing Game if I’m feeling randy.

Once again, I’m a little nervous too but that’s what makes it fun. Hope to see you there.

UPDATE: I’ve posted here for the presentation content.


“Zany” About MbUnit…

January 28, 2007

It looks like Sean has been working hard on my FAVORITE unit testing GUI – Zanebug. He’s updated it to the latest version of NUnit (2.2.9) and added support for MbUnit tests (here’s a post with screenies). Now it really is “all that and a bag of chips”…. (did I really just say that?) Regardless, if you’re not using it as your test runner – you’re missing out big time. Guess I don’t have a reason to put off trying out MbUnit anymore.