Any (non framework specific) good articles on TDD with J2EE?

[Chris Corbyn]

I've come from a PHP background where I used to develop with TDD religiously but moved to Java a couple of months ago. I feel like I've gotten to grips with the language enough to at least get back into Unit Testing. I've tried searching around for some inspriation on how to approach test driven development within a servlet environment but all I keep coming across is spring and hibernate articles....

Does anyone have any good links to articles which provide some insight into using JUnit on a J2EE server without being tightly bound to a particular framework (in my case I'm writing my own framework as part of my self-teaching).

[Frank Carver]

Have you tried our own JavaRanch Journal ?

I wrote a series of articles a few years ago on this very topic - look for "Small and Simple Web Applications - the Friki Way", there are six parts.

[Chris Corbyn]

Reading it now thanks. I read the first one which was aptly agile though no mention of tests just yet having only just written a little interface. I'll keep going I'm aware that some of the content is out of date, being over 4 years old now

PS: I really like browsing/reading the Journal but it looks like things are on a slow down lately... unless I'm missing where the 2007 articles are?

[Stan James]

Spring's inventor wrote about the power of POJOs - Plain Old Java Objects - before he did Spring. Spring dependency injection is just one way to isolate your POJOs from J2EE. You can do it on your own.

One idea is to reduce the classes that know about HTTP, Session, Request, Response, EJB, etc. to minimal gateways. They do as little as possible before handing off responsibility to classes with no J2EE imports. For example, a servlet might copy all the request parameters into a HashMap and call a POJO. (You asked about doing this "without a framework" but you're really building a smallish framework at this point.)

Now you don't have a J2EE question any more. You can TDD all your POJOs without thinking about servlet or EJB containers.

Is that the kind of thing you're looking for?

[Peer Reynders]

JavaWorld: Testing J2EE applications (2004-Aug)
J.B. Rainsberger (Diaspar): Test-Driven J2EE
[ September 10, 2007: Message edited by: Peer Reynders ]

[Chris Corbyn]

Originally posted by Stan James:
Spring's inventor wrote about the power of POJOs - Plain Old Java Objects - before he did Spring. Spring dependency injection is just one way to isolate your POJOs from J2EE. You can do it on your own.

One idea is to reduce the classes that know about HTTP, Session, Request, Response, EJB, etc. to minimal gateways. They do as little as possible before handing off responsibility to classes with no J2EE imports. For example, a servlet might copy all the request parameters into a HashMap and call a POJO. (You asked about doing this "without a framework" but you're really building a smallish framework at this point.)

Now you don't have a J2EE question any more. You can TDD all your POJOs without thinking about servlet or EJB containers.

Is that the kind of thing you're looking for?

This is one approach I considered taking, but J2EE is J2EE. It offers a lot and (IMHO), hiding it from the commands/actions would be a waste. I've taken a K.I.S.S approach with my non TDD version and simply give ServletContext, ServletRequest and ServletResponse to the individual actions controllers before heading off to a View (JSP) -- if requested.

   [Request in]
        |
        v
Request Mapper (FilterChain)
        |
        v
FrontController (HttpServlet)
         |
         V
ActionController.init(ServletContext, ServletRequest, ServletResponse)
         |
         v
ActionController.validate()  --- [no] --> ActionController.handleError()
         |
       [yes]
         |
         v
ActionController.execute()
         |
         v
Main JSP (layout) <--- include --- Page template
         |
         v
   [Response out]

I'm not planning on Unit Testing what I've already written because I don't find that particularly useful. I know it works. I find unit testing more useful as a driving force in development so I'll be going back to scratch.

It would be a shame to have to hide the fact the environment is J2EE by writing my own objects for things that J2EE already provides. Really it wouldn't be too much effort to create mock objects from the APIs in the spec and test with those but I didn't really know if that was a done thing. It's fortunate J2EE has such a complete spec which you can rely on.

Peer, thanks for the links I'll have a read Frank, I still didn't get through your second article because my boss spat his dummy out when he caught me reading it while I was supposed to be working on a PHP project Meh, I don't care, I leave for Oz in 2 weeks

Thanks again guys.

[Chris Corbyn]

Originally posted by Peer Reynders:
JavaWorld: Testing J2EE applications (2004-Aug)
J.B. Rainsberger (Diaspar): Test-Driven J2EE

[ September 10, 2007: Message edited by: Peer Reynders ]

I've only got to the 4th page in that article on JavaWorld and already I feel like they're testing too much. I personally don't want to simulate a web browser and/or a user clicking a link on a page right now. I'd rather create a mock of HttpServletRequest, set the request uri and some parameters and pass that mock to my servlet while I test how it behaves. I may find a need for that depth of testing later once I start testing pages built inside my framework, but not now

I'll finish Frank's article then I'll grab JUnit and wrap my head around how people create Mocks in Java and I'll get started

[Gabriel Claramunt]

Can you use JSF? If you insist, IS part of J2EE and you only need POJOs, very easy to test. If you experienced the pain of working with plain JSPs and servlets, JSF is a blessing

[Chris Corbyn]

Originally posted by Gabriel Claramunt:
Can you use JSF? If you insist, IS part of J2EE and you only need POJOs, very easy to test. If you experienced the pain of working with plain JSPs and servlets, JSF is a blessing

Right now my J2EE knowledge extends to: Servlets, JSP, Tag Libraries (and JSTL) and EL. JSF was on my "to learn" list but with what you're saying I should really look at that now then

Cheers.

PS: Oh yeah, I'll never (ever ever ever) need to test anything in my JSP code Just templates, that's all I use JSP for

[Ben Souther]

Originally posted by Stan James:

One idea is to reduce the classes that know about HTTP, Session, Request, Response, EJB, etc. to minimal gateways. They do as little as possible before handing off responsibility to classes with no J2EE imports. For example, a servlet might copy all the request parameters into a HashMap and call a POJO. (You asked about doing this "without a framework" but you're really building a smallish framework at this point.)

+1

The more you can separate your core components from the the servlet api the easier it will be to test them. I like to see everything work from the command line before trying to get any of it to work from within a webapp.

Rather than tricking your objects into thinking they are being run from within a container, (ie: creating mock objects from the servlet API) make them so they don't care or even know if they are being run from within a servlet container; or Swing app, or JUnit test script.

[Chris Corbyn]

I'm using jMock (which is awesome by the way) for my mock objects because it's simple to generate the mocks and make expectations with it.

jMock allows me to create mock objects from the servlet spec interfaces with a few lines of code so I'm happy for now There's actually only a handful of objects which *need* to be mocked/stubbed in order for things to work.