Web forms are inherently hard to test mainly because of tight coupling of components created at runtime. We will explore a way of getting around this problem and enabling isolated tests and test-driven-development on legacy web form projects.

1. Web Forms and
automated tests
Michali Konstantinidis
All content by the author unless mentioned otherwise

2. The problems
●No control over Page, Web and User Control
creation
●Not isolating view from code-behind
○Access web form elements directly in code
●Dependency on ambient statics (Request,
Response, Session, ViewState…)
●Automated tests next to impossible

3. Some automated tests are still
feasible
●Test end-to-end, from UI to database.
●No quick feedback, expensive to write
●Create/Update/Delete tests: Time-
consuming database setup/teardowns
●Preconditions: Possible a large chain of test
data with relationships

4. I’m not saying not to have end-to-
end tests
A test harness just needs
to look a bit like this...
Manual tests
UI/Acceptance tests
Integration tests
Unit tests

5. Model-View-Presenter
●Derivative of the MVC
●The “view” (Web Forms Page) marshalls
user requests, not the presenter
●Usually a 1-to-1 relationship exists between
a view and a presenter

6. Web Forms with MVP

7. Key Points
●Presenter contains UI logic, and delegates to
business layer
●View marshalls requests and makes Web
Forms components available to the
Presenter
●The Presenter does not operate on concrete
implementations, only on interfaces!

8. Test Isolation
●Framework components accessible by
statics can be wrapped or accessed via
abstract classes, if available, and mocked
○Session - HttpSessionStateBase
○HttpContext - HttpContextWrapper
○Or make those available via a Page subclass
●Leave View with barely existing logic,
making it not worth testing

9. And, that’s (almost) it
●Circular reference between View and
Presenter. “Newing-up” of objects should be
done in one place, in a factory.
●Dependency Injection in Web Forms?
○Unity.WebForms - by S. Kyle Korndoerfer