My process on web projects has tended to be very similar to the paradigm described in Lasse Koskela's
Test Driven book -- ie what he's termed an "Acceptance TDD" cycle wrapping the regular TDD cycle.
If you're not familiar with TDD at all, I wouldn't recommend this approach initially, as you'll have to tackle a lot of "hard/annoying" configuration issues up front.
But to give an example of how I start a project:
I'll start with an acceptance test like
(Note: there is a fair bit of "magic" hidden in the base class, setting up JWebUnit and DbUnit, etc)
With this failing acceptance test, I'll then dive into the unit tests needed to work towards a working implementation. I'm working in Struts 2, so there's no magic needed to test Actions, so often I'll start there, but sometimes I'll go to either the service or domain layers...
This first acceptance test actually covers a lot of ground (which is why it can be a very hard first hurdle)
a) I can build my source, start a container, deploy my app, in an automated manner. (When first starting out, I don't mind using the start/stop/redeploy options in my
IDE, but IMO it needs to be automated before starting on the second acceptance test)
b) I have the web-framework hooked up with a mapping for the index page of the site configured
c) I have the database hooked up (since the list of items is being pulled from that and the ability to inject test data into it
Typically my next acceptance test would cover that a request for "/" gets redirected to the same welcome page. With the third acceptance test driving my security infrastructure -- asserting that a request for a protected resources gets redirected to a log-in page. Which of course leads into a suite of acceptance tests covering login/logout/account creation/password resets/etc... Once that's accomplished moving onto the real business of the web application takes over, but I'll know I have my infrastructure in place and its surrounded by the two sets of tests.