Eli Lopian’s Blog (TypeMock)

Lowering the friction of Unit testing

At Typemock we have been learning allot about our customers lately and understanding where the friction is so that we can make unit testing even easier and maintainable.

What we are succeeding in doing is to lower the density of the tests (this means less code in each test) and raise the test resilient (this means the tests will still work after code changes)

Roy Oserove has talked about this (here, here and here). This has been the basis for the new API and concepts that we have already introduced in Typemock Isolator.

One feature that does this is the Recursive Fakes. Using this we fake and ignore a whole component, by faking a complete call stack. Our classic example is using SharePoint. In SharePoint a top most entry point is SPSite(). All other operations are a part of the call stack and objects returned from the SPSite.

example:

    var site = new SPSite();
    var web = site.OpenWeb();
    var lists = web.Lists;
    var items = lists[1];
    items[2].Update();

Note that SPSite is a Mother class of all other types.

We found out that in our tests, we normally don’t want to fail if any extra calls are called within this call stack. We also still want the test to pass if less calls are made within the call stack. Here is how we do it:

SPSite fakeSite =
   Isolate.Fake.Instance<SPSite>(Members.ReturnRecursiveFakes);

Using this will fake ALL the methods above, and all other methods that are called on the call stack of fakeSite! We can of course specify a fake value down the call stack:

Isolate.WhenCalled(
 () => fakeSite.OpenWeb().Lists[2].Items[1].Update).
 WillThrow(new Exception("");

Here we simulate an exception down the call stack, but all other calls will just work!

Thinking in the terms of Faking the call stack helps in writing less code in the test and adding to the resilient of the test. We are going to keep that trend as we continue to promote unit testing by enabling easy isolation.

Bookmark at:
          

11 November 2008 | TDD, .NET Tests | Comments | Print This Post