I'm attending Denver's JUG tonight, where Scott Davis is talking about Unit Testing the Web Tier.
His opening slide says he's going to cover HttpUnit, Canoo
WebTest and
JMeter. I'm most interested in the JMeter stuff as I've been meaning to integrate
it into AppFuse. I've used HttpUnit and it's a little verbose for me. I prefer
using Canoo WebTest or jWebUnit over HttpUnit. On my current project, we're
considering using jWebUnit or HttpUnit to act as a browser when interacting
with a 3rd-party system.
All of these tools run functional tests - which are much different
from unit tests. Unit tests usually tests the bricks, whereas functional
tests test the building. For unit and functional tests to be truly effective,
they must be:
- Scriptable
- Repeatable
- Automated
- Darn close to 100% coverage
The tools Scott is talking about tonight have passed his basic tests:
- Can I learn it in 10 minutes?
- Does it play nicely with my existing test environment?
- Does it play nicely with my existing production environment?
I didn't take any notes about HttpUnit or Canoo WebTest because I didn't really
learn anything new. Scott did do a nice job in his HttpUnit examples - he
made it look a lot simpler than I've previously seen. I've used it HttpUnit
before and it seems a bit verbose. I've always used jWebUnit, which simplifies
HttpUnit's API.
JMeter allows you to do the same thing as HttpUnit and Canoo WebTest. It's
a standalone GUI, for the complete non-programmer. It does not plug into
Ant/JUnit and is mostly used for load testing. I thought it was exclusively
used for load testing - and I think it has an Ant task. I could be wrong.
<sidenote>Scott uses Smultron for XML editing on his Mac.</sidenote>
The basic building block of JMeter is a "Thread Group". The Thread Group allows
you to control the number of users/threads that run a particular test. You
can test gets, posts, change the protocol and even upload files. For load
testing, make sure and check "Retrieve all Embedded objects in HTML files".
You have to view the "result windows" to view that your tests actually ran
- there's no "green bar" feature.
I think JMeter has improved a lot since I last looked at it. Scott's overview
and demonstration make it look very straight forward and easy to use. One
guy asked if it's possible to see a a global view of all tests run. Scott
thinks it's possible by adding a Listener to the Thread Group and creating
a graph (one of the options). Scott is now showing a lot of the options in
JMeter - there's a ton! It's almost overwhelming.
Next up is "Exceptional" Web Apps by Stephen A.
Stelting, a senior Instructor and Author from Sun. His latest book is "Robust
Java". Stephen has spent the last year and 1/2 figuring out how to make Java
fail.
Objectives:
- Describe the types of errors that occur in the web
- Explain how exceptions and errors can be handled
- Describe the web container response to exceptions
- Present best practices to address web tier exceptions
- Show how web frameworks handle exceptions
Payoff: As a result of this talk, you'll have a better understanding
of how to use exceptions in Servlets and JSPs, improving the robustness of
your webapps.
I'm a little skeptical at this point. I think most folks don't do
exception handling in their webapps. I hope Stephen has some good
tips and tricks for those of us who are familiar with handling exceptions.
I wonder how he feels about Spring and its runtime exceptions?
There are two types of exceptions in the web tier: HTTP Errors and Java Exceptions.
Standard HTTP Errors are handled by the web server. You can also send your
own HTTP errors by calling HttpServletResponse.sendError().
If you're using response.sendError(), make sure and call it before
you commit the output. The web.xml file allows you to specify errors and
exceptions with the <error-page> element.
Servlets and Filters have similar exception behavior. Both declare exceptions
in both of their lifecycle methods: init and service (doFilter for Filters).
Developers throw exceptions in lifecycle methods to "tell" the container
about problems.
javax.servlet.ServletExceptionjavax.servlet.UnavailableExceptionjava.io.IOException
Stephen is now describing the init() method and the exceptions it can
throw. Yawn. I think most Java web developers use frameworks these days. Because
of this, most developers probably don't use these methods because they don't
write plain ol' servlets. One thing I didn't know is that UnavailableException
takes a time parameter - if you throw an UnavailableException with this parameter,
the container will retry after the specified amount of time.
Result of Exceptions in init(): The destroy() method is
never called, since the initialization did not complete. Client calls during
component unavailability render a 500 error.
I stopped taking notes at this point because my laptop battery was dying.
I didn't really learn much in the rest of the presentation. While I can appreciate
Stephen's enthusiasm, it was obvious that he was an instructor and not an
in-the-trenches developer. He explained a lot of what and didn't
have any code to show how to do stuff. There wasn't a single demo
in the entire presentation.
Most
of the exception handling stuff Stephen talked about for the rest of
the session was common sense (IMO). It also centered around the Servlet and
JSP API, which most folks probably don't mess with. The Struts and JSF coverage
at the end was cool. If nothing else, it was to nice to hear a Sun employee
confirm that JSF is quite deficient in its hooks to allow easy framework-configurable
exception handling.
Now that I'm working at home, and working/interacting with friends all day
- it seems that the DJUG meetings aren't as exciting. They used to be fun
because I could get out of the house and have a few beers with friends. Maybe
it was the lack of learning anything new tonight.
. 