Adam Hardy wrote:
What are the additional testing requirements? The returned result is a
string, the parameters used in the result config are strings--what's
left?
The unit test must additionally set up struts to be aware of the config.
Not if you're testing the action itself: check to see if the result
string is what you expect and the exposed config strings are also what
you expect.
If you're testing the configuration mechanism of Struts 2 itself,
sure... but that cross the boundary of what I want to test in the app
test code: if my action runs and I get the expected action properties
when it's done I'm satisfied my action has run correctly.
At best I'd do client-focused integration testing (for example, by
driving a browser) to make sure the front-end contains what I expect it
to, incidentally testing Struts 2 in the process--but my goal isn't to
re-test Struts 2.
It's possible I'm still not understanding what you're saying.
Regarding JSTL vs OGNL, again, the simplicity of JSTL is fine. When you
need something complex, write a taglib function for it - generally it's
easier to read in the JSP and the taglib code is testable.
We'll have to agree to disagree--I hate being hamstrung in the view.
Just my PoV - coming from a generalist in coding right across the GUI /
MVC / Java / DB stack, rather than as a front-end specialist.
I'm an ex-AI and embedded systems/device driver developer--I've been
nearly as far from the front-end as is possible to get. But when I'm
forced to deal with it I don't appreciate not having the same
expressiveness as the powerful languages I'm used to.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
