clausn.dk

Testing Sitecore using WebformsMVP and Moles from RiSE

cln — Tue, 19 Oct 2010 22:08:43 +1000

My previous two posts introduced WebformsMVP (part 1, part 2), in order to get a separtion of markup and logic in ASP.NET applications. This post will give an introduction to using the WebformsMVP in a real world scenario on a CMS called Sitecore.

What you need:

Sitecore (I tested with Sitecore 6.0.0 rev 090120, but any Sitecore installation could be used)
Visual Studio 2010
Moles from RiSE
Rhino Mocks (I use 3.6)

Introduction to Moles
Research in Software Engineering (RiSE) at Microsoft Research have created two projects, Pex and Moles. It allows for Isolation and White box Unit Testing for .NET, where Pex automatically generates test suites with high code coverage and Moles allows to replace any .NET method with a delegate. (Moles is free, but Pex is not, use MSDN subscription or other to obtain).

The following video demonstrates a simple example using Moles: Moles - Replace any .NET method with a delegate. However, the video is a bit old, but the directions below should be updated .

The project

For a new project we received, I had to create a way to change the admin password, since the customer was not aware of its value. So this simple project is going to create a control to reset the admin password and we are going to test it..

The project structure:

Website
Website.Logic
Website.Logic.Tests

Taken from the model provided by WebformsMVP.

Our project consists of a UserControl which displays the new password, a presenter which changes the password and a test class for testing the presenter.
The UserControl uses a simple model:

   1:  public class ChangePassword

   2:  {

   3:      public string Password { get; set; }

   4:  }

The markup is also pretty simple:

   1:  New password: <%= this.Model.Password %>

The presenter attaches to the View.Load event and releases in ReleaseView, but I won’t show that here. The View_Load event listener is displayed below:

   1:  var password = "No success";

   2:  var domain = Sitecore.Security.Domains.Domain.GetDomain("sitecore");

   3:  if (domain != null)

   4:  {

   5:      var userQuery = from u in domain.GetAccounts()

   6:                      where u.Name.Equals("sitecore\\admin", StringComparison.CurrentCultureIgnoreCase)

   7:                      select u;

   8:      var user = userQuery.FirstOrDefault();

   9:      if (user != null)

  10:      {

  11:          var mUser = Membership.GetUser(user.Name);

  12:          if (mUser != null)

  13:          {

  14:              try

  15:              {

  16:                  password = mUser.ResetPassword();

  17:              }

  18:              catch (Exception)

  19:              {

  20:                  // Missing logging

  21:              }

  22:          }

  23:      }

  24:  }

  25:  View.Model = new ChangePassword { Password = password };

The above code is pretty straightforward, but the testing could be rather complex. First of we have an issue with mocking the static method GetDomain from the Domain class. However Moles saves us from a lot of pain!

Add a reference to the logic class library, to Rhino.Mocks, WebformsMVP and Microsoft.Moles.Framework in the test project and add a reference to Sitecore.Kernal from the /bin folder of the Sitecore website.
Having installed Moles, you get an option to “mock” an assembly via Visual Studio. Right click on the Sitecore.Kernel assembly reference in the test project and select “Add Moles Assembly”:

This will add a file to your project called “Sitecore.Kernel.moles” and when you build (Takes a long time the first time), Moles create an extra assembly called Sitecore.Kernal.Moles:

Now we are ready to create our first test method:

   1:  [TestMethod]

   2:  [HostType("Moles")]

   3:  public void ViewLoadNoAdminAccountFound()

   4:  {

   5:      // Arrange

   6:      var expectedPassword = "No success";

   7:      var view = MockRepository.GenerateStub<IView<ChangePassword>>();

   8:      var presenter = new ResetAdminPasswordPresenter(view);

   9:      var accounts = new List<Account>();

10:

  11:      // Redirect Domain.GetDomain to our delegate

  12:      MDomain.GetDomainString = (s) =>

  13:      {

  14:          var dom = MockRepository.GenerateMock<Domain>(s);

  15:          dom.Stub(d => d.GetAccounts()).Return(accounts.AsEnumerable());

  16:          return dom;

  17:      };

18:

  19:      // Act

  20:      view.Raise(v => v.Load += null, null, null);

  21:      presenter.ReleaseView();

22:

  23:      // Assert

  24:      Assert.AreEqual<string>(expectedPassword, view.Model.Password);

  25:  }

The attribute [TestMethod] comes from MSTest and [HostType(“Moles”)] comes from the Moles project. The last attribute tells the runtime to go Moles

We use the Arrange, Act and Assert (AAA) method of testing our method, where we don’t expect the presenter to find the needed account, to see how it handles specific cases.
First we expect the password to display as “No success”, since the presenter displays this text if the password hasn’t been changed. Afterwards we mock our view and we create an instance of the presenter we want to test. Next we setup an empty account list, to simulate the missing account.
The last step sets up a redirect of the call to Domain.GetAccounts(“sitecore”), in order for us to mock the Sitecore calls. The MDomain is a class in the Sitecore.Kernel.Moles assembly with the namespace “Sitecore.Security.Domains.Moles”. We use the Moles naming convention of the Domain.GetDomain(string domain) to MDomain.GetDomainString and setup a delegate to handle the call. The delegate contains a mock of the domain we want to retrieve accounts from and setup the domain to return our list of accounts.

Lastly we act in normal fashion, as we raise the load event and releases the view. Afterwards we can assert that the password is as expected.

Admin account found but Memebership provider returns null
The next test assumes that the membership provider returns null:

   1:  [TestMethod]

   2:  [HostType("Moles")]

   3:  public void ViewLoadAdminAccountFoundButMembershipAccountIsMissing()

   4:  {

   5:      // Arrange

   6:      var username = "sitecore\\admin";

   7:      var expectedPassword = "No success";

   8:      var view = MockRepository.GenerateStub<IView<ChangePassword>>();

   9:      var presenter = new ResetAdminPasswordPresenter(view);

  10:      // Mock admin account

  11:      var adminAccount = MockRepository.GenerateMock<Account>(username, AccountType.User);

  12:      adminAccount.Stub(a => a.Name).Return(username);

  13:      // Create user list with admin account

  14:      var accounts = new List<Account>() { adminAccount };

15:

  16:      // Redirect Domain.GetDomain to our delegate

  17:      MDomain.GetDomainString = (s) =>

  18:      {

  19:          var dom = MockRepository.GenerateMock<Domain>(s);

  20:          dom.Stub(d => d.GetAccounts()).Return(accounts);

  21:          return dom;

  22:      };

  23:      // Mock user return from Membership db - return null

  24:      MMembership.GetUserString = (un) => null;

25:

  26:      // Act

  27:      view.Raise(v => v.Load += null, null, null);

  28:      presenter.ReleaseView();

29:

  30:      // Assert

  31:      Assert.AreEqual<string>(expectedPassword, view.Model.Password);

  32:  }

What’s changed is the account list which has an added account we are mocking (Supplying username and AccountType to the constructor). We are still redirecting the call to the domain and returning the account list, but now we also redirect the Membership.GetUser –call, because we want to mock the behavior of Sitecore. This first test method, we tell the runtime to return null, when GetUser is called with a string.

The test expects that a password has been set to “No success”, and thereby no exceptions are thrown.

Admin account and membership accounts return expected values, but reset password throws exception
The next test simulates that the ResetPassword method of the MemberShipUser throws an exception:

   1:  [TestMethod]

   2:  [HostType("Moles")]

   3:  public void ViewLoadAdminAccountFoundButMembershipPasswordResetThrowsException()

   4:  {

   5:      // Arrange

   6:      var username = "sitecore\\admin";

   7:      var expectedPassword = "No success";

   8:      var exceptionToThrow = new Exception("Cannot reset password");

   9:      var view = MockRepository.GenerateStub<IView<ChangePassword>>();

  10:      var presenter = new ResetAdminPasswordPresenter(view);

  11:      // Mock admin account

  12:      var adminAccount = MockRepository.GenerateMock<Account>(username, AccountType.User);

  13:      adminAccount.Stub(a => a.Name).Return(username);

  14:      // Create user list with admin account

  15:      var accounts = new List<Account>() { adminAccount };

16:

  17:      // Redirect Domain.GetDomain to our delegate

  18:      MDomain.GetDomainString = (s) =>

  19:      {

  20:          var dom = MockRepository.GenerateMock<Domain>(s);

  21:          dom.Stub(d => d.GetAccounts()).Return(accounts);

  22:          return dom;

  23:      };

  24:      // Mock user return from Membership db

  25:      // Mock ResetPassword to throw an exception

  26:      MMembership.GetUserString = (un) =>

  27:      {

  28:          var user = MockRepository.GenerateMock<MembershipUser>();

  29:          user.Stub(u => u.UserName).Return(un);

  30:          user.Stub(u => u.ResetPassword()).Throw(exceptionToThrow);

  31:          return user;

  32:      };

33:

  34:      // Act

  35:      view.Raise(v => v.Load += null, null, null);

  36:      presenter.ReleaseView();

37:

  38:      // Assert

  39:      Assert.AreEqual<string>(expectedPassword, view.Model.Password);

  40:  }

Here we change the GetUserString from a delegate that returns null to a delegate that returns a mocked MemberShipUser that throws an exception when calling ResetPassword.

Here we expect no Exceptions to be thrown and still expecting the password to be “No Success”.

Password updates
The last test case is when the password is updated:

   1:  [TestMethod]

   2:  [HostType("Moles")]

   3:  public void ViewLoadAdminPasswordUpdates()

   4:  {

   5:      // Arrange

   6:      var username = "sitecore\\admin";

   7:      var password = "abcd12345";

   8:      var view = MockRepository.GenerateStub<IView<ChangePassword>>();

   9:      var presenter = new ResetAdminPasswordPresenter(view);

  10:      // Mock admin account

  11:      var adminAccount = MockRepository.GenerateMock<Account>(username, AccountType.User);

  12:      adminAccount.Stub(a => a.Name).Return(username);

  13:      // Create user list with admin account

  14:      var accounts = new List<Account>() { adminAccount };

15:

  16:      // Redirect Domain.GetDomain to our delegate

  17:      MDomain.GetDomainString = (s) =>

  18:      {

  19:          var dom = MockRepository.GenerateMock<Domain>(s);

  20:          dom.Stub(d => d.GetAccounts()).Return(accounts);

  21:          return dom;

  22:      };

  23:      // Mock user return from Membership db

  24:      // Mock ResetPassword to return a value we can compare

  25:      MMembership.GetUserString = (un) =>

  26:      {

  27:          var user = MockRepository.GenerateMock<MembershipUser>();

  28:          user.Stub(u => u.UserName).Return(un);

  29:          user.Stub(u => u.ResetPassword()).Return(password);

  30:          return user;

  31:      };

32:

  33:      // Act

  34:      view.Raise(v => v.Load += null, null, null);

  35:      presenter.ReleaseView();

36:

  37:      // Assert

  38:      Assert.AreEqual<string>(password, view.Model.Password);

  39:  }

We setup a sunshine scenario where the password is updated. We do this by mocking the MemberShipUser to return a predefined password and Assert that the value of the View’s Model is equal to the expected password. Otherwise something would have gone wrong..

Outro
The above example shows how it’s possible to intercept calls to a static method or property in order to test Sitecore behavior via mocking.

Comments are welcome, since testing is rather new for me .

World War II, told with Facebook terminology

cln — Thu, 19 Aug 2010 17:17:15 +1000

This is an unusual post, but I simply have to share this story about world war II!

Great fun!

WebformsMvp – Part 2

cln — Wed, 28 Jul 2010 19:06:54 +1000

In the first blog post, we covered the basics of creating a user control with WebformsMVP. In this blog post we’ll look at another example: Deletion of a news item. The example might be simple to understand, but there is some logic to cover. Our frontpage displayed a list of news items with respective edit and delete links, which only link to another page. From EditNewsItem.aspx we can edit a news item and from DeleteNewsItem.aspx we can delete a news item – it’s a confirmation page…

Remember: Presenter first

Our first step is to create our presenter: “NewsItemDeletePresenter”:

     public class NewsItemDeletePresenter : Presenter<INewsItemDelete>

The difference to our first presenter is the generic parameter for the base presenter class, in this case an interface called “INewsItemDelete”, which looks like this:

    public interface INewsItemDelete : IView<NewsItem>

    {

        event Action<NewsItem> NewsItemDeleting;

    }

This interface inherits from “IView<NewsItem>”, which would be a normal approach to using presenters. We want our model to be a “NewsItem”, but we also want a possibility to act when a button is clicked to delete the news item. Hence we add an event to the interface between the presenter and view, called “NewsItemDeleting”. The type of event is an “Action<NewsItem>”, which gives us a prototype of a receiving method like so:

    void View_NewsItemDeleting(NewsItem newsItem)

So, creating our constructor looks like this:

    public NewsItemDeletePresenter(INewsItemDelete view, IData data, ILogging logging)

        : base(view)

    {

        _data = data;

        _logging = logging;

        View.Load += View_Load;

        View.NewsItemDeleting += View_NewsItemDeleting;

    }

    public override void ReleaseView()

    {

        View.Load -= View_Load;

        View.NewsItemDeleting -= View_NewsItemDeleting;

    }

We set our data and logging variables and listen to both the view’s “Load” and “NewsItemDeleting” events. The “ReleaseView” is also shown here, since it is rather simple – we clean up our event subscriptions.

Next we implement the 2 methods for our event subscription. The “View_Load” first.

Load

    void View_Load(object sender, EventArgs e)

    {

        Guid newsId;

        if (!Guid.TryParse(this.Request["id"], out newsId))

        {

            this.Response.Redirect("default.aspx", true);

            return;

        }

        var newsItem = _data.GetNewsItem(newsId); 

        if (newsItem == null)

        {

            this.Response.Redirect("default.aspx", true);

            return;

        }

        View.Model = newsItem as NewsItem;

    }

Our first step is to retrieve the id from the query string and parse it to a valid “Guid” object. If this is not possible, we cannot find it in the data layer. This means we should redirect back to “default.aspx”, if no valid id can be found.

What you’ll notice here is the “this.Request” and “this.Response” property provided by base Presenter class. You have access to both “Cache”, “HttpContext”, “RouteData”, “Request”, “Response”, “Server” and a couple other properties, which enables you to get URL strings and info, redirect, get server values, etc. What’s missing is the “Session” property, which is on purpose. The argument being from the framework builder’s is, that sessions don’t scale (another discussion, but not in this blog series).

If we get a valid “Guid” from the url parameter “id”, we retrieve the news item from the data layer and check if it returns a “null”-value. If the value is “null”, we also redirect back, because a valid “Guid” id could be passed to the page, but that does not mean it exist in the data layer.

Lastly we set the views mode to our retrieved news item.

Load Test

We will not be performing a load test, but we will test the load method!

Our first goal is to test the first portion of the method, which checks for a valid “Guid” via the “this.Requst” property. This test shows the power of WebformsMVP, since it allows us to abstracts the webserver away. With Rhino, we can mock the “HttpContext”, “HttpRequest” and “HttpResponse” like so (We are still using the Arrange, Act and Assert (AAA) method):

    [TestMethod]

    public void ViewLoadParsesIdButCannotParseGuidFromRequest()

    {

        // Arrange

        var view = MockRepository.GenerateStub<INewsItemDelete>();

        var data = MockRepository.GenerateMock<IData>();

        var logging = MockRepository.GenerateMock<ILogging>();

        var httpContext = MockRepository.GenerateMock<HttpContextBase>();

        var httpRequest = MockRepository.GenerateMock<HttpRequestBase>();

        var httpResponse = MockRepository.GenerateMock<HttpResponseBase>();

        var requestEntry = "id";

        var requestValue = "sdf34rsdfsdgcfg3j";

        var redirectUrl = "default.aspx";

        httpRequest.Stub(r => r[requestEntry]).Return(requestValue);

        httpResponse.Expect(r => r.Redirect(redirectUrl, true));

        httpContext.Stub(h => h.Request).Return(httpRequest);

        httpContext.Stub(h => h.Response).Return(httpResponse);

        var presenter = new NewsItemDeletePresenter(view, data, logging)

        {

            HttpContext = httpContext

        };

        // Act

        view.Raise(v => v.Load += null, view, new EventArgs());

        presenter.ReleaseView();

        // Assert

        httpResponse.VerifyAllExpectations(); // Expect redirect

    }

We setup view, data and logging, and we setup both “HttpContext”, “HttpRequest” and “HttpResponse” using a mock of the base classes “HttpContextBase”, “HttpRequestBase” and “HttpResponseBase”. These classes are provided by the .NET framework in “System.Web.Abstractions”. We will see their use in just a minute.

Next we define our request entry and value and redirect URL. This is to simplify the reading of the code, but it also makes it possible in other scenarios to assert what actually happened.

Lastly we arrange what should happen, so we create the “httpRequest” mock, and instruct it to return our “requestValue”, if someone accesses the entry “requestEntry”. This means that for future references of “httpRequest[‘id’]”, the object returns “sdf34rsdfsdgcfg3j”.
For the “httpResponse” object, we expect that the redirect method is going to be called with the “redirectURL” and “true” as parameters, because that the presenter cannot validate the “requestValue” as a “Guid”.
Last we setup the “httpContext” to return “httpRequest” and “httpResponse” when accessing their respective properties on the object.

We can now create our presenter, and set is “HttpContext” to the mocked context we just created.

Now we “replay” the scenario by raising the view’s load event and supplying the parameters. Afterwards we release the view and we can assert our expectations.
In this scenario, we only expect the “httpResponse” object to have its “Redirect” method called with certain properties. If this does not happen, the test will fail.

The next test tests almost the same thing when retrieving a news item from the datalayer. We expect a redirect if no news item can be found, but I won’t show this here, you can look in the code.

What’s more interesting is that I have actually not coded the method very well. Take a look at this test:

    [TestMethod]

    public void ViewLoadParsesIdButDataLayerThrowsException()

    {

        // Arrange

        var view = MockRepository.GenerateStub<INewsItemDelete>();

        var data = MockRepository.GenerateMock<IData>();

        var logging = MockRepository.GenerateMock<ILogging>();

        var httpContext = MockRepository.GenerateMock<HttpContextBase>();

        var httpRequest = MockRepository.GenerateMock<HttpRequestBase>();

        var httpResponse = MockRepository.GenerateMock<HttpResponseBase>();

        var requestEntry = "id";

        var requestValue = "E4B202593D9E4D8EA16A02091EBC439F";

        var redirectUrl = "default.aspx";

        var newsId = Guid.Parse(requestValue);

        var dataLayerException = new Exception();

        data.Stub(d => d.GetNewsItem(newsId)).Throw(dataLayerException);

        httpRequest.Stub(r => r[requestEntry]).Return(requestValue);

        httpResponse.Expect(r => r.Redirect(redirectUrl, true));

        httpContext.Stub(h => h.Request).Return(httpRequest);

        httpContext.Stub(h => h.Response).Return(httpResponse);

        var presenter = new NewsItemDeletePresenter(view, data, logging)

        {

            HttpContext = httpContext

        };

        // Act

        view.Raise(v => v.Load += null, view, new EventArgs());

        presenter.ReleaseView();

        // Assert

        httpResponse.VerifyAllExpectations(); // expect redirect

    }

It’s almost the same, but includes a call to the data layer, where it throws an exception. This gives me the following error message when running the test: “WebformsMvpDemo.Logic.Tests.NewsItemDeletePresenterTests.ViewLoadParsesIdButDataLayerThrowsException threw exception: ...”
We better “try-catch” the call to the data layer – new “View_Load” method:

    void View_Load(object sender, EventArgs e)

    {

        Guid newsId;

        if (!Guid.TryParse(this.Request["id"], out newsId))

        {

            this.Response.Redirect("default.aspx", true);

            return;

        }

        NewsItem newsItem = null;

        try

        {

            newsItem = _data.GetNewsItem(newsId); // Do not set View.Model directly if you test for View.Model == null. When View.Model is null the framwork throws an exception

        }

        catch (Exception ex)

        {

            newsItem = null;

            _logging.Write(string.Format("Could not retrieve news item for id: '{0}'.", newsId.ToString("N")), ex);

        }

        if (newsItem == null)

        {

            this.Response.Redirect("default.aspx", true);

            return;

        }

        View.Model = newsItem;

    }

Much better, and the test does not fail!

The last test before user interaction, where everything works (a sunshine scenario), will not be written here – look in the code .

Deletion of news item

Next up, the “View_NewsItemDeleting” method. Our event prototype defines a method with a single parameter, a “NewsItem”. We need to implement a method that handles the deletion of the particular news item, and then redirect back to the news list:

    void View_NewsItemDeleting(NewsItem newsItem)

    {

        try

        {

            _logging.Write(string.Format("Deleting news item with id: '{0}'.", newsItem.Id.ToString("N")));

            _data.DeleteNewsItem(newsItem);

            _logging.Write(string.Format("News item with id: '{0}', was deleted.", newsItem.Id.ToString("N")));

        }

        catch (Exception e)

        {

            _logging.Write(string.Format("Could not delete news item with id: '{0}'", newsItem.Id.ToString("N")), e);

        }

        this.Response.Redirect("default.aspx");

    }

This method could do some more stuff, like showing an error message if the news item cannot be deleted etc., but for simplicity the method is kept short.

Delete test

The test is rather straightforward and is composed of 2 test methods. The first presented is where the data layer throws an exceptions:

    [TestMethod]

    public void ViewUpdatesNewsButDataLayerTrowsException()

    {

        // Arrange

        var view = MockRepository.GenerateStub<INewsItemDelete>();

        var data = MockRepository.GenerateMock<IData>();

        var logging = MockRepository.GenerateMock<ILogging>();

        var httpContext = MockRepository.GenerateMock<HttpContextBase>();

        var httpRequest = MockRepository.GenerateMock<HttpRequestBase>();

        var httpResponse = MockRepository.GenerateMock<HttpResponseBase>();

        var requestEntry = "id";

        var requestValue = "4c278cea5c2145d395a64a9188d960c4";

        var redirectUrl = "default.aspx";

        var newsId = Guid.Parse(requestValue);

        var newsItemFromDb = new NewsItem { Id = newsId, Date = DateTime.Now, Title = "News item 1", Content = "Hello world" };

        var newsItemFromView = new NewsItem { Id = newsId, Date = DateTime.Now, Title = "News item 1-2", Content = "Hello world3" };

        var exception = new Exception();

        var loggingStartMessage = string.Format("Deleting news item with id: '{0}'.", newsItemFromView.Id.ToString("N"));

        var loggingExceptionMessage = string.Format("Could not delete news item with id: '{0}'", newsItemFromView.Id.ToString("N"));

        data.Stub(d => d.GetNewsItem(newsId)).Return(newsItemFromDb);

        data.Stub(d => d.DeleteNewsItem(newsItemFromView)).Throw(exception);

        logging.Expect(l => l.Write(loggingStartMessage));

        logging.Expect(l => l.Write(loggingExceptionMessage, exception));

        httpRequest.Stub(r => r[requestEntry]).Return(requestValue);

        httpResponse.Expect(r => r.Redirect(redirectUrl));

        httpContext.Stub(h => h.Request).Return(httpRequest);

        httpContext.Stub(h => h.Response).Return(httpResponse);

        var presenter = new NewsItemDeletePresenter(view, data, logging)

        {

            HttpContext = httpContext

        };

        // Act

        view.Raise(v => v.Load += null, view, new EventArgs());

        view.Raise(v => v.NewsItemDeleting += null, newsItemFromView);

        presenter.ReleaseView();

        // Assert

        httpResponse.VerifyAllExpectations(); // expect redirect

        logging.VerifyAllExpectations(); // expect logging

    }

We use the items from arrange again and add an exception and logging message, since the datalayer throws an exception when calling “DeleteNewsItem”.

In the act-part, we raise both the views “load” and “NewsItemDeleting” events, to initiate the deletion of the news item.

Lastly we assert that a redirect has been started and that the logging has occurred.

A success scenario is described in the last test:

    [TestMethod]

    public void ViewDeletesNewsAndSucceeds()

    {

        // Arrange

        var view = MockRepository.GenerateStub<INewsItemDelete>();

        var data = MockRepository.GenerateMock<IData>();

        var logging = MockRepository.GenerateMock<ILogging>();

        var httpContext = MockRepository.GenerateMock<HttpContextBase>();

        var httpRequest = MockRepository.GenerateMock<HttpRequestBase>();

        var httpResponse = MockRepository.GenerateMock<HttpResponseBase>();

        var requestEntry = "id";

        var requestValue = "4c278cea5c2145d395a64a9188d960c4";

        var redirectUrl = "default.aspx";

        var newsId = Guid.Parse(requestValue);

        var newsItemFromDb = new NewsItem { Id = newsId, Date = DateTime.Now, Title = "News item 1", Content = "Hello world" };

        var loggingDebugBeginMessage = string.Format("Deleting news item with id: '{0}'.", newsItemFromDb.Id.ToString("N"));

        var loggingDebugEndMessage = string.Format("News item with id: '{0}', was deleted.", newsItemFromDb.Id.ToString("N"));

        data.Stub(d => d.GetNewsItem(newsId)).Return(newsItemFromDb);

        logging.Expect(l => l.Write(loggingDebugBeginMessage));

        logging.Expect(l => l.Write(loggingDebugEndMessage));

        httpRequest.Stub(r => r[requestEntry]).Return(requestValue);

        httpResponse.Expect(r => r.Redirect(redirectUrl));

        httpContext.Stub(h => h.Request).Return(httpRequest);

        httpContext.Stub(h => h.Response).Return(httpResponse);

        var presenter = new NewsItemDeletePresenter(view, data, logging)

        {

            HttpContext = httpContext

        };

        // Act

        view.Raise(v => v.Load += null, view, new EventArgs());

        view.Raise(v => v.NewsItemDeleting += null, newsItemFromDb);

        presenter.ReleaseView();

        // Assert

        httpResponse.VerifyAllExpectations(); // Expect redirect

        logging.VerifyAllExpectations(); // verify logging messages

    }

We now have tests that verify what we are doing in the presenter is valid. Next step is to create the actual UserControl – create a new UserControl called “NewsItemDelete” and open it’s code behind file. Here we change the inheritance from a “UserControl” to “MvpUserControl<NewsItem>” and also defines that we want to implement our extended view interface in “INewsItemDelete”. This gives us an implementation of our UserControl like so:

    [PresenterBinding(typeof(NewsItemDeletePresenter))]

    public partial class NewsItemDelete : MvpUserControl<NewsItem>, INewsItemDelete

    {

        protected void DeleteNewsItem(object sender, EventArgs e)

        {

            if (NewsItemDeleting != null)

            {

                NewsItemDeleting(this.Model);

            }

        }

        #region INewsItemDelete Members

        public event Action<NewsItem> NewsItemDeleting;

        #endregion

    }

Again, the “PresenterBinding”-attribute should be overlooked for now, but we assign a “NewsItemDeletePresenter” to use as our presenter. The “DeleteNewsItem” is an eventhandler for a “Button” in the markup:

    <table cellpadding="2" cellspacing="0">

        <tr>

            <td>Id:</td>

            <td><%   1: : this.Model.Id.ToString("N") %></td>

        </tr>

        <tr>

            <td>Title:</td>

            <td><%   1: : this.Model.Title %></td>

        </tr>

        <tr>

            <td>Date:</td>

            <td><%   1: : this.Model.Date.ToString("dd/MM-yyyy") %></td>

        </tr>

        <tr>

            <td>Content:</td>

            <td><%   1: : this.Model.Content %></td>

        </tr>

        <tr>

            <td>&nbsp;</td>

            <td><asp:Button ID="btnDeleteNewsItem" runat="server" OnClick="DeleteNewsItem" Text="Delete news item" /></td>

        </tr>

    </table>

The markup defines a table presenting the news item about to be deleted, and includes the button in the bottom row. The button has an “OnClick” event called “DeleteNewsItem” presented in the last code block.

When a user clicks the button, the UserControls raises the event “NewsItemDeleting”, if anyone listens to it. If our tests are valid, our presenter should listen to it and we have a loose coupling of logic and interaction (Disregarding the attribute, I know!).

Outro

We’ve created a simple interaction with a XML file that holds our news items. So far we can list and delete news items, but the code also contains the ability to create and edit news items. Feel free to look in the code for examples.

Get the code here.

WebformsMVP – Part 1

cln — Wed, 28 Jul 2010 18:24:19 +1000

Introduction

When developing projects with ASP.NET it can be a more or less troublesome experience to test the solution being generated. What it comes down to is separation of concerns.

Developing with Webforms in ASP.NET, it allows you to define your controls and layout (possibly via CSS) using markup and events can be hooking in a code behind file. This setup might work for a lot of cases, but it is still very hard to test and you have your logic combined with your presentation.

Introducing: WebformsMVP!

WebformsMVP is a framework for helping achieve separation of your logic, data and view. The name is short for (ASP.NET) Webforms Model-View-Presenter, where the Model is your data model (i.e. a database), the View is your user controls and the Presenter is your logic. User controls define how data is displayed, and the Presenters handle the logic of interacting with the model:

Two important parts are the communication between View and Presenter, and Presenter and Model. What’s more important, is the lack of communication between View and Model!

Compared to Model-View-Controller the View is a bit more responsible than a normal view, in the sense that user interaction occurs in the view and the initiation also happens in the view. What Model-View-Presenter adds, is the decupling of the presenter from the button clicks etc., but it still knows about ASP.NET.

Enough introduction, let’s learn how you use it!

Open Visual Studio (I’m using 2010), and set up the project with appropriate names in the following structure (Web application, class library and MS Test project respectively):

The sample project

The project I’m building is a news list creator. The purpose of the project is to list news, create, edit and delete them. I’m using a simple XML file for data, and using LINQ wherever possible. Testing is done with help from Rhino Mocks

Initial steps:

· Add WebformsMvp.dll to all projects

· Add a reference to Rhino.Mocks, System.Web and System.Web.Abstractions in the test project

In the following examples I’ll be using a class “NewsItem” with the following properties:

     public class NewsItem

    {

        public Guid Id { get; set; }

        public DateTime Date { get; set; }

        public string Title { get; set; }

        public string Content { get; set; }

    }

The class is placed in a subfolder in the Logic project under “Views” called “Models”, where the namespace is WebformsMvpDemo.Logic.Views.Models. The namespace will make sense when you start using the framework for more advances scenarios.

Create the presenter first

We want to create page with a UserControl that displays all the news items created in our XML file, and create respective links to edit and delete. Just above the list, we insert a link to create a new news item.

To create our UserControl, we first create our presenter (It will all make sense in the end J). In the project WebformsMvpDemo.Logic, create a folder called “Presenters” and create a normal class called “NewsListPresenter”. This class should extend the class WebFormsMvp.Presenter with the generic parameter “IView<List<NewsItem>>”, like so:

    public class NewsListPresenter : Presenter<IView<List<NewsItem>>>

In order to extend Presenter<T>, you have to implement the “ReleaseView”-method. This method will make sense in just a minute.

Next step is to implement a constructor for the “NewsListPresenter”, because the base class does not have a constructor with 0 parameters. The parameter type for the base constructor is the generic type of “IView<T>”, and in our case it is “List<NewsItem>”:

    public NewsListPresenter(IView<List<NewsItem>> view, IData data, ILogging logging) : base(view)

    {

        _data = data;

        _logging = logging;

        View.Load += View_Load;

    }

I’ll explain the last parameters in the next blog post, but for now assume that some magic happens and the correct “IData” and “ILogging” parameters are passed.

The constructor code sets the local variables for a data interface (i.e. your model), a logging interface and subscribes to the views “Load” -event. This load event is available through the WebformsMVP framework, and their argument being that most data is retrieved in the load method of a Page, UserControl, etc. Next we implement the “View_Load” –method:

    void View_Load(object sender, EventArgs e)

    {

        try

        {

            View.Model = _data.GetNewsItems();

        }

        catch (Exception ex)

        {

            View.Model = new List<NewsItem>();

            _logging.Write("Could not get news items from data layer", ex);

        }

    }

When the view loads, we want to retrieve the data to be displayed and catch any errors that might occur. It’s important to keep the views model initialized or an exception is going to be thrown when accessing it. In the catch of the data retrieval, we set the views model to en empty list and write an error to the logging framework. The “ReleaseView”-method simply releases our subscription to the views load event.

We are done implementing the presenter – next we have to test it!

Test

Wait, what? Yes, you read it right: Test

I’m going to be using Rhino Mocks to help with the tests. When using Rhino, you create a test case via the Arrange, Act and Assert (AAA) methodology. We first arrange our variables, dependencies and our expectations of the test, then we act to “play” the scenario and finally we assert our expectations:

    [TestMethod]

    public void NewsListPresenterGetsNewsItemsFromModel()

    {

        // Arrange

        var view = MockRepository.GenerateStub<IView<List<NewsItem>>>();

        var data = MockRepository.GenerateMock<IData>();

        var logging = MockRepository.GenerateMock<ILogging>();

        data.Stub((d) => d.GetNewsItems()).Return(new List<NewsItem>());

        var presenter = new NewsListPresenter(view, data, logging);

        // Act

        view.Raise(v => v.Load += null, view, new EventArgs());

        presenter.ReleaseView();

        // Assert

        Assert.IsNotNull(view.Model);

    }

Our test plays the scenario when we get the data in the views load event and sets the views model.
We first arrange our view, data and logging, which are our parameters for our presenter. Next we tell the mock of the data layer, that when someone calls “GetNewsItems”, it should return a new instance of a generic list of NewsItems. We can then setup our presenter.

The presenter is created from the actual implementation, and passing the respective view, data and logging parameters for the constructor. This is the class we want to test!

Next we can act on the presenter, as if the view is instantiated and a request is made to the UserControl where the “Load”-method is called. When calling the load event, you have to pass 2 parameters; an “Object” and “EventArgs”, representing the sender and the arguments for the method. After the load event has fired, we can call the presenters “ReleaseView”-method, to remove our subscription from the views load method. This is normally done by the framework.

Last we assert, to check if everything is alright. In this case we only have to check that the views model is not null, or we would have made some mistake.

What happens if the data layer throws an exception when called? Let’s find out:

    [TestMethod]

    public void NewsListPresenterGetsNewsItemsFromModelTrowsException()

    {

        // Arrange

        var view = MockRepository.GenerateStub<IView<List<NewsItem>>>();

        var data = MockRepository.GenerateMock<IData>();

        var logging = MockRepository.GenerateMock<ILogging>();

        var loggingMessage = "Could not get news items from data layer";

        var loggingException = new Exception();

        data.Stub((d) => d.GetNewsItems()).Throw(loggingException);

        logging.Expect((l) => l.Write(loggingMessage, loggingException));

        var presenter = new NewsListPresenter(view, data, logging);

        // Act

        view.Raise(v => v.Load += null, view, new EventArgs());

        presenter.ReleaseView();

        // Assert

        Assert.IsNotNull(view.Model);

        logging.VerifyAllExpectations();

    }

Again we arrange our view, data and logging, but in this case we also arrange a logging message and an exception, which we expect to occur.

The data layer is changed, so that when we call the “GetNewsItems”-method, it throws an exception. When the data layer throws an exception, we expect that the logging framework is going to be called with the parameters of a string and the exception thrown by the data layer.

We act on the presenter, and raise the load event. We then release the view from the presenter in “ReleaseView”.

Finally we assert, and we still make sure that the views model is nut null and then we verify all the expectations on the logging mock. The “VerifyAllExpectations” is an extension method from the Rhino framework, which helps assert any expectations setup by our code. In this case we expect that the logging framework is called with a specific string and exception thrown by the data layer.

Results:

Note
It’s important to note that the IData and ILogging implementations delivered to the presenter are assumed to be tested and valid. A separate project should implement and test these, where in this project it is not.

Finally – the UserControl

Create a new UserControl in a subfolder called “UserControls” and name it “NewsList” (In the web project). Here you get 3 files: NewsList.ascx, NewsList.ascx.cs and NewsList.ascx.designer.cs. Open up “NewsList.ascx.cs” and change the extended class to “MvpUserControl<List<NewsItem>>” and set a “PresenterBinding” attribute on top of the class with the argument “typeof(NewsListPresenter)” as its argument:

    [PresenterBinding(typeof(NewsListPresenter))]

    public partial class NewsList : MvpUserControl<List<NewsItem>>

    {

    }

This is your code behind file, which only needs other methods if any events or custom databing needs to occur.

Note
The “PresenterBinding” attribute is part of the WebformsMVP framework, but is supposed to disappear in a future version. The attribute tells the framework which presenter to use, and in future versions it will be discovered automatically via a naming convention as seen in ASP.NET MVC.

Using the class “MvpUserControl<T>” as the extended class compared to the normal “UserControl” from ASP.NET gives us access to the model delivered by the presenter. The generic argument of “MvpUserControl” is the type of the model shared. In our news list case, the model is a list of news items. We can access the model via the property “Model”, and use it in our markup – open the “NewsList.ascx” file:

    <a href="AddNewsItem.aspx">Add new news item</a><br />

    <asp:Repeater runat="server" DataSource="<%# this.Model %>">

        <HeaderTemplate>

            <table cellpadding="2" cellspacing="0" border="1">

        </HeaderTemplate>

        <ItemTemplate>

            <tr>

                <td>

                    <h3>

                        <%   1: # Server.HtmlEncode(((WebformsMvpDemo.Logic.Views.Model.NewsItem)Container.DataItem).Title) %></h3>

                    <p class="newsDate">

                        <%   1: # ((WebformsMvpDemo.Logic.Views.Model.NewsItem)Container.DataItem).Date.ToString("dd/MM-yyyy hh:mm")%></p>

                    <p>

                        <%   1: # Server.HtmlEncode(((WebformsMvpDemo.Logic.Views.Model.NewsItem)Container.DataItem).Content).Replace("\n", "<br />")%></p>

                </td>

                <td>

                    <a href="EditNewsItem.aspx?id=<%# ((WebformsMvpDemo.Logic.Views.Model.NewsItem)Container.DataItem).Id.ToString("N") %>">

                        Edit</a> | <a href="DeleteNewsItem.aspx?id=<%# ((WebformsMvpDemo.Logic.Views.Model.NewsItem)Container.DataItem).Id.ToString("N") %>">

                            Delete</a>

                </td>

            </tr>

        </ItemTemplate>

        <FooterTemplate>

            </table>

        </FooterTemplate>

    </asp:Repeater>

The markup contains a link to create a new news item and a Repeater that displays the news items. The Repeater has its datasouse set to “this.Model”, since “this.Model” is our list of news items. For each item in the model, a table row is created with two columns. The first column contains the content of the news item, with title, date and content, and the second contains links to edit and delete for the respective news item presented. What’s missing here is the strongly typed items in the repeater, so a cast has to be made from the “Container.DataItem” and then the properties can be accessed.

Conclusion

WebformsMVP delivers a way to separate and test logic from presentation of data. UserControls can layout and present data via styles and so forth, but the problem is usually the logic.

Next blog post will contain more information regarding testing of more advanced presenters.

Code will be available in a later blog post.

Palm Springs og LA

cln — Sat, 25 Jul 2009 15:20:26 +1000

Idag forlod vi Palm Springs efter at have nydt en aften ved et hyggeligt marked og afslapning ved pool’en:

Da mørket faldt på blev det for alvor hyggeligt:

Et hyggeligt marked, men med 41 grader var det næsten for varmt at gå rundt. Det var dejligt de sprøjtede vand ud fra butikkerne, således man lige kunne komme af med lidt varme. Da vi kom tilbage til hotellet kunne vi tage en dukkert i poolen for at blive kølet lidt af:

Det var dagen igår, men idag gik turen som beskrevet til Los Angeles, hvor vi som den første dag faktisk ikke har taget nogle billeder! Da hotellerne først kan garantere at værelset er frit typisk fra kl. 15, skulle vi finde noget at få dagen til at gå med og hvad er mere oplagt en at shoppe. Julia havde fundet et Mall i nærheden af hvor vi boede, som skulle være meget berømt. Der var 130 butikker som f.eks. Hugo Boss, Calvin Klein, Prada, Fossil, Nike, Levis, Diesel og mange flere – det bedste ved det var bare at det var outlet butikker, så priserne var meget bedre :)

Dagen gik altså med at slæbe og prøve det ene og det andet. Vi fik faktisk gået forbi alle 130 butikker, men undgik heldigvis at besøge dem alle. Der blev købt nederedele, skjorter, sweatere og undertøj, så nu skulle kufferten gerne være fyldt.. Lad os håbe det kan være der :)

Heart attack

cln — Fri, 24 Jul 2009 16:42:26 +1000

At forlade Grand Canyon var lidt hårdere end vi troede, så vi tog en tur langs kanten igen, inden vi skulle køre til Flagstaff:

Vi gik en tur rundt og besøgte et mindre Mall, hvor vi kunne kigge på butikker.
Under aftensmaden begyndte det at regne. På turen hjem kunne vi fange et billede:

Efter en afslapningsaften kunne vi køre vestpå mod Palm Springs, men først skulle vi forbi Pheonix:

Så blev jeg “indlagt”:

Så fik jeg en “Triple Bypass Burger”:

Efter maden fik jeg et hurtigt tjekup:

Herefter kunne vi fortsætte mod Palm Springs :)

Grand Canyon

cln — Fri, 24 Jul 2009 16:23:56 +1000

Så er Grand Canyon allerede overstået, hvor vi har fået set en masse. Vi havde 2 overnatninger ved kanten, hvor vi brugte en dag på at vandre ned i den og gå langs kanten. Derudover så vi en IMAX film, som viste en flot film med lidt historie og en masse flotte billeder af kløften.

Her starter vores tur ned i kløften:

Her går turen nedad:

Vi skulle gå ned ad stien, hvor der først ville være et sted de kalder “Uhh Ahh”. Der var ingen skilt der markerede stedet, men som brochuren sagde, så ville man vide når man var der. Det havde de ret i:

Dejlig sti rundt:

Det næste stoppested var Cedar Ridge:

Fantastisk udsigt:

Så gik turen op igen, som forventet var noget hårdere end turen ned:

Det er et stort hul i jorden:

På ovenstående billede kan man se platoet vi gik ned på. En fantastisk tur med en rigtig flot udsigt.
Da vi kom op trak det op til tordenvejr:

Vi fik en masse bulder og brag som var rigtig flotte.

Aftenen gik med at se solnedgangen over Grand Canyon:

En fantastisk oplevelse at se Grand Canyon!

Monument Valley

cln — Mon, 20 Jul 2009 14:39:25 +1000

Så nåede vi Kayente og dermed punkt K på vores kort.

Dagen er gået med at køre hertil fra Moab, som tog lidt over formiddagen med frokost og en optankning. Vi tog nemlig et stop ved “Four Corners”, hvor staterne Arizona, Utah, Colorado og New Mexico mødes i et enkelt punkt:

Nogen i min familie vil kunne kende dette punkt :)

Derefter var vi klar til at se Monument valley og det var bestemt en oplevelse værd.
Monument Valley er en dal fyldt med store klumper bjerge, som lettest kan beskrives ved at vise dem:

(Denne bliver kaldt tommelfingeren)

Her er et eksempel på, hvordan Navajo indianerne boede:

Der var også tid til at lave reklamefotos:

Vi så også en tornado:

Fantastisk natur de har og man bliver imponeret over hvor stort det er!

Velkommen til EU

cln — Mon, 20 Jul 2009 14:06:12 +1000

En ting vi finder rimelig morsomt her i USA er faktisk mobilnettet.

Hvorvidt man kan give USA’s mobilnet eller Telmore, som vi begge har, er lidt svært at vide, men en ting er sikkert – for mobiludbyderne er vi åbenbart i EU.

Vi har begge modtaget en SMS fra kundeservice, som pænt byder os velkommen til EU. “Pris/min. inkl. moms…” lyder beskeden, hvilket vi jo synes er en smule morsomt, da vi befinder os i USA.

Det sjoveste sted jeg modtog en, var i Death Valley, som må siges at være et af de ødeste steder i USA, hvilket gør det lidt underligt at vi modtager disse.

Hvis bare prisen var, hvad de skrev i den sms…

2 rejser øst

cln — Sun, 19 Jul 2009 16:01:29 +1000

Idag har været en lang dag, for vi skulle stå tidlig op og se solopgangen i Bryce Canyon. Det var rigtig flot og vi nåede det lige et par minutter før solen kom op over bjerget og vi var endda tidlig på den. Damen i receptionen måtte have brugt den samme tid hele ugen…
Flot var det:

Herefter kørte vi til Moab (Punkt J), hvor vi skulle se nogle flotte buer udformet i sandstenene oppe i bjergene:

Her sidder Julia i den midterste af de 3 buger ovenfor:

Der var dog store problemer med at gå rundt der, da der ingen skygge var og bilen sagde 108F = 42,2C!