In MbUnit, you can add a class and decorate it with the AssemblyFixtureAttribute, and the FixtureSetup decorated method will be run once before all tests. Remember, however, that if you want to use it with Ivonna tests, you should decorate the class with RunOnWebAttribute, just like a regular test class.

All active development is currently done on the 3.0 branch, which is going to be more MVC-oriented (and let you extend it if you prefer other frameworks like Monorail, or FubuMVC, or Open Rasta). So, if you have a suggestion, just comment on this post, or use the forum.

My first idea was, I've got something like a WebForms UserControl here, so I'd go for a RenderAction call. So, in my test I'll make sure that this method is called with proper parameters. If you're smarter than that, you can see that I'm tying my test to the implementation. Instead of "what", I'm testing "how". Should I change my implementation to calling RenderPartial or DisplayFor, my test breaks, although I still have my implementation done correctly.

To get it "right" (and you can guess there's no absolutely right way here), I think about what it means, "display a list of thingies". My guess is that it means two things, data and view, put together and displayed as part of the page. Now, getting the correct data is not the concern of this test (you should write a unit test here), but getting the correct partial View is the job for Ivonna. And after a quick Reflector session (or, better, using the built-in TraceAspect from CThru), we realize that all various implementations ultimately go through IViewEngine.FindPartialView. And all we have to do is spy on these calls, collect the arguments, and make sure that there's been a call to this method with a correct argument (that is, the path to your partial). This way, unless you move or rename the partial, the test stays green even if your implementation changes.

This CThru aspect can be useful in many other scenarios, so I'm going to include it in the next version of Ivonna, which will contain lots of other MVC related features.

This exception usually happens when the Asp.Net engine cannot create an instance of an HttpContext. However, the inner exception is not provided (who needs it anyway?), so you're left in the dark. In this case, the actual exception happens inside the HttpRequest.ClientFilePath property getter. It now allows only absolute paths for some reason.

The fix is going to be released at some point next week.

Wait, isn't MVC testable by design? Yes, most of it is testable, but as for the Views, you have to resort to integration tests (which isn't bad by itself, but sometimes is not enough).

In my recent project, I needed to write a test verifying that if a user is not authenticated, she should see a login form and a registration form. Speaking in terms of implementation, this means that Html.RenderPartial should be invoked with paths to my partial views containing these forms. Looks like a good task for TypeMock Isolator, but I prefer working with CThru. Here's the test code (forgive me for not following the strict rules, such as one assert per test, this is just for clarity):

Imports WebTests.Infrastructure

Imports Ivonna.Framework

Imports MbUnit.Framework

Namespace Membership

    <TestFixture(), RunOnWeb()> _

    Public Class OwnersPage_NotLoggedIn

        <Test()> _

        Public Sub ContainsLoginPartial()

            'Arrange

            Dim spy As New RenderPartialSpy

            CThru.CThruEngine.AddAspect(spy)

            Dim session As New TestSession

            'Act

            session.ProcessRequest(New WebRequest("Owners"))

            'Assert

            Assert.Contains(spy.ViewNames, "~/Views/Account/Login.ascx")

            Assert.Contains(spy.ViewNames, "~/Views/Account/Register.ascx")

        End Sub

    End Class

End Namespace

The RenderPartialSpy class can be reused (this is why I prefer CThru), here's the code for it:

Imports CThru

Imports System.Web.Mvc.Html

Namespace Infrastructure

  Public Class RenderPartialSpy

    Inherits Aspect

    Public Overrides Function ShouldIntercept(ByVal info As CThru.InterceptInfo) As Boolean

      Return info.TypeName.Contains("RenderPartialExtensions") AndAlso info.MethodName = "RenderPartial"

    End Function

    Private _viewNames As New List(Of String)

    Public ReadOnly Property ViewNames() As IList(Of String)

      Get

        Return _viewNames

      End Get

    End Property

    Public Overrides Sub MethodBehavior(ByVal e As CThru.DuringCallbackEventArgs)

      Me.ViewNames.Add(e.ParameterValues(1))

      MyBase.MethodBehavior(e)

    End Sub

  End Class

End Namespace

Here I just set it to intercept all calls on the RenderPartialExtensions class with the method name "RenderPartial". When the call is intercepted, I save the value of the second argument (remember this is an extension method) in my list. At the Assert stage, I'll be able to retrieve all saved values and check them.

The focus of this release is on AJAX support. While Ivonna still doesn't deal with client side stuff, you can now fake an AJAX request and test the server's response.

Let's see the code:

var session = new TestSession();

var result = 
      session.ExecuteAjaxMethod(
           "Page.aspx",
            "MethodName",
            new {name="John"});

Assert.AreEqual("Hi John!", result);

Note that I'm using an anonymous class object to pass the arguments.

The code above would work with JSON-formatted Web services as well (note that you wouldn't use SOAP formatted services with AJAX anyway). If you need to return a custom object, you can use a generic overload of the same method.

There's also another, simpler alternative for doing AJAX: UpdatePanel. While most serious developers frown upon it, it remains a nice option for doing it quick (and dirty) if the performance and traffic is not an issue. While there's not much you can test with it, Ivonna provides a way to execute a request coming from inside an UpdatePanel:

var session = new TestSession();

session.GetPage("HasUpdatePanel.aspx");

var response = 
    session.ProcessRequest
    (session.CreateUpdatePanelRequest
    ("Button1"));

That's all for AJAX functionality in the current release. I'd probably have to fix a few bugs or provide more options and better API in the future releases. Please give me some feedback in the Forums.

As for the optimization stuff, I already wrote about it in the previous post, so there's not much to add.

So, what's the roadmap for 2.2? I guess it's going to be extensibility. The code is complicated enough to introduce an IoC container (it's going to be StructureMap), and I'd like to open some possibilities for custom request and response types, as well as modify the initialization aspects for advanced scenarios. You are welcome, as always, to suggest an extension you want, and I'll make Ivonna flexible enough to satisfy your needs.

One of the most annoying things about Ivonna was her bad performance on startup. Every time I needed to run a test, the Asp.Net engine cleared the temp folder and recompiled the whole site. It would take up to several minutes, depending on the number of pages. So, in the 2.1 release, I decided to stub the whole thing. The startup time dropped to several seconds, which is sort of acceptable (note that each test itself takes much less time to run).

Everything went fine until I put some code in an App_Code class, and Ivonna couldn't load it. It turned out that no changes in the App_Code folder could be recognized by the test. However, changes in the codebehind are recognized.

The workaround is, whenever you make a change to or create an App_Code class, be sure to delete the temporary site folder, which is usually under the C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\ folder.