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.
df11cca3-88ad-435a-9f1f-450298d08964|0|.0