News: JTR (Java Test Runner) 2.0 has been released
JTR ("Java Test Runner") is an open source J2EE testing framework based on inversion of control (IoC). It lets you build complex J2EE test suites that connect to application servers to execute tests, including multiple instances of tests.
- Posted by: Francesco Russo
- Posted on: May 11 2005 06:51 EDT
A JTR test suite is made of a set of factories (to control how the tests run and outcomes are evaluated), a set of runners (threads that actually execute tests), applilcation server settings (to allow multiple servers to be used in a given test run), and JMS configurations (to configure JMS resources). JTR uses all of this to run a test suite (specified as a set of runners) to provide unit and performance testing of EJB resources, JMS resources, and - of course - ordinary Java code.
The JTR framework is completely designed by interface. This means it provides you with a number of pluggability points you might use to customize its behavior via the factories block.
It's licensed under the GPL, and you can download it from Sourceforge.
- JTR (Java Test Runner) 2.0 has been released by analog boy on May 11 2005 09:06 EDT
- IoC and Spring Tests by Eu Gene Lim on May 11 2005 10:33 EDT
- JTR (Java Test Runner) 2.0 has been released by Francesco Russo on May 11 2005 10:42 EDT
- Unit-test or Stress-test? - authentication - full-j2ee by Alexander Jesse on May 13 2005 04:55 EDT
- Unit-test or Stress-test? - authentication - full-j2ee by Francesco Russo on May 13 2005 06:51 EDT
why didn't you use an existing ioc framework? i'd like to be able to use ioc in during testing, it's a shame there isn't an easy way of loading testcases from a spring context. i'd imagine it wouldn't be hard to get going tho, is anyone working on ioc with junit?
The Spring Test classes already support IoC, they autowire collaborators by type by default.
Well, simply because I wanted to spend some spare time practising what I learned about IoC in the past. Sometimes I think it's useful trying to code something instead of using something else that is already out-there, even if just for fun ;).
Seriously speaking maybe Spring was too much for me for writing JTR, so I decided to device something new on my own, tailored on my own needs.
Thanks for your opinion and hope you will try JTR 2.0 soon.
While I understand the desire to roll your own - I have done the smae in the past - going my own way rather than using existing architectures sometimes for reasons so ludicrous and petty I won't even meantion them here and sometimes just to know that I did it myself and now have a greater understanding of the concept in question.
However - I think the choice of not going with an existing, established IOC framework (or providing mechanisms of interoperability) will most likely hurt your chances of finding a following for your app.
Maybe I'm wrong, maybe it will light the world on fire like 'TestNG' ;-)
(Cedric - just kidding, TestNG is a fine project)
I do not think it is a matter of which IoC framework I have used for building JTR, mainly because JTR is not meant to be a new IoC framework. JTR is only based on such ideas, but is aimed to help developers in building test suites (both for J2SE and J2EE projects).
I would have expected more comments, opinions and suggestions about the JTR framework in its own essence and not about which existing framework I have used to apply IoC.
Hope to receive more comments related to what you think about the facilites JTR provides, and about what you think JTR lacks of today.
Thanks for your posts,
Focus: What is the primary focus? Is it unit-testing or stress-testing? This message is not very clearly given.
Authentication: Have you tried to use certificates for authentication purposes?
full-j2ee: I am looking for ways to unit-test JSF-components. But it seems your framework is focused on testing the backend of J2EE (JMS and EJB).
Thanks Alexander for your interest.
Your comments and questions are really well suited.
Actually I developed JTR to stress-test J2EE back-end systems (EJBs and JMS applications), but in my humble opinion it can be used for unit-testing too (I did it). Maybe nowadays it lacks some assertion facilities, but their implementation has already been planned.
As far as authentication is concerned at the moment I've only used the user-name/password authentication provided by J2EE app servers and messaging brokers. Anyway it is absolutely necessary to explore other mechanisms as you said.
It would be nice to find out others willing to contribute to the JTR project even in this area!
At the moment (as stated before) JTR is focused on backend J2EE technologies.
Regards and thanks for your interest,