Friday, April 17, 2009

Continues Integration with Team City

At Netdug last night the subject was continues integration with Team City, so I finally got the opportunity to see a continues integration server in action. As a demonstration the presenter had RoboDojo (created by David Star of Elegant Code) David committed a change to his project to on codeplex and with in a few minutes the project built, ran his tests, etc.

Inspired by this my project tonight was to set up Team City. The Installation was fairly simple, I set up my Sample Project, using the sln2008 builder output to a virtual directory in IIS so I can check the output for both the webforum and webservices. Everything just worked until I tried to get the mstest to run the unit tests. It kept failing to run the unit tests, but didn't tell me.

This bothered be a little, after searching online for a while I couldn't find anything but how to do it with msbuild, or with one of the other builders. Finally after playing around with the setting I found that I could get the mstests to run if I used an older nunit test runner that supported both nunit and msunit, and honestly I really like doing that way I only have one place to add test projects.

So what I was expecting to be a 30-60min project tuned into a 3 hour project, but in the end, it really wasn't that bad, the only major complaint I have now is that Team city is kind of a memory hog (it's written in java, go figure) so I don't think I can really run it on the same box I do development on, but it wasn't designed to.

My eventual goal is to do continues integration at work, but I think that's going to be a hard sell right now, so I'm starting off with built deployments, this way I can show the benefits of doing this, then work on getting continues integration. Now that I have the proof of concept done, I can give a realistic time line on how long it would take to set this up at work.

Monday, April 13, 2009

Rolling your own Mock Objects

One of the problems I have with doing unit testing is the mock objects. the principal is simple enough, I create an object that implements the interface I'm trying to mock, the only problem is I end up creating a least 2+ mocks for every class I'm trying to test. I could use something like Rino mocks but there may be some company policy against using open source, or you just don't want to keep it as simple as passable.

Talking to another developer about this he pointed all I needed to do was to give my mock objects some state to handle what passes or fails; BRILLIANT!! why didn't I think of that. So I took the base class

I added 2 collections:
  1. A Collection of string to handle messages added by the various mocked methods to tell the unit test what has occurred
  2. A second collection of strings to to tell the mock to fail and on what methods based on messages passed to the mock object
public class BaseTestRequest
public Collection Messages { get; set; }
public Collection FailOn { get; set; }
private string _currentMessage = string.Empty;

public string CurrentMessage
get { return _currentMessage; }
_currentMessage = value;

public BaseTestRequest()
Messages = new Collection();
FailOn = new Collection();

public bool WasSuccessful()
return (!FailOn.Contains(_currentMessage));
Then I can mock an object like this
public class TestAuthenticationRequests : BaseTestRequest, IAuthenticationRequests
public bool AuthenticateUser(string userName, string password)
CurrentMessage ="AuthenticateUser";
return WasSuccessful();

to see the full code with comments check out this Sample Code from the sample project.