TDD with ASP.NET - is it really practical?

[Frits Ramon]

So I'm starting a new ASP.NET project and want to proceed with a test-driven
approach as much as possible. I have decided that I will ceratainly NOT use
the ASP.NET MVC framework, and instead go with the traditional web forms
approach.

The first issue I ran into is that, in order to create my unit tests, I'd
need mocks for Application, Session, Context etc. Thinking that through,
these mocks would have to do practically *everything* offered by the
Application, Session etc objects. Suddenly I'm *duplicating* much of what
ASP.NET is - all for the sake of unit testing my code. That seems like a
ridiculous amount of work to get automated unit tests.

Am I missing something? Or is it simply not possible to use TDD for ASP.NET
Web forms application development?

Do any of you use TDD with traditional Web Forms-based ASP.NET Web
applications? If so, how do you get around having your unit tests depend on
Application, Session, etc? Or do you take less of a TDD purist approach and
let your unit tests have those external dependencies?

Thanks.

 

[bruce barker]

I use TDD with asp.net, not not so much with the actual aspx page.

1) the first rule is to have no business logic in the page, (thats why the
MVC pattern works better and is well worth switching to). define adapters or
messages to move data between form fields and business objects. i always
subclass all asp.net controls I use, and supply a binding interface. then
only one mock control is required for testing the adapters.

2) create a seperate project for all business logic, and yet another project
for unit tests.

3) it easy to write a mock session manager, but if you store just a few
objects in session, its much easier. also in general you are testing the
business objects, adapters, and methods, so no session is required for the
unit test.



-- bruce (sqlwork.com)

 

[sloan]

As previously illuded to:

You want a STRONG business layer, and the more "presentation" the aspx page
is, the better.

And then you can work on the app/session stuff on a much smaller scale.

As I keep preaching at work "Push it down to the business layer, push it
down to the business layer".

...

 

[Cowboy \(Gregory A. Beamer\)]

So I'm starting a new ASP.NET project and want to proceed with a
test-driven approach as much as possible. I have decided that I will
ceratainly NOT use the ASP.NET MVC framework, and instead go with the
traditional web forms approach.

Much easier today, as the tools are not there.

The first issue I ran into is that, in order to create my unit tests, I'd
need mocks for Application, Session, Context etc. Thinking that through,
these mocks would have to do practically *everything* offered by the
Application, Session etc objects. Suddenly I'm *duplicating* much of what
ASP.NET is - all for the sake of unit testing my code. That seems like a
ridiculous amount of work to get automated unit tests.

You don't need mocks for the ASP.NET items, as they are UI items. Your
application is not a UI. Testing UI is more a function of QA and acceptance
testing than unit/programmer testing, where you are testing algorithms,
business logic and data logic.

Am I missing something? Or is it simply not possible to use TDD for
ASP.NET Web forms application development?

Think of your application as the algorithms necessary for business logic,
primarily, and you will find you can easily test without mocking up the UI.

Do any of you use TDD with traditional Web Forms-based ASP.NET Web
applications?

Yes, all the time. It is the reason I treat MVC, although a great idea, with
some disdain. MVC is there to force developers to do the right thing. If you
have "dumb" views you have to code your application in classes (controllers,
libraries) rather than code behind and you are forced to have a clean
separation of data logic (models).

If so, how do you get around having your unit tests depend on Application,
Session, etc?

You code your ASP.NET to be a UI, not the application. It is called
separation of concerns and is a concept so few developers truly understand.

It is rather simple to encapsulate the logic into business libraries. You
then set a facade between the UI and the application. You can unit test all
but the UI with standard unit tests.

A benefit to this approach is I can switch the application from web, to WPF,
to Silverlight, to Windows forms, to Console, to Web Service (WCF or ASMX),
to Windows Service with a small change of "UI" (realizing the services do
not really have a UI).

Another approach is bite the bullet and code using the Go Live license with
the new MVC Framework. There are no tools to really help you, so it is a
harder path ... right now.

Or do you take less of a TDD purist approach and let your unit tests have
those external dependencies?

The only area I might use a less purist approach is on testing the UI. There
is a project called nUnit ASP that allows this. It is no longer an active
project, however, so it will become stagnant eventually.

Then again, if you have unit tests on the rest, you can acceptance test the
UI, or use a formal QA approach. Very few bugs will be UI driven anyway.

 

[Cowboy \(Gregory A. Beamer\)]

I use TDD with asp.net, not not so much with the actual aspx page.

1) the first rule is to have no business logic in the page, (thats why the
MVC pattern works better and is well worth switching to).

IMO, the only real benefit of MVC here is that it forces the separation of
concern, which so many developers are bad at doing. ;-)

NOTE that this is not a knock on MVC, but rather that its primary selling
point is that it forces those with bad development practices to do it right.
If the application was viewed as a set of classes up front, everyone's
ASP.NET "application" would be little more than a UI "skin".