The JTR Project is a Java distributed testing framework aimed at fastening the development of both functional and stress-test suites for verifying the requirements and robustness of both JSE and JEE projects. The JTR Framework supports you in writing components meant for testing: 1. standard JSE components / applications 2. EJBs conforming to both J2EE 2.x and JEE specifications 3. MOM-based JSE and JEE systems (JMS) 4. web-services (both document-based and rpc-like) Here is the list of the most important interventions carried out for this release: 1. JTR 4.0 enables effortless distributed testing (EDiT). This means that you can instruct the JTR runtime to distribute your test-sessions to a set of JTR passive-nodes that will execute concurrently with your JTR active-node. This is achieved just declaratively. Not a single line of code is required and you are not asked to take care of jars/libraries distribution amongst all the cooperating JTR nodes 2. JTR 4.0 introduces an appealing and friendly graphical user interface that pops-up at test completion for showing you all the collected results with some aggregate data. For further elaborations the JTR Console lets you export all the collected outcomes into the Excel format as well 3. the WSIF 2.0 based webservices-invocation engine has been deprecated. This implementation is going to be dropped in the next JTR minor-release 4. a new JAX-WS 2.1.1 based webservices-invocation engine has been introduced that replaces the former WSIF-based implementation. This new engine supports synchronous, asynchronous and one-way MEPs, still leveraging on DII. As a consequence of using JAX-WS 2.1, by default JTR 4.0 requires that input and output messages are generated by means of JAXB 5. enhanced the property-injection capability of the JTR-runtime. Before this release the JTR-runtime was not able to assign a value to your runners’ inherited properties if a mutator method was not publicly available, during the parameterization process. With JTR 4.0 this limit has been finally exceeded This new release also features a brand new users' guide that will help you in learning all the features JTR 4.0 provides you with. More information are available at http://jtrunner.sourceforge.net

Do you distribute junit or testng test or do you have your own formalism? Emil Kirschner

Do you distribute junit or testng test or do you have your own formalism?

Emil Kirschner

JTR has always had its own test-representation and its own way of test-suite definition/implementation. This means that, as highlighted in the brief posted note and as described in the JTR Users' Guide, JTR is a framework that allows you to implement "natively" your own tests, and it is not a wrapper built around other testing tools. Thanks for your interest, Francesco

In practice, I suspect introducing your own test framework just ends up turning away your potential users. The project would be much more appealing and practical for many if JTR builds on JUnit and adds distributed testing capability. I think the documentation can be also improved. You really need to have a "3 minutes tutorial" kind of document to get your visitors hooked, before going into all the gory details like the XML format and various interfaces. The simplest test I could find in your doc is in http://jtrunner.sourceforge.net/JTR/UG%204%20API.html and this trivial test takes more than 20 lines! Probably not all the methods are mandatory, but again, as a first time visitor, it just doesn't look very convincing, and hence my suggestion for a 3 minutes tutorial, where you can show how simple things can be done simple. (From JUnit/TestNG users, I also find it puzzling that a test case extends from a test runner.) Just my 2 cents...

Hi Kohsuke, first of all thanks for your point of view. JTR does not build on top of JUnit (I'm talking about it because you mentioned it) merely because they are too much different from each other. JTR has a completely different approach than JUnit, and it is much more inclined to stress-testing than JUnit. Furthermore JTR is not just about "distributed testing", thus I guess it is much too reductive stating it would have been a better idea using it to add JUnit distributed testing capabilities. As far as the Users' Guide is concerned I agree with you that a brief "3 minutes tutorial" could be useful for potential new users, and I do hope I'll find the time to arrange one. But in the meantime I found it was much more important having a really detailed Users' Guide showing the full potentials of the JTR Project, to enable users to accomplish in the smoothest possible way what they wanted to. I do think, according to current JTR users experience I have been informed about, that JTR is not as hard to learn as you think. Maybe the Users' Guide is full with details yes, but I do think details are a really precious things when trying to do things better. Thanks, Francesco

JTR does not build on top of JUnit (I'm talking about it because you mentioned it) merely because they are too much different from each other. JTR has a completely different approach than JUnit, and it is much more inclined to stress-testing than JUnit. Furthermore JTR is not just about "distributed testing", thus I guess it is much too reductive stating it would have been a better idea using it to add JUnit distributed testing capabilities.

Still don't get it. What's the big difference to JUnit/TestNG?

... and hence my suggestion for a 3 minutes tutorial, where you can show how simple things can be done simple.

+1

Still don't get it. What's the big difference to JUnit/TestNG?

Hi Rex. Well, JTR and TestNG have a lot of intersections and overlappings actually, but I guess there is just one fundamental reason that can explain these similarities: they both have been conceived in parallel and (this is my very own opinion) have been motivated by the same needs arose due to the extreme simplicity of JUnit. That's why, as far as I'm concerned, today we have both JTR and TestNG. Nevertheless I do believe in diversity and good/loyal competition. About JUnit I have to say that four years ago when I started JTR I did not wanted to tie myself to any particular already existing framework, just to be as much free as possible in the decisions I would have made. I understand it is important for guys like you having new tools that support/integrate older ones, but sometimes there are simply circumstances that prevent this from happening since the beginning. Anyway I'll try to not ignore these important points of view. Francesco

Well, JTR and TestNG have a lot of intersections and overlappings actually, but I guess there is just one fundamental reason that can explain these similarities: they both have been conceived in parallel and (this is my very own opinion) have been motivated by the same needs arose due to the extreme simplicity of JUnit. That's why, as far as I'm concerned, today we have both JTR and TestNG. Nevertheless I do believe in diversity and good/loyal competition. About JUnit I have to say that four years ago when I started JTR I did not wanted to tie myself to any particular already existing framework, just to be as much free as possible in the decisions I would have made.

Thanks for the explanations.

Francesco, It looks like you can only define one test method per JTR test class, is this correct? -- Cedric

Francesco,

It looks like you can only define one test method per JTR test class, is this correct?

--
Cedric

Hi Cedric, glad to read you again. Yes, you are right, there is one "test" method per JTR Runner, but this is not a strong limitation in the sense that JTR Runners' runs are always parameterized according to what stated in the jtr.xml file by the user, thus the "test" method becomes merely an entry-point from which the JTR Runtime can launch that JTR Runner's logic, a logic that is always parameterized. Obviously that's what a JTR Runner looks like today, but things might change in the future. Francesco

How is this different from TestMaker?

Hi Ilya, I must humbly admit that I did not know that testing tool before you mentioned it in your post, so in order to be able to answer your question I've just given a look at it. As far as I can see it is much more focused on supporting HTTP, SOAP, XML-RPC, and the email testings. I guess, but I might be wrong not knowing it well, that it does not provide an out of the box environment for either JMS or EJB testing while the JTR Project does, being focused on the set of back-end JEE technologies. Another peculiarity of the JTR Project is its "runners parameterization feature". You can easily instruct the JTR runtime, via the jtr.xml file, about running your runners with different parameterizations. I still seems to me (but I might be wrong) that TestMaker has no such feature. Please, do not hesitate to fix wrong impressions I might have had. Thanks, Francesco

Hi Ilya,
I must humbly admit that I did not know that testing tool before you mentioned it in your post, so in order to be able to answer your question I've just given a look at it. As far as I can see it is much more focused on supporting HTTP, SOAP, XML-RPC, and the email testings.
I guess, but I might be wrong not knowing it well, that it does not provide an out of the box environment for either JMS or EJB testing while the JTR Project does, being focused on the set of back-end JEE technologies.

Another peculiarity of the JTR Project is its "runners parameterization feature". You can easily instruct the JTR runtime, via the jtr.xml file, about running your runners with different parameterizations. I still seems to me (but I might be wrong) that TestMaker has no such feature.

Please, do not hesitate to fix wrong impressions I might have had.

Thanks,
Francesco

Francesco, agree, good assessment. TestMaker is more of a functional testing framework with a focus on SOA, specifically SOAP/XML-RPC. It does not provide a way to test the lower layers. Frank and I talked about it before, but I don't think it ever got beyond our late night IM conversations:-) With that said, I'll take a look at JTR sometime soon and see how we can incorporate it into one of our projects. We're currently revamping our QA practices and incorporating functional testing frameworks on top of our current unit testing TDD practice with TestNG. Thanks.

Francesco, agree, good assessment. TestMaker is more of a functional testing framework with a focus on SOA, specifically SOAP/XML-RPC. It does not provide a way to test the lower layers. Frank and I talked about it before, but I don't think it ever got beyond our late night IM conversations:-) With that said, I'll take a look at JTR sometime soon and see how we can incorporate it into one of our projects. We're currently revamping our QA practices and incorporating functional testing frameworks on top of our current unit testing TDD practice with TestNG.

Thanks.

Hi Ilya, glad you have found my post correct in its contents. Yes, actually we can say that JTR has a partially different focus than TestMaker. I do hope you'll find it useful integrating JTR in TestMaker. Please, feel free to contact me in case of need. Thanks, Francesco