Bloggin'bout Ivonna

Just to catch up with the TypeMock Isolator development. I should have released this weeks ago, but.. no, really no excuse here.

The only improvement is adding the TestSession.SetUser method. Before that, you had to write something like

session.User = new GenericPrincipal(...)

Now:

session.SetUser("ulu", "admin");

Enjoy!

You can get it at the download page, as always. Not much breakthroughs this time, but three handy spies that will simplify yor tests a bit.

Next will be the 2.1 release, with long-awaited AJAX support (page methods and maybe something else), and at last some optimization efforts.

Until next time..

One of the biggest problems about Ivonna is its performance. On medium sites, the first request to a page can take up to several minutes. The following requests are quite fast, however, which makes Ivonna more efficient than client-side tools when running big integration suites. However, doing the fast red-green-refactor cycles is.. not as fast as it should be.

After some investigation, I discovered that the the Asp.Net engine recompiles the web site when it receives the first request. Even if the site itself hasn't changed. A few more hours of digging (with the help of the excellent CThru's TraceAspect) revealed the whole picture:

1. When the runtime creates a new AppDomain for the site, it recalculates the hash and compares it to the previous value.
2. Since the test assembly has changed (even if it hasn't, since it's been copied to the bin folder, the timestamp has changed), the hash is different.
3. The runtime clears the temp directory.
4. On first request, it recompiles the site.

There are two tricks that can help us here. The first is pretty sraightforward: install a RAM drive and point the temp directory there:

<compilation debug="true" strict="false" explicit="true" tempDirectory="R:\temp"

The second is more esoteric: in the compilation tag, put  optimizeCompilations="true". This will skip checking the bin (as well as App_Code and resources) folder for modifications. So, sometimes you'd want to recompile -- you can do that by touching one of the aspx pages.

As you know, Ivonna supports testing MVC sites. However, the support is.. it works, but you can't do much about it. However, Steve Sanderson (the author of xVal) recently published a post about the MVC testing framework he's developed. It's based on the same idea as Ivonna: it's running in-process. However, since MVC is much more open for extension, this framework doesn't require "hacking" the runtime. It doesn't require TypeMock and, by the way, is completely free. You can read his post here.

I think it makes no sense to add MVC related features to Ivonna, unless this is really needed, so I'll continue the development in other directions.

It is always a good idea to hide your membership-related activity behind a service, instead of just using the MS provided API. However, I am currently building a prototype, and I wanted to use the built-in controls, which leaves me no choice but use the Membership API.

Turned out it's quite simple, you don't even have to create an aspect:

Dim section As MembershipSection = _
   ConfigurationManager.GetSection("system.web/membership")

section.Providers.Add(New ProviderSettings("InMemory", _
    "Tests.Membership.InMemoryMembershipProvider"))

section.DefaultProvider = "InMemory"

Here I add my custom provider to the configuration and set it as default.

Of course, this simplicity shouldn't fool you that this is a good idea in general.

Today I released the 2.0.1 version, but before I explain the new features, I wanted to say a couple of words about the whole 2.* idea.

When you do "regular" unit testing, you often need to redesign your class so that the collaborators are not instantiated but rather "injected". After that, you can inject a mocked version of some collaborator via the constructor, for example.

Unfortunately, we don't have that luxury when testing Asp.Net views, be it WebForms or MVC. We usually call something like "Default.aspx", or "Products/List", leaving no opportunity for DI. So, what can we do?

If we look at desktop applications, there's always a top-level code that is responsible for all wireup. It's either the Main function, or the config file. It's not covered by the unit tests, but rather unit tests tend to "swap" it for some mockup. And while they can bypass it by just calling the lower-level classes, we can also bypass it -- using TypeMock!

Here comes the solution for Ivonna: make it possible to change the production top-level code for test counterparts. Including the web.config file, HttpModules, and the HttpApplication class. This is the main idea for the version 2.*.

Here's what we have in the version 2.0.1:

• We can modify the configuration, including, but not limited to, app settings and connection strings.
• In case this is not enough, we can swap the entire web.config file for, say, test.config. Should be in the root directory of the Web, but I think this is a temporary limitation.
• We can manipulate the HttpModules collection. Ok, actually, it's module types. This feature was implemented for the 2.0.0 and is already superceded by the writable configuration introduced in 2.0.1
• In 2.0.2, we'll be able to plug into the point at which the HttpApplication is initialized, and modify some of its properties, including the Modules collection. Note, however, that this instance will be probably alive in the tests that follow.

Download it here.

While Asp.Net MVC architecture is widely praised for its testability, it is seldom mentioned that the Views are still untestable. It is believed that you don't need to test your views since they are "dumb", and it's just too hard anyway. However, string-based ViewData and unevitable foreach pieces make the View fragile, and you just can't leave it untested.

While you can't have a Page instance with all its structured beauty, you can still test your MVC views with Ivonna. Remember, however, that the usual session.GetPage() won't work: you have to use something like session.ProcessRequest(new WebRequest("LogOn")), for example. Then use response.BodyAsString to get the raw HTML output, or other WebResponse to check for redirects or response status.

While this is all possible with client-side frameworks, the mere fact that we are in-process makes it possible to mock stuff. For example, you can mock the Controller, or the Model, or, say the membership provider.

If you are seeing this message, it is possible that you just don't have sufficient rights to read a certain registry key. This issue has been reported on a Windows 7 64bit box. To fix it, either run Visual Studio (or your test runner) as an admin, or relax the permissions for the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\TypeMock\TypeMock.NET\Packs\Ivonna

From time to time, my Web tests were throwing a "400 Bad Request" response. It was always a problem with the Ivonna setup, but the request itself was a little bit too laconic: it said "Bad request" inside a body tag, and that was it: no exception message, no stack trace, nothing!

Turned out that if the runtime fails to create an instance of HttpContext, it swallows the exception and just sends a hardcoded response. Just take a look at this:

try {

   context = new HttpContext(wr, false);
}

catch {

   wr.SendStatus(400, "Bad Request");

   wr.SendKnownResponseHeader
      (12, "text/html; charset=utf-8");

   byte[] bytes = Encoding.ASCII.GetBytes
      ("<html><body>Bad Request</body></html>");

   wr.SendResponseFromMemory(bytes, bytes.Length);

   wr.FlushResponse(true);

   wr.EndOfRequest();

   return;

}

In order to figure out what's going on, I had to create the Context manually. Turned out that the exception is thrown inside my code, and the actual cause is that the hosting environment is not initialized in the current AppDomain. So, I just added a simple check (fortunately there's a public property, HostingEnvironment.IsHosted), and hopefully we can forget about the Evil Request Mystery.

I thought it's worth a new version, you can get it here, as always.

I tried to publish an article about Ivonna on CodeProject, but they refused on the grounds that they publish articles about either free or Microsoft tools (a bit unfair, imho). Anyway, you might be interested in it, so I'm publishing it here.