Hmm, the link doesn’t work for me.

When I first saw MVC there were two negatives. One was the ugly classic ASP if statements. The Second was no controls which I thought ment no generic Grids.

With new technology comes new ways of thinking. What ever control you lost look to JQuery plugins to replace it. DataTable, jqGrid plugins are replacements for the grid control. jVal and Validate are plugins that replace the Microsoft validation.

As far as old classic ASP look I have found ways to maintain a clean look. DropDowns require a for-each loop to spell out all the options. This can add alot of code to page. So refactor and put dropdown code into a partical. Then on the main page do a RenderPartical.

I know what you mean (we do not employ people who show a tendency towards auto-generated HTML), but repeaters and placeholders are the only ASP.NET controls I use as they are the only ones that don’t "magically generate markup". Repeaters give you complete control over what HTML is output (Datagrids and Datalists are horrible though).

To test the UI we have been using ACT to record and execute scripts for years and unit tests for things CRUD logic that was incorporated into the page. Is it perfect? Definitely not. The UI scripts are not as sensitive as scripted testing in the desktop days with VT but you still get days of "fail 500".

I asked my question because TDD is almost always held up as the #1 gain in coding for asp.net MVC and I wanted to know what is gained because I sensed there is a gap between what I perceived to be web testing and what everyone was so excited about.

thanks for the explanation. I can definitely see benefits of being able to test more in the base tool (vs 2008) compared to what we have done at the shop I work for in winforms and webforms.

With ASP.NET MVC, you gain the ability to test your controller actions, which are analogous to the server side events in ASP.NET web forms. For example, a unit tests that you can do easily on ASP.NET MVC but not in ASP.NET web forms is testing whether or not a user is redirected to the correct page when they click on a link. This will let you test, among other things, if your security settings and permissions are working as expected.

You can also test out behavior this way (i.e. when this action is performed, are the following functions called and is the response to the user what you expect).

You aren’t necessarily testing the html response so much as the system’s response to requests to the controller.

Are you testing the html response based on a simulated request to the controller? This sounds more like the ability to write acceptance level tests than unit tests. Please be gentle and fill in the gap in my understanding of MVC.

WebForms was designed so that you could develop web applications and not understand how web programming works. It did a decent job in some areas, and a terrible one in others. As long as you actually do understand how the web works, and learn the rediculesly complex way that webforms works, you can usually work around the profoundly bad ideas yourself (ViewState, ASP.NET AJAX, the raping of element IDs, Extenders). The problem with WebForms is while they will take you 80% of the way extraordinarily fast, that last 20% will take about ten times as long as it should.

The MVC model is the direction everyone else outside of microsoft moved to years ago. It fits the web a lot better, reduces the complexity and overhead of ASP.net, and using it will not get you painted into a corner of pain the same way that webforms almost inevitably does. The one and only downside over webformss is you can’t do anything without actually understanding and learning the technologies that power the web.