Community
Participate
Working Groups
Selecting "Disable JMUnit" in turn causes filters for *Test and *TestSuite names to be added to the source folder. This is confusing if you have some java files that includes "Test" as part of their name but not using JMUnit. Perhaps the filter can be done so that only files depending on JMUnit is added to the filter.
currently we don't have enought engineers to work on this on 1.0 timeframe. i1m postponing this to a future release
Proposed Solution Hello everyone, Rather than excluding the classes in the source folders with name ending in "Test", exclude the classes that extends of "TestCase" or "TestSuite". To do so, when enable the JMUnit, scan the workspace by classes that extends "Test" or "TestSuite" and add them to the exclusion filters. Also add an IResourceChangeListener that will be looking for test classes modifications in the workspace in order to update the exclusion filters. When disabling JMUnit all exclusion filters will be cleaned and the workspace listener will be removed. Please, feel free to make suggestions! David Aragao
I like the idea. For me it's good enough. The only thing you must remember is to check the hole hierarchy of the class. I.e. class A extends Class B that Extends TestCase Could you provide a patch with the implementation of this solution? Thanks Diego
+1 for the proposed solution implemetation! (In reply to comment #2) > Proposed Solution > > Hello everyone, > > Rather than excluding the classes in the source folders with name ending in > "Test", exclude the classes that extends of "TestCase" or "TestSuite". To do > so, when enable the JMUnit, scan the workspace by classes that extends "Test" > or "TestSuite" and add them to the exclusion filters. Also add an > IResourceChangeListener that will be looking for test classes modifications in > the workspace in order to update the exclusion filters. When disabling JMUnit > all exclusion filters will be cleaned and the workspace listener will be > removed. > > Please, feel free to make suggestions! > > David Aragao >
Maybe I'm missing something... why are we mixing test case classes into the same source folder as the real source? Shouldn't they be in a different source folder?
The user can choose where to put the test classes, then it is a user's decision put in the same folder or not. The solution will work in both cases. Regards, David Aragão
I'm OK with the solution, but I do think we should be directing users to put their test cases into a separate source folder.
(In reply to comment #7) > I'm OK with the solution, but I do think we should be directing users to put > their test cases into a separate source folder. > I agree. Maybe we could set the default source folder on the "New Test Case wizard" to test. if the user wants, this folder can be changed.
Hello everyone, I will fix this bug and send a patch soon. Regards, Eric Sousa Dias
Created attachment 145309 [details] Patch to fix the confusion when disabling JMUnit Hello all, This patch proposes to fix the disabling JMUnit problem. The idea proposed by Craig (directing users to put their test cases into a separate source folder) can be created in another bug for improvement. Can anyone revise this patch? Eric Sousa Dias
Patch reviewed and code committed.
I, Eric Sousa Dias have created the patch attachment 145309 [details] solely based on existing (EPL licensed) code in the MTJ project, and wrote all new code 100% myself, without using any other open source or proprietary source code as a basis for my work. I am making my contribution available under the terms of the Eclipse Public License (EPL) to be included in the codebase of the MTJ project.
Released
