Add JameleonUnitTestCase for help with debugging.

Logged In: YES
user_id=60860
Originator: NO

I did remove this back in the M2 release. Have you looked at the JUnit tag that does the same thing? Because the results were totally refactored, the JameleonTestCase depended on it so heavily and there was already a JUnit tag that does this (that also required a refactor), I just pulled it out. Can you use the provided tag to do this? If not, then I'm afraid so much changed behind the scenes (and even more changes to come) that even it put it back, then it will no longer even compile.

Logged In: YES
user_id=245333
Originator: YES

Thanks for the reply... we figured the refactoring preserved the functionality in some way, just not exactly where.

This is what we would like to do (this is how we use JameleonTestCase today):
1. Write a custom Jameleon tag, compile in the usual fashion using Ant.
2. Write a Jameleon script using that tag, with associated csv files
3. Create a JUnit test case within Eclipse
4. Within the JUnit test case code, call (somehow) the Jameleon script from step 2.
5. Put a break point in the customer tag class
6. Run the JUnit test case in debug mode within Eclipse
7. Step into and inspect the running customer tag Java code.

Once the custom tag is debugged, include that tag in a normal Jameleon script that can be called from Ant or whereever.

Is there an example of step 4 that I can look at using the JUnit tag ?

Logged In: YES
user_id=60860
Originator: NO

Yes.

ExecuteTestCase exec = new ExecuteTestCase();
exec.executeJellyScript(new File("script-to-run.xml"));

Does this do the trick?

I could write a real JameleonJUnitTestCase that does this for you, but w/o all of the custom validation of the previous JameleonTestCase. The new one would return the test case results which you could then use to verify the behavior.

Logged In: YES
user_id=245333
Originator: YES

The ExecuteTestCase provide the functionality of being able to debug our tags.

In fact, we were able to copy the JameleonTestCase class from 3.2 into 3.3 and run it. We do not need all the functionality of the old class.

A simple JameleonJUnitTestCase would suit our needs. Having the ability to run a script as you indicated, plus having access to the test case results for later inspection is sufficient to verify our tag behavior.

I assume the JemeleonJUnitTestCase you have in mind would register appropriate listeners to build a test result in a convenient manner for consumption within a JUnit environment. If you like, we could assist with writing this class, given some examples to start from.

Logged In: YES
user_id=60860
Originator: NO

The ExecuteTestCase class has a method that registers the listeners based on what's configured in jameleon.conf. I just added a new method that registers a listener based off an instance of a TestCaseListener. This should make it much easier to do this in the new JameleonJUnitTestCase.

Then we could have a new JameleonJUnitTestCase that has a new method in it called runScript which returns a TestCaseResult. We could even add another method that takes a String representing the script so you wouldn't need to write a script just to unit test the tag. Does that make sense?

The JameleonJUnitTestCase would then implement TestCaseListener with something like so:

public void beginTestCase(TestCaseEvent event){}

public void endTestCase(TestCaseEvent event){
TestCaseTag tct = (TestCaseTag)event.getSource();
testCaseResult = tct.getResults();
}

public TestCaseResult runScript(File script){
ExecuteTestCase exec = new ExecuteTestCase();
exec.registerEventListener(this);
exec.executeJellyScript(script);
return testCaseResult; //instance variable of the JameleonJUnitTestCase class.
}

If you would like to implement that, it would really help. If you have any questions on how to write a unit test for it, just let me know (all Unit tests go in tst/java. The class should then be added to the tst/java/TestAll.java class.

If you wanted to add the ability to just pass in a String containing the actual script instead of a File, we would need to add a new method to ExecuteTestCase that accepted a String instead of a File. We would then create a StringReader from the String and instantiate a org.xml.sax.InputSource object and pass that to Jelly.

Logged In: YES
user_id=60860
Originator: NO

This feature has been commited to SVN and will included in the
next release