ASP.NET OOP and Unit Testing
page 5 of 7
by Brian Mains
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 52646/ 116

Representing Server Controls

Representing ASP.NET server controls in a custom page or user control class can be a double-edge sword for several reasons. By adding properties or fields that represent ASP.NET server controls, this often couples the custom page class to the ASP.NET page it represents. This may not be a bad thing overall, but it will require more work to utilize its full effect. I am currently working on some code to make this implementation approach easier to work with, and that might be the subject of a future article. For now, we will be taking this approach, seen as a variant to the front controller or page controller pattern. Check out the properties below.

Listing 12

public class SignupPage : PageBase
{
  protected abstract TextBox EmailAddressBox { get; }
  protected abstract TextBox NameBox { get; }
  protected abstract RadioButtonList NewsletterSignupList { get; }
}

Instead of properties, examples using page or front controller use protected fields as you did in ASP.NET 1.1.  Because the approach that I use is not using Web Application Project (WAP), to expose controls to the custom page class requires the use of properties. These properties are overridden and return the real components for each property.

Listing 13

<%@ Page CodeFile="signup.aspx.cs" Inherits="Mains.Examples.InboxASPXPage" %>
<table>
      <tr>
            <td>Name:</td>
            <td><asp:TextBox id="txtName" runat="server" /></td>
      </tr>
      <tr>
            <td>Email:</td>
            <td><asp:TextBox id="txtEmail" runat="server" /></td>
      </tr>
      <tr>
            <td>Newsletter Signup?:</td>
            <td>
                  <asp:RadioButtonList id="rblSignup" runat="server">
                        <asp:ListItem>Yes</asp:ListItem>
                        <asp:ListItem>No</asp:ListItem>
                  </asp:RadioButtonList>
            </td>
      </tr>
</table>
public class InboxASPXPage : SignupPage
{
      protected override TextBox EmailAddressBox
      {
            get { return txtEmail; }
      }
      protected override TextBox NameBox
      {
            get { return txtName; }
      }
      protected override RadioButtonList NewsletterSignupList
      {
            get { return rblSignup; }
      }
}

This ASPX page inherits from the custom signup page above, implementing the protected properties and returning the appropriate control. The reason those properties add additional opportunities are because the custom page class can do something like this below:

Listing 14

protected override void OnLoad(EventArgs e)
{
  if (!Page.IsPostBack)
  {
    this.NewsletterSignupList.Items.Add("Yes");
    this.NewsletterSignupList.Items.Add("No");
 
    this.NameBox.Text = this.GetProfileValue < string > ("Name");
  }
}

Because the controls of the page are exposed in this fashion, the custom page class can perform whatever interaction it needs to do. Notice that the page loads the default list of items. This could be something more complex as checking with a back-end reservation system and creating a dynamic page, creating a data-driven web site, or something simpler.

In the previous sample, the ASPX markup defines a list of items; however, removing the code from that markup and adding them to the code-behind OnLoad method adds a good benefit: the list will always have a common set of known, standard values that the custom page definitely knows about.

From this, it is possible to create a unit test like the one below. The test inherits from the abstract page class and implements the server control properties with dummy controls. That is why it is nice to setup some of the server control properties in this custom code-behind page, as shown above.

Listing 15

[TestFixture]Public class SignupPageTest: SignupPage
{
  Private TextBox txtEmail = new TextBox();
  Private TextBox txtName = new TextBox();
  Private RadioButtonList rblSignup = new RadioButtonList();
 
  protected override TextBox EmailAddressBox
  {
    get
    {
      return txtEmail;
    }
  }
  protected override TextBox NameBox
  {
    get
    {
      return txtName;
    }
  }
  protected override RadioButtonList NewsletterSignupList
  {
    get
    {
      return rblSignup;
    }
  }
 
  [TestFixtureSetUp]Public void Initialize()
  {
    this.OnInit(EventArgs.Empty); //Raises init event
    this.OnLoad(EventArgs.Empty); //Raises load event
  }
 
  [Test]Public void TestInitialValues()
  {
    Assert.AreEqual(2, this.NewsletterSignupList.Items.Count);
  }
}

View Entire Article

User Comments

Title: jjjjjk   
Name: gggg
Date: 2012-10-13 3:17:31 PM
Comment:
gggg
Title: RE: Unit Test Bangs   
Name: Brian Mains
Date: 2010-04-18 10:49:40 AM
Comment:
Unit testing for simple applications can surely be done; unit tests only help strengthen an application, but unit tests add time, so for a small project, manual unit testing by the user probably is all that is necessary.

The real question is: is the application going to grow? If it will eventually become a big app, unit testing may be favorable to grow with that application.

But IMHO no you don't need unit testing for a small application, unless you want to to strengthen the application.
Title: Unit Test Bangs   
Name: Chennaite
Date: 2010-04-13 8:00:19 AM
Comment:
Nice Article. but still need to know whether we need unit testing for simple applications?..

Hats off for brain.
Title: Good Article's   
Name: LoveIndonesia
Date: 2009-10-28 5:59:38 AM
Comment:
good articles but sometime i can't understand the mean in article because my english is bad.:D
Title: wow. just what i needed.   
Name: d potter
Date: 2009-07-22 1:06:37 PM
Comment:
this article explained just what i needed to know at just the right level of detail. spot on, man.

protip: if you're stubbing both Request and Response, combine them into an IRequestResponseManager so your stub can share the same HttpCookieCollection across simulated redirects/etc.
Title: Timely info   
Name: Scheffler
Date: 2008-08-26 6:45:50 PM
Comment:
Nice article Brian. I had a similar need today and this fit the bill quite nicely. I used a pared down version of the ISessionStateManager interface you defined above because I was only barely interacting with the Session state collection. However, this has allowed me to nicely stub out and test locally my persistence logic for some prototyping work before fully fleshing out my NHibernate logic.

Thanks for taking the time to write and share your idea.
Title: Good   
Name: venkat
Date: 2008-01-25 2:43:08 AM
Comment:
its Good...! better to provide code for this.
Title: good   
Name: max
Date: 2007-10-09 3:07:04 AM
Comment:
this article is very..good...keep it up






Community Advice: ASP | SQL | XML | Regular Expressions | Windows


©Copyright 1998-2019 ASPAlliance.com  |  Page Processed at 2019-07-22 4:38:44 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search