junit plugin RFE : patterns linked to templates...

Hi you can already do this here is what you do, create a ServerTestCase template in idea, in the fileTemplates menu under project settings, something along these lines:

package $;

import junit.framework.*;

public class $STest extends TestCase { } // the $ is the name if the test class, then in the plugin configuration under project settings on the templates plugin include this under the test class templates box, then when you click an icon or click CTRL-SHIFT-T you will be given an option of which template to use, when creating your server classes use the server template otherwise slect another. Hope this answers your question

sorry the templates tab!! under the junit plugin icon

Nice one. Thanks for the info.

Actually, this method doesn't work. The problem is navigation between the tested class and the testing class.

The testClass pattern dictates how to link the tested class and the testing class and it can't manage multiple mappings. So if my template doesn't follow the testClass naming pattern I define on the patterns page, then bad things happen.

The good news is that I have already started implementing this.

My end goal is not only to support multiple patterns but also to support the same mechanism as test methods for test classes: a pattern will support multiple fixture classes for the same pattern:
$CLASS$ -> Test$CLASS$$OTHER$ will associate
MyClass to TestMyClass, TestMyClassCanonicalOperations,TestMyClassFirstResponsability, the same way as fct() -> testFctFirstCase, testFctSecondCase...
That way you can really partition your tests based on a unique fixture and don't end up lumping every single fixtures into one fixture class.

The other feature I want to implement is an intention to move an operation to the setUp/tearDown and maybe later inlining setup/teardown to every tests or one test.

Like I was saying I already started on the multi-pattern support: I have already done a basic configuration ui. I am now going through the navigation/creation and will need to look into the automated refactoring as well. Prior to doing this I am also doing some major cleanups/refactorings that I delayed for too long (so now they are really sizable tasks, not to mention that they touch all 3 of my plugins since they all share the same common framework ;-( )

Now, outside of the coding, I am unsure on how to navigate through all these test classes so I would appreciate any feedback/suggestions:
My first implementation will certainly be a simple list with an option to show the originating test class. But this is far from being useable.
Problem 1: patterns might be different type of tests. How should we differentiate them in the navigation and in the creation. Should a pattern be named and that name presented as the first navigation selection dialog...
Problem 2: Some patterns might be legacy. Should they be allowed to be used to generate new tests? Would it be interesting to have an automated tool to move the test class from one pattern to another...
Problem 3: How to present the tests of multiple test class associated with one pattern. As they belong to one pattern it seems logical that they should be displayed together.
Problem 4: Is a simple list enough to represent the 3 levels being introduced: pattern->testclass->testmethod. Would a tree be better (beware however that I will be stretching my swing knowledge to make it keyboard friendly...)

Anyhoo, this is a lot of work so don't hold your breath. I don't expect releasing something before the end of September. And that my friend is the bad news ;)

Jacques

Alan, I believe I hear you need to be able to associate a template with a pattern. Is that right?

If I get to do this, the first implementation will most likely be the most expediant: similar to today the plugin will remember the last used template per pattern and preselect it. Would that be enough?

Jacques

I think that would work for me if I understand what you're proposing. Am I right in saying that this would mean that each pattern would be associated with one template? And that I'd be able to define multiple pattern 'translations' with each one associated with it's own template? That would certainly work for me. Once I've set a pattern to a template, I intend for that pattern to always be associated with that template.

The way I imagined it working was from that I'd generate a template and then set a pattern to it, as this is the way I think of my tests.

In my plan, every time a testclass template was added in the templates tab, there would be an extra row on the patterns tab for that template, enabling me to set the tested class pattern name and test class pattern name (so there would be 3 columns in each row: the template name, the tested class pattern, and the test class pattern). In this way multiple templates could be associated with the same pattern.

I'm not sure how this would affect navigation between the testers and the tested though.