ASP.NET MVC vs. Jquery/AJAX (Where to draw the dividing line?)

Question

I am learning MVC and I understand the basics now. It is very good for CRUD pages and has built in HTTP methods to post/get edits/updates. That is nice. This is all very testable by just creating a new controller and testing it.

But I was thinking about other web page scenerios when using MVC. What about a page that has 2 listboxes that you add/remove users with. (A button will move the user from one listbox to another)

This would be done using Jquery/Javascript... But then what happens to testing? How do you test adding/removing users from a listbox like that example?

It seems to me the more jquery you use the less testable the page becomes right? When you get beyond basic forms being filled out then you need to use something more than the standard MVC pages.

What is the correct philosophy on this on when am I not understanding ?

Answer 1

1. adding/removing users can't be done with jQuery alone, unless your users database is local to the client browser. at some point you will have to invoke a controller action in the MVC application to persist the choice. that action is unit testable.
2. there are fameworks and techniques for unit testing JavaScript that you can use to unit test your jQery code.

The right way to think about this scenario is to separate your application into two - one server MVC app and a client side jQuery app. The fact that the client-side code is generated and delivered by the server side app actions and views is irrelevant.

Once you start separating these two, you can start thinking about how to unit test each of them properly.

Answer 2

Progressive enhancement: http://www.alistapart.com/articles/understandingprogressiveenhancement/

Make everything works without jQuery/Ajax, using regular HTML. Plain old links and submits.

Then, let jQ be a very thin layer on top. For me, I just have jQ submit forms via Ajax instead of the regular submit. Same form, same controller, it just happens without the full page refresh.

Doing it this way means that jQ's only real responsibility is UI refinement. If it fails, it falls back to regular HTML.

So front-end testing becomes a bit less important -- you are assured of correct functionality, you're just testing for UI niceties.