Typemock Racer – A “must have tool” for all ASP.NET developers

A very common mistake taken by junior ASP.NET developers is forgetting that any web application running in a IIS instance will most likely run in a multithread environment.

They forgot that, unlike the dev environment which usually runs in a single thread pool, production environment usually have a working thread pool with several dozen threads.

Common mechanism like the ASP.NET Cache or the ASP.NET Session have points of concurrency.

It’s common to create singletons in web apps. The most common scenario are provider pattern implementations. Many times, apps also need to have it’s own Cache mechanism or even Session mechanism. All this scenarios may leads us to multi thread racing for some resources.

Testing those code pieces were almost impossible … and multithread bugs and deadlocks were detected late in the application developing cycle:

  • when running load tests
  • or, in the worst scenario, only in a production environment.

Those days are gone … last May Typemock added a new tool to its toolkit, the Typemock Racer.

This new tool is intended to help finding and fixing possible deadlocks by enabling us to write threaded tests.

And if you think that this is a complex task to do, you are wrong. Doing race tests is as simple as writing a unit test and then decorate it with an  attribute – [ParallelInspection].

That’s it .. you can then run the test and Racer will try to find and recreate deadlocks.

In future Racer will also check for race conditions.

Take a look at this Roy Osherove post for some snapshots and a little movie.

Typemock Isolator – Faking an internal static type and overriding a static method

In most common samples about faking static types, the type itself is public as the static methods are too.

Usually programmers tend to expose all members that going to be targeted by an Unit test. Well, that’s not how I see Unit tests.

I always try to produce code to keep the cyclomatic complexity lower, and If I succeeded I ended up with types that can be easily tested.

I won’t expose code simply to test it, code should always have the minimum visibility that it indeed requires.

Then I rely on tools to test all my type members, either private, internal or public.

Currently I use the Typemock Isolator and I must say that I’m completely satisfied.

So, here’s how I faked an internal static type and also override it’s GetString method to allow me test the first parameter value:

Type globalizationHelperType = Type.GetType("NG.Helper, NG", true);
Isolate.WhenCalled(() => globalizationHelperType.GetMethod("GetString", new Type[] { typeof(String) }).Invoke(null, new object[] { null })).DoInstead((callcontext) => { return callcontext.Parameters[0]; });