Unit Testing the Web GUI

Question

I recently heard a discussion in which TDD was the hot buzz word. Now according to one speaker, in order to test your behaviors you need to use MVC but on the other side its been said that TDD is an approach which can be adopted in any environment (as the discussion surrounding ASP.NET MVC or Web Forms). Another speaker claimed that if you put your behaviors in library or models then you can just test your repository or services in TDD and hence don't need to worry about testing HTML. How much TDD should cover in case of Web GUI testing or is it worth the effort?

I know sometimes we use the "next best thing" and carry it to the extreme, but it doesn't really benefit real development scenarios. So can TDD be applied to the UI?

EDIT:

I agree with you guys and that's also how I feel: if you really do TDD then you don't need to test your WEB UI front end, since the data that you're providing to it should be under your business/services/repositories layers which can be tested without a UI. So if you program your Web Forms application in such a way that your operations/behaviors are tied in with server side calls (like button click events although in my case they can be tested by calling lower level operations) you can have TDD in Web Forms. Thanks for your answers

Answer 1

I agree with Josh here. Just getting going on SO, though, so I can't vote it up.

It should be noted firstly that testing your GUI is not unit testing. With clean separation of concerns, as Josh advocated, the GUI contains no business logic.

The logic that requires testing is encapsulated in one or more discrete libraries (or possibly in simple MVC controllers).

TDD refers only to logical code units, and one hallmark of solid TDD practice is that all of your logic code can be written and tested without any UI at all. In fact, tests are often written before the classes they will test. Once code is complete and all tests pass, the UI can be added to utilize the API hooks you've built, and that UI can be webforms, MVC, WPF, winforms, etc.

Testing on the UI that you'll do with a product like Selenium has more to do with acceptance testing or possibly integration testing.

Answer 2

I will be bold enough to say that if you need to unit test your GUI in order to get business logic, or integration testing done, then your design is lacking a clean separation of concerns. Both MVC and MVP are patterns that offer a clean separation of concerns so your UI can focus solely on presentation logic.

You do have both options in ASP.Net using either ASP.Net MVC, or WCSF (an MVP implentation using web forms).

That being said, you should still do GUI testing, but you have no need to do all this manually. Selenium Server, and Selenium Remote Control offer ways to do automated testing through the UI.