Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

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

 
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JavaWorld: Testing J2EE applications (2004-Aug)
J.B. Rainsberger (Diaspar): Test-Driven J2EE
[ September 10, 2007: Message edited by: Peer Reynders ]
 
Chris Corbyn
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.



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
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 375
Scala Monad
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
 
Sheriff
Posts: 13411
Firefox Browser VI Editor Redhat
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Space pants. Tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!