I found another reason to love open source NUnit over MSTest, NUnitEx. NUnitEx provides a fluent DSL to write NUnit assertions where Visual Studio intellisense is your guiding friend. I’m sure you’re thinking, “Yeah whatever, show me some code.”

[Test]
public void AdjacencyGraph_is_directed_by_default()
{
    var graph = new AdjacencyGraph<Task, TaskDependency>(DoNotAllowParallelEdges);
    graph.IsDirected.Should().Be.True();
}

Nice eh? graph.IsDirected is the property I want to test.  Everything after that is the NUnitEx extension methods. I know I find it much more readable than this:

[Test]
public void AdjacencyGraph_is_directed_by_default()
{
    var graph = new AdjacencyGraph<Task, TaskDependency>(DoNotAllowParallelEdges);
    Assert.IsTrue(graph.IsDirected);
}

I would also like to add that this syntax is likely to be included in NUnit 3, which would be excellent!

Thanks to Justin Burns who submitted the required code changes to upgrade my MsTest plugin to ReSharper 4.5.  I just applied the patch and posted the new plugin DLL.  For those of you who wonder why you would use this over the JetBrains provided MsTest runner, one word: speed.

This has been pretty low on my priority list since I don’t use MsTest very often anymore since converting of all but one of our test projects to NUnit, but for the rest of you, enjoy!

Update: Resharper 4.5 beta is out, and it natively supports MsTest.

Update: I updated this plugin to work with ReSharper 4.5

Chances are, if you have ReSharper you're using the built in ReSharper test runner. The Resharper test runner is pretty frictionless assuming you're using one of the open source testing frameworks like NUnit.

If you're stuck using MSTest for some reason, like in my unfortunate case my company has standardized on it... then you're pretty much stuck using the MSTest runner, which really sucks for numerous reasons.

The MSTest runner likes to muck around with vsdmi and testconfig files (or something like that, I can't remember) and is pretty slow. Up until VS 2008 it was almost completely useless for TDD.

Its almost usable in VS 2008, but I still hate the test failure reports. I can't just scan a bunch of grouped tests to see which one's failed and why. To really see why, I have to open a new test report tab in VS. Even more annoyingly, MSTest refuses to find my resource satellite assemblies without additional hoop jumping. I like to call that friction.

After finally having enough of this I decided to create my own MSTest ReSharper 4 plugin (Apache 2.0 license). It was actually quite easy to hook into the ReSharper test infrastructure, especially since JetBrains gives you most of the code to do it in the form of a csUnit plugin. A few deletes and edits later, and I have a functional MSTest plugin.

Not only does it work, it works better. My satellite assemblies are found right out of the gate, reports are inline with the runner, and for a moment I almost lapse back into mistakingly typing NUnit attributes.

Now mind you, its not perfect, but it works really well for my needs. Some gotchas, or differences between the standard MSTest runner and my plugin:

• TestContext is always null, the runner doesn't provide that. Unit tests shouldn't need it anyway.
• AssemblyInitialize is not honored, much like like TestDriven.NET. I get around this using a static initializer in my base class test fixture (I need this for some slow integration tests if you're wondering).
• MSTest seems to create a new test fixture instance between each test run, this plugin only creates a single instance of the fixture. Generally this shouldn't be a problem if your TestInitialize method is written correctly.

Binaries and source are available on my Google Code web site. To install, just drop the DLL into the ReSharper bin\plugins folder and restart VS 2008. Happy testing!

One of the topics brought up at the agile beer night was test fragility and how mocking frameworks can be a contributor to test smell.  Actually, I'm the one who brought up the point about mocking frameworks and fragility, but further examination revealed some disparity on the subject, specifically related to replay semantics.

I know that when I first started using a mocking framework I assumed it was best practice to use strict mocks.  I mean, why wouldn't you want to verify everything possible?  Apparently I'm not the only one to think this at one point or another.  I found this blog post by Derik Whittaker stating how he prefers strict mocks, it gets really interesting once you read through the comments.  Scott Bellware made the following comment:

Strict mocks is often a design smell.  It causes tests to express knowledge of an operation's internals, which is a violation of encapsulation of the system under test.

Any large code base that depends on strict mocking by default will suffer from unnecessary productivity loss due to breaking tests that have to be fixed where those tests suffer from inappropriate intimacy.

An API's internals are supposed to be allowed to change independently of its tests.  This is an essential quality of an agile codebase.

Strict mocking by default is a rather extreme stance.  Agile succeeds by finding those places where strictness can be slackened without causing any observable and categorical loss in integrity.  Opting for the strictest possible default runs contrary to this heuristic.

Through years of experience with mocking frameworks have I come to the realization that loose mocks should be your default.  Apparently the creator of Rhino Mocks, Ayende, agrees (emphasis is mine).

As an aside, I am deprecating CreateMock in favor of StrictMock. Using strict mocks by default was a bad design decision on my part.

One of the primary reasons mocks introduce fragility is that they require knowledge of the SUT that goes deeper than the public API.  You often need to know what methods on a collaborator will get called and setup some sensible return values that force your SUT through a particular branch of code. To me that's the very definition of tightly coupled.

So, how do we take advantage of a mocking framework, without making our tests fragile and resistive to change?  Unfortunately there's no way to completely avoid the mock object tax, but we can certainly minimize it.

One of the very first things we can do is setup our mocks in a shared fixture setup method. Sharing mock setup between tests is a great way to reduce the verbosity of each test.  A shared setup method will also setup the SUT with the appropriate mocks.

[SetUp]
public void SetUp()
{
    mocks = new MockRepository();
    userRepository = mocks.DynamicMock<IUserRepository>();
    purchaseService = mocks.DynamicMock<IPurchaseService>();
    sut = new Controller(userRepository, purchaseService);
}

You'll notice that the shared fixture setup I've created is using Rhino Mocks dynamic mocks.  You could instead use an auto mocking container to create the mocks for you to save some keystrokes and repetition.

With loose replay semantics (dynamic mocks in Rhino terminology) any method call during the replay state is accepted and if there is no special handling setup for this method a null or zero is returned. All the expected methods must be called if the object is to pass verification.

Too many times I've been burned by an over specified test using strict mocks.  With strict replay semantics only the methods that were explicitly recorded are accepted as valid. This means that any call that is not expected would cause an exception and fail the test. All the expected methods must be called if the object is to pass verification.  Depending on the mock this could be rather verbose leading to many expectations that have nothing to do with the actual test.

Tests should test only one thing.  You may have multiple assertions or expectations per test, but all of those assertions should have the same goal or theme.  I only want to setup the minimal amount of expectations on a mock that will verify a particular behavior in my SUT, anything more is over specified.  More to the point, keep your tests short and concise.

By using dynamic mocks rather than strict mocks, we are free to ignore the parts of the interaction between the SUT and the mock that we don't care about for our particular test.  We can also use setup result instead of expect if we can verify the interaction using a classicist approach.

[Test]
public void Should_show_cart_empty_message_if_cart_is_empty()
{
    SetupResult.For(purchaseService.GetCart()).Return(new ShoppingCart());
    mocks.ReplayAll();

    sut.ShowCart();

    Assert.AreEqual("You're shopping cart is empty", sut.Flash["warning"]);
}

Here I'm verifying behavior without explicit help of the mock framework, I'm only using the mocking framework to stub in my external dependencies and then verifying the expected behavior using a traditional assertion. 

If it weren't for the external service dependency I probably wouldn't be using a mocking framework here.  Mocking frameworks are most valuable at the edges of your components where things come together with the SUT, like databases, web services, and files.

The normal flow through the controller actually uses the purchase service for more than just grabbing the cart, it also uses it to grab the customer's billing information, but for this particular test I don't care whether the billing details get populated or not.  Here's the simple controller method we're testing:

public void ShowCart()
{
    PropertyBag["customer"] = userRepository.GetCustomerDetails(userID);
    PropertyBag["billing"] = purchaseService.GetBillingInfo(userID);

    ShoppingCart cart = purchaseService.GetCart();
    if (cart.IsEmpty)
    {
        Flash["warning"] = "You're shopping cart is empty";
    }
}

Lets say I now want to verify that the billing information gets populated when ShowCart is called.  Here the tables are turned, I don't really care about the call to GetCart() on the purchaseService.  I really only care that the property bag gets properly populated with billing information.

[Test]
public void Should_show_billing_info()
{
    SetupResult.For(purchaseService.GetBillingInfo(0))
        .IgnoreArguments()
        .Return(new BillingInfo());

    mocks.ReplayAll();

    sut.ShowCart();

    Assert.IsNotNull(sut.PropertyBag["billing"]);
    Assert.IsInstanceOfType(typeof(BillingInfo), sut.PropertyBag["billing"]);
}

Perhaps now we're concerned with populating the correct billing information, because as you might imagine, showing someone else's billing info would be a horrible security flaw.  So lets change our test to verify that using a mock.

[Test]
public void Should_show_billing_info()
{
    sut.CurrentUserID = 5;
    Expect.Call(purchaseService.GetBillingInfo(5))
        .Return(new BillingInfo());

    mocks.ReplayAll();

    sut.ShowCart();

    Assert.IsNotNull(sut.PropertyBag["billing"]);
    Assert.IsInstanceOfType(typeof(BillingInfo), sut.PropertyBag["billing"]);

    mocks.VerifyAll();
}

Just by changing from SetupResult.For to Expect.Call we are now explicitly checking that controller gets its billing information using the correct user ID.  We also added in a VerifyAll call.  Now if the purchaseService.GetBillingInfo method is called with anything other than 5, or not called, the test will fail.

By using dynamic mocks we've verified just enough to see if our SUT works without adding a bunch of noise or unneeded fragility to our tests.

I committed an example class library (utility) which drives some JsUnit tests and gathers the results.  This is handy if you want the results inside of a C# application or an NUnit test.  Basically the JsUnit webform is posted to an ASHX handler running under the .NET 2.0 webserver. 

Its not real pretty or that usable in its current form, but it has some good starting points. I'm not sure it actually works since I lost the original source code and had to decompile it using Reflector.  It at least compiles...  Do whatever you like with the source, its available in my SVN repository here.

Perhaps I'm exaggerating a little bit, but if you look at the claims Gallio makes you might be tempted to agree with me. 

The Gallio platform seeks to facilitate the creation of a rich ecosystem of interoperable testing tools...  they should present consistent interfaces to the world so that they can easily be integrated into the systems and processes of the enterprise.  At present Gallio can run tests from MbUnit versions 2 and 3, MSTest, NBehave, NUnit, and xUnit.Net.  Gallio provides tool support and integration with CCNet, MSBuild, NAnt, NCover, Pex, Powershell, Resharper, TestDriven.Net, TypeMock, and Visual Studio Team System.

That's a lot of integrations!

The UI runner that comes with Gallio is pretty and for the most part functional - remember this is an alpha!  I did have some issues when I tried loading several thousand tests into the UI.  Things got slow and a little wonky while it scanned for tests in my assembly. A couple of times it crashed on on me after reloading the assembly after a recompilation. Then again I'm not sure if NUnit is any better in this type of scenario.

Gallio sounds like a real benefit for organizations using MSTest that are looking to upgrade to a real xUnit framework.  At the very least you can ditch the lackluster MSTest runner in favor of a better runner like ReSharper, which is what I'm currently trying to do.  Unfortunately there's an issue with Gallio that makes all the tests report back a status of 'skipped.'  Luckily this is an OSS project with public source code...

Gallio makes working with different open source projects very easy from my point of view.  Now I can use a common interface (ReSharper 4.0 test runner) for all my testing needs regardless of the OSS project's test runner... no need to fire up MBUnit GUI or NUnit or whatever.  It all just works and doesn't interrupt my flow.  I imagine the number of testing frameworks and tools for Gallio will almost certainly grow over time. 

This is definitely one of the more useful testing tools I've seen recently.  Why?  Because it reduces friction.

Sometimes you'll actually have a class that needs to read and parse files on disk.  This is pretty easy to do with the FCL StreamReader, but the problem is how do we test a class that is accessing resources on disk like text files?

Most devs first reaction is to create a file on disk in the test project and read that in.  This is often better than nothing, but has some problems associated with it.  Your test assembly now requires physical files on disk which are probably not in the current running test directory, or maybe you've moved the entire assembly to a different location then the test expected.  The real issue is that the class under test controls where the data is read from, not the test.

In short, these external files make your tests brittle, slower, and less intention revealing.  Not only that, but the external dependency really makes the test an integration test and less of a unit test.

The normal solution is to hide the external dependency behind a facade or interface that is mockable.  Unfortunately this is difficult because access to files on disk normally is very short lived.  A StreamReader instance often only lives for the duration of a method call, if even that.  The typical usage pattern  is: construct/open, read, close.

   1: using (var reader = new StreamReader(@"c:\file.txt"))

   2: {

   3:     fileType = reader.ReadLine();

   4: }

We really can't just inject a StreamReader instance into our class under test because the StreamReader opens the file via its constructor.  The problem is that the class under test is responsible for the entire StreamReader life cycle.

The simplest way around this is to use a factory class to create StreamReader instances which allows us to control the instantiation of the StreamReader, which is important when we go to unit test.

   1: public class StreamReaderFactory : IStreamReaderFactory

   2: {

   3:     public StreamReader CreateReader(string path)

   4:     {

   5:         return new StreamReader(path);

   6:     }

   7: }

   8:  

   9: public interface IStreamReaderFactory

  10: {

  11:     StreamReader CreateReader(string path);

  12: }

With that interface in place we can then inject a StreamReaderFactory implementation into our class when running in production. The factory couldn't be any simpler, its just a simple wrapper around the new statement. 

Now when we unit test we'll swap out the very simple factory implementation with a mocked one using RhinoMocks.  This mocked factory will return a predefined result which is located at the beginning of the test, keeping everything located in the test.

   1: [Test]

   2: public void Should_parse_resource_type_from_first_line()

   3: {

   4:     using (var content = CreateStream("F4", "some text resource"))

   5:     {

   6:         var streamReaderFactory = MockRepository.GenerateStub<IStreamReaderFactory>();

   7:         streamReaderFactory.Stub(x => x.CreateReader(@"resource.dat"))

   8:             .Return(new StreamReader(content));

   9:  

  10:         var classUnderTest = new ResourceParser(streamReaderFactory);

  11:         classUnderTest.ParseResources();

  12:  

  13:         Assert.AreEqual("F4", classUnderTest.ResourceType);

  14:     }         

  15: }

  16:  

  17: private static Stream CreateStream(params string[] lines)

  18: {

  19:     string rawContent = string.Join(Environment.NewLine, lines);

  20:     return new MemoryStream(Encoding.UTF8.GetBytes(rawContent));

  21: }

If we had a really complicated external file I would more than likely stick it into an embedded resource text file, but that's only if the file was complicated or a pain to create in code as a string.  The point is with the factory in place the test controls where the data comes from, not the class under test.

It always amazes me when I find some little gem of functionality in a code library that I've used for some time.  Today I was amazed to find out that RhinoMocks has a logging facility built into it, and I'm willing to bet this feature has been there for a long time and I just never noticed it.

Turning on RhinoMocks logging in your test fixture setup (or test) outputs all kinds of nifty informational messages about what RhinoMocks is doing.  There appears to be 3 built in loggers in RhinoMocks:

• TraceWriterExpectationLogger
• TraceWriterWithStackTraceExpectationWriter
• TextWriterExpectationLogger

Here's a simple test case using TraceWriterExpectationLogger (line 4):

   1: [Test]

   2: public void Should_login_user_with_valid_user_name_and_password()

   3: {

   4:     RhinoMocks.Logger = new TraceWriterExpectationLogger();

   5:  

   6:     var userRepository = MockRepository.GenerateStub<IUserRepository>();

   7:     userRepository.Stub(x => x.GetUserByUserName("sneal")).Return(new User

   8:     {

   9:         UserName = "sneal",

  10:         Password = "password"

  11:     });

  12:  

  13:     var controller = new LoginController(userRepository);

  14:     controller.Login("sneal", "password");

  15:     

  16:     Assert.AreEqual("sneal", controller.UserContext.UserName);

  17: }

You might have noticed I'm using the new AAA syntax in RhinoMocks 3.5.  Very elegant.  No setup method, no explicit replay or verify calls.  I really like it.

Using the TraceWriterExpectationLogger looks like this from the ReSharper test runner, notice the trace messages from my mock:

So the next time you get stuck with an over complicated test session, try turning the logger on - I know I will.

Over the years I've struggled with naming conventions for unit test methods, picking up various habits from different projects and people.  Roy Osherove (who reminds me of Adam Sandler) at one point recommended the following format for your unit test names:

[MethodName_StateUnderTest_ExpectedBehavior]

Although workable, and certainly an improvement over chaos, I don't find it all that appealing.  Non-programmers probably won't get it, and even programmers might have to read it a couple of times - at least that's what I ran into.  It does organize a group of tests in a fixture nicely, but beyond that...  its just not for me.

I've tried varying other methods, but I've generally always started my test names with some sort of assertion like "Should" or "Can".  This makes the test at least state what the expected behavior that is supported in a semi-fluid way.

Beyond that I like my unit test method names to convey exactly what is being tested, not just the class or method name being tested along with a state - I want a full sentence describing the expected behavior.

Up until recently I've been following the .NET naming conventions for my unit tests, but the simple fact is my method names are too long to be readable sentences.  You see, my test method names tend to be sentences which may or may not come from the user story or task itself. 

Here's an example method name from my current project using the .NET naming conventions: ShouldRedirectToShippingPageWhenShippingIsRequiredAndShippingAddressIsMissing.  Not only is this long, but its also unreadable except to programmers.  Even to programmers this isn't pretty, its just too long.

Now here's how I've been formatting my test names as of recent:

Obviously I'm breaking .NET naming conventions left and right here, but I don't care who you are, that's waaaaay more readable. Even more importantly I can discern what the test does just by reading the method name.  I find this handier than reading comments since it also shows up in your test runner. 

There's little need to go back through and re-read the test itself to figure out what the test does, its clearly stated in the method name. With this style anyone can go back and read the unit test method name and figure out the expected behavior.

I've never been too happy with the .NET naming standards especially in regards to unit tests.  The world is bigger than .NET, so take that convention!

I found myself doing this today with Rhino Mocks:

[TearDown]

public void TearDown()

{

    mocks.ReplayAll();  // ensure replay was called

    mocks.VerifyAll();

}

I have a few tests in my fixture that don't use mocks, so forcing those tests to have mocks.ReplayAll() in them is just extra noise.  As it turns out calling Replay multiple times is safe, so tests that use mocks of course have already called ReplayAll, but tests that don't use the mocks can forgo having to call ReplayAll() just to have the tear down method run without error.

In case you didn't know, calling VerifyAll in RhinoMocks will throw an exception if you have previously called Replay.

Over the past few months on the RhinoMocks group I have seen several good ideas for enhancements to the library.  One of the ideas was to add a DoNotExpect.Call helper, which would do the same thing as the LastCall.Repeat.Never() syntax, just in a much more concise way.

This past weekend I added the DoNotExpect.Call() syntax to RhinoMocks, and Ayende has already applied the patch to the RhinoMocks trunk.  Here's how you use the new syntax:

There are two overloads for the method, one takes an object, and the other a delegate.  For methods that return a value you can use the simpler one without the delegate, however for void methods you need to use the delegate syntax (since something has to be passed in, even if it is technically ignored).

I'm excited about the syntax since I know I will use it quite often on my controller tests that use a lot of dynamically mocked objects.  The syntax I think is also easier to understand, especially for RhinoMocks newbies who have used NMock2 before.

Hopefully I'll have time to add some other enhancements to RhinoMocks in the near future.  It feels good to give back to the software ecosystem every once in a while.

I posted last week about testing JavaScript through NUnit with JSUnit.  While this worked, it was a little slower to run tests than I really wanted.  It was also slower (for me) to write the tests since I had to leave the comfort of NUnit and .NET for JSUnit and JavaScript.

I'm continuing to look at the problem of JS testing for ASP.NET.  I evaluated YUI Test, Yahoo's JS unit test library.   YUI Test actually looks very good, but I really wanted to keep things integrated with my current build and test process, even if it isn't the best solution; you don't know unless you try. 

This time I'm only using NUnit and WatiN for my JavaScript tests.  Since WatiN now has the ability to evaluate JavaScript and return the results, I'm using this to run the JavaScript function under test and then using an NUnit assertion for validation.

I create each test using regular NUnit syntax, and then wrap the JavaScript function call with a C# method which passes the arguments off to the JS function to test.

[Test]

public void ShouldValidateDiscover()

{

    Assert.IsTrue(ValidateCreditCard("6011648040903965", "discover"));

}

private bool ValidateCreditCard(string cc, string ccType)

{

    string testJs = string.Format("var cc = new CreditCardValidator(); cc.isValidCreditCardNumber('{0}', '{1}');", cc, ccType);

    return EvalToBool(testJs);

}

The EvalToBool method just calls the WatiN eval method which accepts JavaScript as a parameter, and then converts the JS string result to a .NET boolean.

protected bool EvalToBool(string js)

{

    string result = ie.Eval(js);

    return bool.Parse(result);

}

The overall process is:

1. Create a dummy HTML page which includes the JavaScript source file I want to test.
2. Kick off WatiN and navigate to the dynamically created HTML file.
3. Pass the JavaScript function to be evaluated by WatiN.
4. Assert the eval call results using NUnit.

The test setup is very simple, and it runs fast for this type of test.  On my PC it was taking 1.7 seconds to setup the test fixture, and then .2 seconds to run each test.  The nice thing is that the errors are generally obvious and easy to diagnose since they are native NUnit tests.  Its also nice to have multiple NUnit test entries in the runner instead of one monolithic JavaScript test function which encapsulated all my JS tests that run in JSUnit. 

The tests can get ugly if a JavaScript exception is thrown, in that case you get a generic COM exception returned from WatiN rather than a nice error message.  The is one area where a JSUnit or YUI test are naturally better at.

This makes me wonder if WatiN couldn't be extended to return better error information from JavaScript, and whether the use of a dynamic .NET language along with NUnit couldn't make for a nice testing experience.

I needed to make a change to some existing legacy* JavaScript that validates credit card numbers in the browser.  For the most part the project was green field except for a few services, so overall test coverage was very good - except for the JavaScript code.  The lack of test coverage in the increasingly growing JavaScript libraries was starting to really bother me, so I set out to find a way to create "unit" tests for my JavaScript code that didn't require any setup or any extra steps for another developer to run.  What I really was wanting, was for my JS tests to be integrated and run along side my NUnit tests.

After some searching it appeared that JsUnit looked to be the most widely used and supported JavaScript testing facility available.  The one problem with this is that it requires you run the tests through a frame in a browser, which is a whole lot slower and less integrated with our NUnit tests that I wanted.

To get faster feedback on my JS tests I immediately thought of using WatiN to drive the JsUnit tests.  After a quick Google search I found that Adam Esterline had already done something very similar.  The main difference between what he's done and what I wanted was that I wanted JsUnit errors results right there in my ReSharper test runner window and I wanted my test scripts to be pure JavaScript rather than HTML files that JsUnit uses (because I wanted to keep the SOC high, and be able to dynamically change the location of JsUnit relative to my test scripts).  Like Adam, I'm auto generating a test HTML page for JsUnit and using WatiN to drive IE (although since I get my results outside of IE, I'm thinking I can drop using WatiN altogether for this and make it browser independent).

The workflow for using the JsUnit utility library is as follows:

1. In your test project include a reference to JsUnit.Utils.dll
2. Create a folder (or two) to contain your JavaScript JsUnit test fixtures.
3. Create your JsUnit test fixtures as separate .js files.
4. Create a .NET NUnit test fixture with a test that runs the JsUnitTestRunner from JsUnit.Utils.

Here's my solution explorer window with the JsUnit.Utils reference and the c# and the JavaScript fixtures.

Once that is setup you create a single NUnit test that kicks off all the JsUnit tests.

/// <summary>

/// This runs all JsUnit tests found in the JavaScript folder and makes

/// their results available through NUnit (if any fail).

/// </summary>

[TestFixture]

public class JavaScriptFixture

{

    #region Setup/Teardown

    [SetUp]

    public void SetUp()

    {

        jScriptTestDir = AppDomain.CurrentDomain.BaseDirectory + "\\..\\..\\JavaScript\\";

        jsUnitDir = ConfigurationManager.AppSettings["JsUnitDir"];

    }

    #endregion

    private string jScriptTestDir;

    private string jsUnitDir;

    [Test]

    public void RunAllJSUnitTests()

    {

        Assert.IsTrue(Directory.Exists(jScriptTestDir),

                      string.Format("Could not find the JsUnit tests directory: '{0}'", jScriptTestDir));

        Assert.IsTrue(Directory.Exists(jsUnitDir),

                      string.Format("Could not find the JsUnit directory: '{0}'", jsUnitDir));

        ITestFileReader reader = new SuffixTestFileReader(".js", new TestFileReader(jScriptTestDir));

        new JsUnitTestRunner(reader, jsUnitDir).Run();

    }

}

Running this test through the ReSharper Test Runner runs all my JsUnit tests, so when I choose "Run All Tests from Solution," it really means "run all tests".  More importantly, if any JsUnit tests fail during execution the JsUnit error is displayed in the output window.  Here's my "testShouldValidateCreditCard" test that is failing which shows the JsUnit error text:

If you've ever used JsUnit before I bet you're wonder how I'm getting the result back, since JsUnit is entirely web based and only supports posting results to a URL (generally for use with the JsUnitServer).  What I'm doing is unpacking an ashx file that is an embedded resource, copying the current running DLL (JsUnit.Utils.dll) to the bin directory under the current running directory, and then starting the .NET 2 webserver.webdev.exe to listen for results using the unpacked ashx file.  The results are then saved out to a predetermined text file which JsUnitTestRunner is looking for and then parses out any errors.  I could use .NET remoting or something fancier, but this works well enough for now.

There's still a lot that could be done to clean this up, like removing the WatiN dependency, adding new features and so on.  There are also a few bugs I need to work out, but so far so good.

*legacy in the sense that there were no unit tests, even though the code is only a month old.

Being the only one at work with any Linux experience, I was elected by default to port our C++ API over to Linux.  Luckily we had some CxxTests already being utilized on Windows, and good thing we did because as I found out, just getting our API to compile on Linux didn't mean it would run on Linux.  These unit tests saved me around 2 days of work (it only took me about 12 hours to port).

The Linux environment I chose to use was Ubuntu running Eclipse CDT.  After some Googling I found that there's an Eclipse plugin for CxxTest that is similar to the Eclipse JUnit runner.  That sounded very appealing; I sure wish there was Visual Studio CxxTest runner.  Unfortunately all of the instructions for the plugin are about getting it to work with Windows and Cygwin, which wasn't much help in my scenario.  To get the pluging to work I found I needed to:

1. Install the BFD dev library onto my Ubuntu system using apt-get.
2. Remove the -libintl flag from the test project's additional libraries section.

After making those changes I was able to get the CxxTest runner building and running just fine.  The one thing I did notice is that the tests run only after 2 rebuilds of the test project.  I'm not sure why that is, or if I was doing something wrong - it was getting annoying having to edit my test file, compile, edit it again, and then recompile a second time to get the tests to run.  There must be a manual way to force the tests to build...

int theRef = 42;
int theOut = 0;
Expect.Call(obj.MyMethod(ref theRef, 0, out theOut)).Return(True).OutRef(13, 666)

Articles

• http://www.codeproject.com/useritems/Rhino_Mocks_22.asp - This provides an integrated overview of how to use Rhino Mocks including examples.
  
• http://blogs.giffordconsulting.com/archive/2007/02/17/9949.aspx
• http://blogs.giffordconsulting.com/files/RhinoMocks%20QuickRef.pdf
• http://groups.google.com/group/RhinoMocks

Documentation

• http://www.ayende.com/wiki/(S(a00bey3wmfmvxc55ipic4kng))/Rhino+Mocks+Documentation.ashx -This provides more examples of the Rhino Mocks API beyond the article.
• If you are looking for “Cheat Sheet” type of help then look at:
• Methods: http://www.ayende.com/wiki/(S(a00bey3wmfmvxc55ipic4kng))/Rhino+Mocks+Method+Options+Interface.ashx
• Properties: http://www.ayende.com/wiki/(S(a00bey3wmfmvxc55ipic4kng))/Rhino+Mocks+Properties.ashx

Now that I’m finally back in ASP.NET user land, I can finally scratch an itch of mine to use WatiN on a real project.  I’m thoroughly impressed with the product, even though the documentation is fairly light; the thing is the API is so straight forward you don’t need a bunch of documentation which allows you to ramp up and use it very quickly.  How nice is that?

The one problem I had was that Session state and general page state was being shared between each of my tests initially which would cause some tests to break because they expected the page to be in one state, but another test had changed the state to something else.  I had originally scoped my IE instance at the fixture level, which caused some tests to break because of the order they were being run by NUnit.  I ended up having to change my IE scope from fixture level, to test level which was quite a bit slower.  Here’s one of my tests:

[Test]
public void SearchResultsAreDisplayedOnSearchClick()
{
   using (IE ie = CreateIE())
   {
      ie.Link(Find.ById(new Regex(@"m_btnSearch\b"))).Click();
      string borrowerName = GetResultTable(ie).TableRows[1].TableCells[1].Text;

      Assert.AreEqual("George Washington", borrowerName,
          "Search results did not display as expected.");
   }
}

private Table GetResultTable(IE ie)
{
   return ie.Table(Find.ById(new Regex(@"m_resultsGrid\b")));
}

private IE CreateIE()
{
   IE ie = new IE(SearchUrl);
   ie.Refresh();
   return ie;
}

What I need to do is to make my tests less granular, less like a unit test and more like a functional integration test.  I would rather not do that, but I think for more complicated testing scenarios I will have to do this anyway.  I should stop trying to fight what should be natural here.  Basically I need to combine what are now several tests into a single test.  An end user would likely perform several actions on the page before moving on to anther page, and so should my WatiN tests.  After all, these aren’t unit tests – those of course are already all green.

if (m_testingData)
{
   serviceResults = m_testingData;
}
else
{
   RequestorDataService ds = new RequestorDataService(m_url);
   ds.Message = CreateSOAPRequest();
   ds.Submit();
   serviceResults = ds.GetResults();
}

Does anyone see a problem with the above code fragment?  Some IoC love would go a long way here.

enum DayOfWeek
{
    Monday,
    Tuesday
}

DayOfWeek badDayOfWeek = (DayOfWeek)(-1);

WatiN

Inspired by Watir development of WatiN started in December 2005 to make a similar kind of Web Application Testing possible for the .Net languages. Since then WatiN has grown into an easy to use, feature rich and stable framework. WatiN is developed in C# and aims to bring you an easy way to automate tests with Internet Explorer. Following is the Hello world example of web testing automation; searching Google with WatiN.