eWorld.UI - Matt Hawley

Ramblings of Matt

NUnitASP and Portals

April 14, 2004 18:27 by matthaw

As a followup to my blog post yesterday, my boss decided to throw a new one at me - give an example of how we can use NUnitASP for our projects as another form of TDD during the project life cycle. Well, I hadn't used NUnitASP before, so I jumped right in following their step-by-step tutorial for newbies. Sure, the tutorial wasn't a real-world example, it did give you an idea of how things work and what needs to be done.

So, after my success with that, I decided it was time to take one of our applications for a test ride. Well, this application so happened to be built on a custom portal framework we developed, and things started to go wrong for me from the very beginning. I first tried to get to the first main page, the login page, and grab the username & password text boxes in a test.

Problem 1: NUnitASP took me to the default page, which sets a cookie and redirects the user to their homepage. Well, NUnitASP didn't do the redirect, so I was stuck with a page that had no controls. Solution was to grab the URL manually (which have a few different query string parameters that vary depending on your user/role/application using/page viewing).

Problem 2: NUnitASP needs to grab the controls via HTML ID. Ahh, so I just plopped in "tbUsername" and "tbPassword" - what? It can't find them? Solution was to fully qualify them as "_ctl5_tbUsername" and "_ctl5_tbPassword". This doesn't really make writing tests easy for data driven portals that vary on the modules that are displayed...I mean, how am I supposed to know the unique prefix that is added.

So, from my two problems I just listed, I've come to the conclusion that NUnitASP cannot (as of this blog posting) be used in Portal based webpages. My reasons are as follows:

  • You need to know the exact URL to a page to test, initially at least. If you're page's are dynamically put together with different modules based on you're user, role, and query string parameters, this could vary from time to time, thus breaking your tests which require modifying your tests...not a good practice.
  • You need to know the exact HTML ID of the element you're trying to write tests against. This is a good design if you're pages are darn near static (in the sense that the way they're loaded is not data driven), and are not contained in User Controls (this may work, but the same logic applies) because you know what the HTML ID should be when writing a test. However, if you're using a portal, you will most commonly not know the unique name of the control, which could in turn change from time to time, again (revisit my last statement above, it applies here too).

Although I say NUnitASP is not a good framework for portal based solutions, I do see it as being a very viable framework for pages that are not dynamically created. Maybe this is something that will possibly change in the future, however I'm not sure if or how it would. What are your thoughts on TDD of portal based application UIs?

Update: I missed the "UserControl" tester object that can be used for accessing User Controls and controls within those. However, this will still not work for dynamically created UC's that are added that don't have a distinct ID that is set, IE - portals.

Categories: .NET
Actions: E-mail | Permalink | Comments (15) | Comment RSSRSS comment feed


April 14. 2004 18:57

In regards to the second bullet point - you don't need to have the exact HTML id.  You need to setup a user control container and then place your textbox controls in there. That way NUnitAsp can figure out the HTML id for you.


April 14. 2004 19:09

Is there any documentation that you can point me to for this? Is that limited for only UserControls that you know the ID of, and does it work with dynamically loaded UC's?

Matt Hawley

April 14. 2004 22:32

I didn't even know this existed (shows how much I pay attention). I'm a Web jockey at heart, but in my current gig it's all back-end stuff and we couldn't get along without NUnit. This sonuds good conceptually, but if you figure out how to overcome the limitations you mention, I'd be glad to hear how.


April 14. 2004 23:30


There is just the tiniest bit of documentation.  The UserControlTester is here:


Then you need to combine that with the fact that the TextBoxTester constructor (nunitasp.sourceforge.net/.../...erConstructor.html">nunitasp.sourceforge.net/.../...erConstructor.html) requires a container class, and I just tried passing one into it instead of "CurrentWebForm".

It will work for dynamically created user controls as long as you know what their dynamic name is going to be (it's not a random number or anything).

I was thinking of writing something about it on my blog, but wasn't sure how many people were interested in the topic.


April 14. 2004 23:36

The problem with my situation is that we dont set the ID of the dynamically generated UC's, so they do get _ctl1 and _ctl2, etc. I'm thinking that this can change for my situation, though, so we have an actual name to use.

Matt Hawley

April 15. 2004 17:32

I'm beginnging to explore NUnit and NUnitAsp for our development as well and would love to see a good set of tips for using NUnitAsp.  The biggests issues I'm having right now is simply that the support for a few of our frequently used controls is not supported (ie: Repeater, CheckBoxList, and RadioButtonList).  I'm trying to get familiar with the source, actually working to add a RadioButtonListTester to the project but until I have time to really look into the guts of how everything works it's tough.


April 19. 2004 15:44

As a point of interest you can obtain the clientside ID programmatically via the ClientID property either from the codebehind(MyUserControl.ClientID) or within the ASPx with <%=MyUserControl.ClientID%>

for dynamic controls you can iterate across the page with:

foreach (System.Web.UI.Control currentControl in this.Controls)


    TheUserControl currentUserControl = currentControl as TheUserControl;

    if (currentUserControl != null)


        // do somthing with currentUserControl.ClientID




April 20. 2004 16:21

Nice to see posts on NUnitAsp.  We use it all the time but on a regular web app not a portal.  We have had similar problems testing custom controls - what we decided was to have a separate test web project that hosts each control in its own page where it can be tested in a known state.  This doesn't test the interaction of that control with other controls - but after all, it is unit testing.

Another approach we use when we can't figure out a better way is to just use IndexOf(expectedString) tests on the resulting HTML (Browser.CurrentPageText) - ugly but it keeps the TDD cycle going ...

Jonathan Cogley

April 20. 2004 21:57

Hi, Matt.  I'm the maintainer of NUnitAsp.  NUnitAsp was developed for a portal project, so I know that it can be used in that environment.  The trick is to remember that it's meant to be used for test-driven development and for unit tests.  If you try to test pre-existing code at integration-test level, as you are, you're bound to be disappointed (as you were).

Jonathan Cogley has the answer: focus on testing individual units and put them in test web pages so that you can get at them easily.  That's what we did on our portal project and it worked well.

I'd like NUnitAsp to work more smoothly.  I'm not currently developing in ASP.NET, so I'm relying on the (very sporadic) contributions of the community to keep it up to date.  In this situation, NUnitAsp is only as good as the people who use it.

Jim Shore

April 20. 2004 22:00


Thanks for the answer and explanation. It does seem like it would work in that instance, however my division has chosen to not proceed with UI level TDD, so its not really an issue anymore.

Matt Hawley

April 24. 2004 02:57

If I have a html table that doesn't have an ID, how can I initiate click on the cell data ?


June 8. 2004 11:40


    I am facing a problem when i try to test an HTML Control. Is NUnitASP limited to Web Controls alone?

Thanks In Advance,

Jefferey Rayan


July 2. 2004 16:44

First I tried to test our MSCMS Application with NUnitAsp, I was also disappionted. But a second look helped me to understand how it works and now I'm using it more and more. Yes, I had to modify the pages and some controls but in future I will design my pages to work well with NUnitAsp. The benefit of testing tens or hundreds of use cases on one button click before delivering a release or patch is very big. It is really embarrassing to deliver a software and the customer notices that some older components don't work anymore. There is a lot to improve in NUnitAsp but we can contribute...


July 13. 2004 15:19

how exactly can i use aspid or htmlid of controls for their validation or reference.. please help


July 23. 2004 02:54

Can anyone tell me how to:

1.  get access to rendered HTML. Someone mentioned using Browser.CurrentPageText, but can you go into more detail or provide some sort of reference material.

2.  how to address controls NUnitAsp does not support, other than just creating custom controls to handle them.

3.  how to address actual objects instead of proxy objects (or have complete implementation of properties and methods of actual objects)

4.  is there away to execute client side script using NUnitAsp

5.  how to drive AspRunTime externally or get a handle on the actual webpage, and thus all elements on that page



Comments are closed

Copyright © 2000 - 2014 , Excentrics World