When I first started employing automated testing methods in my daily
practices, at first it seemed very hard. I had to create mock objects
for every dao and feed that mock to the webpage or action I used.
Normally the page would have some jsps so I needed to bring up a
servlet runner to run that jsp, also asserting results from the html
pages needed parsing which was another problem. And as my business
logic was scattered everywhere from DAO's to actions and jsps, testing
the simplest scenarios would involve tackling all these problems.
Eventually I learned that if writing tests are hard, this means
there's some flaw in my design. It has been said that "Design for
testing", which means design to test  easier. So I started looking for
smells in my design and improving testing, and things have changed
since then for me. Here are a few tips I can share with you :

- First of all, testing web  & persistence layer is hard enough, So
remove as much business logic as you can from these two and put them
in simple POJOs which dont depend on any other layers. These objects
can be tested using simple unit tests,with no need for mocks, special
contexts, environments etc. I know you already know all this, but its
too important to be left out.

- Embedding UI logic or java code in pages is considered evil, and has
many drawbacks. One is reducing the testability of the logic, because
both creating and asserting results get harder. So if you're using web
frameworks who use these kind  of template engines, try to leave as
little as possible to the pages to render.

- Depending on the framework you use, normally they provide tools to
be able to test your actions/pages/objects... . Those tools will help
alot so use them as much as you can.

- Using Spring to inject your dependencies can help when you need
services in your actions/pages. At test time you replace the services
with simple mocks and get on with the real tests. As a rule of thumb,
any object that looks up its dependency itself will be harder to test.

- A practice I normally use is I divide my UI logic in two parts, one
manages the behavioral aspects of the components I use, and is a
simple POJO independent of the web environment  which can be tested
easily, and another part wires the components together(This part is
dependent on the framework) This way I can write simple unit tests for
the behavior of my components easily. I guess this method can only be
used in component-based web frameworks.

- To test the html output of the pages, Selenium is the ultimate tool.
Its very easy to use and has a great effect on the whole process. But
its drawbacks compared to java based tools like httpunit is httpunit
test can be used in load testing your application, but with selenium I
dont know any good method.

- The tools I use are Selenium,TestNG, along with Springs testing
facilities and my own web frameworks tools. I dont know any other tool
in javaland thats good for testing. Normally I believe testing should
be easy enough not to need tools.

These were my few tips on the subject, maybe you can clarify a bit so
we could zoom on a specific part and discuss that.