Testing ASP.NET webforms applications

Question

If you're in my position you have a big WebForms applications which have escalated to this unmaintainable thing. Things break when you add new features and you need an inexpensive maintainable way to do some kind of automated testing.

Now, from my understanding, the right thing to do would be to try building an abstraction layout of the page and user control model present in ASP.NET WebForms however, seeing as it would require a major investment in an existing application it is not an option.

I'm trying and pushing for a REST-like development as much as possible because it has some nice properties. And while doing this I've written a simple spider bot that crawls all URLs it can find and tries, simply getting them. This allowed my to quickly find bad data that was causing problems and avoid having my end-users clicking on broken things, however, this is of course not enough.

I continued work on my crawler and it's developed into a simple REST client that tries different input combination, looking for a probable bug or crash. It's more intelligent that just an exhaustive search (because it knows about the ASP.NET WebForms application layer) and my goal here is to basically explore the state of the web application, hoping to hit all the corner cases before our users.

Does anyone have any experience doing something similar?

Also, for you test gurus out there. Is this a complete waste of time, or will I be able to actually say something about the quality here? From my perspective it seems to hit a sweet spot in that it will try things a potential end user would though a browser.

As I said before, we're stuck in a bad place. And we need a simple way out of it, right now.

We've tried things like Selenium, but it mandates a lot of extra work and we change things all the time, it's just no possible to maintain multiple selenium test suits for 50 different applications.

Answer 1

What part of your application is breaking? The UI, or the business logic?

Business logic should be completely separated from the user interface, and should be tested separately. In particular, it's much easier to use automated unit testing tools against separated business logic than it is against UI.

Answer 2

Of all the types of testing to implement, unit testing is both the easiest and the most likely to yield results, in terms of less bugs and more maintainable code. Get that worked out before you deal with automated integration testing

1. Pick an IOC Container - I like Ninject for this personally
2. Find a convenient place to inject "service" classes into your Page (the consturctor of a base Page class or override the module that loads pages, whatever works for you)
3. Pick a unit test framework and if you don't have an automated build then set one up; include running a full suite of unit tests in that build
4. Every time you go near a piece of logic in an aspx.cs file, see if you can't isolate it in a service and wrap unit tests around it
5. Take a look at whether the MVP Pattern would be good for you - we found it decreased productivity as much as it increased testability (it did both a lot), but it works for some people
6. See about slowly migrating your app over to MVC, a page at a time if necessary

And remember, you are not going to fix this problem overnight, you don't have time. Just keep improving test coverage and you'll see the benefits over time.

Answer 3

If i am rigth you have a large web form and want to run some standard end user tests each time you do a new release.

I can recomend the Selenium IDE adon for firefox.

it will allow you to record your user actions, e.g filling in a form, and allow you to replay those actions at any time. an easy way to run some test over a form with differnt data.

For internal code testing write some Unit tests using NUnit