Interested in a
Personal Demo ?

Name* :
Please Enter your Name
Company E–Mail* :
Please Enter a Valid Email


"I find a new use for Typemock each time I use it... It's not often a product fills a gap so well… I was impressed. It takes care of a big hole in unit testing"
John Spano, CTO and Co-Founder, NeoTekSystems
Success stories


US Toll Free
Outside US
Get your printable quote
Buy online


ASP.Net unit testing - Interview with Artem Smirnov

Artem Smirnov is the author of Ivonna, part of Typemock Isolator for ASP.Net. Artem talks about the challenges of ASP.Net testing, and about Ivonna development.

How long have you been doing unit testing in the ASP.Net space?

I don't remember exactly, but I guess it was around 2005, soon after I discovered TDD.

What was the most painful thing you found about the process?

I was using NUnitAsp. It's a client-side tool that performs an HTTP request and parses the response, trying to figure out the page structure. While it's much better than just verifying the raw HTML, there are many problems with this approach: 

In fact, after trying it for a while, I decided that it's not worth the effort.

How does Ivonna add to Typemock Isolator’s capabilities to make it even simpler to test ASP.Net applications?

Ivonna lets you execute the ASP.Net requests in-process, relying on Isolator's capabilities to access and/or modify the inner stuff that is unreachable otherwise. In addition, Ivonna lets you work with your pages in an intuitive way, similar to how you would write a Windows Forms test. For example, you can enter a text into a TextBox, or verify some Label's Text property, rather than working with input and span elements. In other words, while the WebForms framework abstracts away all HTML/HTTP intrinsics (or tries its best to), Ivonna does the same for your tests.

Do you see advancement in unit testing that can drive people who don’t do unit tests to do them?

Definitely. First, test frameworks become easier to use, "closer to the common people" I'd say. The AAA (Arrange-Act-Assert) structure and fluent syntax are very helpful here.

Second, there's a lot of pressure. Lots of blog posts and articles implying that not knowing unit testing is uncool, major companies make unit testing experience a job requirement, even Microsoft urging us to write tests.

Unfortunately, unit testing done wrong can be a painful experience (and I've been through that), and that turns many developers away from it.

How did you use CThru in Ivonna? What purpose did it serve?

Artem: I was very fascinated when I first looked at the possibilities that CThru offered. On one hand, I needed the power that only Isolator could give me. On the other hand, I didn't need mocks or stubs, I needed some custom code executed at a particular point. That's what AOP (Aspect Oriented Programming) frameworks are for. So, I had to invent my own (NJect, not to be confused with Ninject), which was actually two screens of code. But I digress.

When I was planning the second major version of Ivonna, CThru just came out. After looking at its features, I understood that this is exactly what I need. While the first version needed Isolator just to get a reference to the currently executing HttpHandler, the second one required more powerful tricks, and that's where CThru really shined.

For example, making the configuration mutable requires certain method calls to be stubbed, but these calls are made in the AppDomain of the Asp.Net request, just after this AppDomain is created, before you are able to run any code in it. I could do it with CThru (although it was tricky). In other places, all I needed was a simple stub, but I made it with CThru as well, just to make the code more consistent.

Another use for CThru is tracing. I've done a lot of traces at the exploration phase. Yes you have Reflector, but it provides a static picture. At some point you really need to know which methods are being called, which arguments are passed etc., especially with a complicated framework like ASP.Net. Using CThru, it takes just a line of code to achieve that. But you can do even more: set breakpoints, evaluate arguments and return values etc.

What about other parts of web development? MVC and AJAX – what features make them easy or hard to test?

While it is widely known that MVC has been built with great support for unit testing, it's still hard to write integration tests, and this is where Ivonna could help. However, what we have here is not a Page object with its hierarchy of controls, each with properties that we could test. Instead, all we have is raw HTML, so it's not much different from client-side testing tools. What Ivonna can offer here is support for configuration changes, authenticated requests, and Typemock Isolator integration, which is about Arrange and Act, but the Assert part remains the same -- finding a particular piece of html in the server output.

That said, when MVC is done right, you can easily get away with unit tests, which is great, of course.

With AJAX, it is different. Unless you do it the UpdatePanel style, AJAX is more about client side behavior, so you might want to use browser-driving tools like WatiN or Selenium. UI testing is traditionally considered hard and not worth it, so I'm trying to avoid it as long as I can. Especially after a friend of mine told me that the full suite of their WatiN tests takes four hours.

What is the status of Ivonna now? What are your plans for the future?

Ivonna is moving towards its 2.1 release, which will include support for page methods and UpdatePanels, as well as user control testing enhancements. In addition, I'd like to make it more usable, so I plan to add an Ivonna project template and optimize the performance. I'd be happy to hear your suggestions.

The next major version will combine client and server side testing.

You'll be able to drive your browser with WatiN, intercept the Web request with Ivonna, fake the response, and verify the browser behavior, for example. And many other things. Again, suggestions are more than welcome.