What this book is having, which other Struts 2 books don't have, i mean what is the best part of book?
Does the book cover Unittesting? If so mock testing or in container testing? My company has been hesitant to move from Struts 1.x because we are heavily invested in MockStrutsTestCase and that has yet to support (at least from what I've read) Struts 2.x
Does the book cover Unit testing? If so mock testing or in container testing? My company has been hesitant to move from Struts 1.x because we are heavily invested in MockStrutsTestCase and that has yet to support (at least from what I've read) Struts 2.x
There is a fairly comprehensive testing chapter covering unit and functional testing.
The need for a plethora of mock objects is *hugely* reduced in Struts 2 because it's so decoupled from the Servlet spec. More often than not the bulk of an application's logic can be developed with very few, if any, mocks needed. (Obviously this is very application-dependent.)
If you can provide a quick idea of what kinds of testing needs you have I can elaborate further.
Joined: Oct 27, 2008
Our overall goal is to run our Unit tests in our ANT Builds without depending on the code being in the container or having a DB connection.
We have a variety of JavaBean POJOs representing Users, Organizations, Settings, Search Results, etc... and they all have many states they can be in. In the Code these POJOs come from our DB Layer, get passed around between Actions in the request, are sometimes stored in the Session, and are consumed by the JSPs.
We created a bunch of Mock POJOs to represent the various states and stick them in the Session, Request, etc using MockStrutsTestCase. After calling action perform we verify the forward or expected validation errors are caught and that the Mock POJOs in the response are present and in the right state.
Hopefully this gives you some talking points for testing elaboration or a reason to say we did Struts 1.x all wrong and we should just throw it away and start a fresh with struts 2.x.
I don't quite get the concept of "mock POJOs"; seems like it shouldn't need to be mocked if it's a POJO, but I could just be mis-understanding your environment, or we're operating with different definitions of "mock".
With Struts 2 the "mock" POJOs can be put into a plain ol' Java Map and injected into an action. If the actions depend on nothing else they can then be executed and the String return value can then be checked against whatever business logic required. Test code, then, can create the appropriate map, set it on the action being tested, execute the action method, and query the action for appropriate results.
Since there's a near-complete separation of S2 from the Servlet spec (i.e. the request, session, and application scopes are plain ol' Maps, form data can be set on action properties, etc.) it's totally straight-forward to instantiate an action, set the appropriate data, set mock services (and thus their return values), and so on, most everything can be tested outside of a container, DB, etc. The request and session *can* be mocked if absolutely necessary (boo hiss!) but it's relatively rare they need to be.
With a concrete example I'd be happy to provide more information regarding a canonical way Struts 2 might handle it (and its tests), or at least *one* of the canonical ways