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

Custom ASP.NET Classes

Each ASP.NET page inherits from System.Web.UI.Page; however, a custom page class can inherit from this System.Web.UI.Page, and all ASP.NET pages can inherit from this custom page. This custom page class is a great feature because it can provide generic or specialized properties/methods that are useful to an application or a specific page. User controls work the same way; a custom UserControl class can be used, which can expose properties/methods to all of the user controls in a web application. Throughout this article the custom page class and custom user control class that serves as an intermediary will be referred to as "the custom page class" or "the user control class."

Unit testing has several complications when testing against an ASP.NET page. First, this approach usually involves the unit test inheriting from the ASP.NET page. In addition, ASP.NET utilizes a different set of runtime objects (Handlers/Modules) that are available in the web environment and not in the unit testing environment. For instance, the session object makes use of a module that is not available normally in the test environment. Creating a custom session factory for testing purposes only can be overly complicated and not worth the effort it takes to develop one for unit testing purposes. In addition, the request/response collection is also specialized to the web environment, and not available in the unit testing environment. Caching is not the same, because one can make use of the Enterprise Library Caching block, which works in the windows realm as well.

The ASP.NET default model can also provide additional complications. Within a custom page or user control class, ASP.NET controls can be exposed, but simple and complex properties, templates, and other server-control settings may not be directly accessible in code-behind. In addition, what happens when a custom user control base class is reused between multiple user controls? The markup code has to be duplicated. For instance, take the markup below.

Listing 1

<asp:GridView id="gvwProducts" runat="server" AutoGenerateColumns="false"
      DataSourceID="sdsProducts">
      <Columns>
            <asp:BoundField HeaderText="ID#" DataField="ProductID" />
            <asp:BoundField HeaderText="Name" DataField="ProductName" />
            <asp:BoundField HeaderText="Cost" DataField="Cost" />
      </Columns>
</asp:GridView>

The GridView control has three columns, all in the markup.  However, if the page or user control is considered reusable, a better implementation is to move the setup of the GridView to the page or user control class, and create them at runtime.

There are good reasons to do this: creating them in the custom page or user control class increases reusability, increases how much the page/user control class knows about the server controls, and increases how much can be manipulated. The drawbacks are, as I stated before, extra coding effort.


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-11-14 6:32:52 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search