Community
Participate
Working Groups
currently default includes will be **/Test*.java **/*Test.java **/*TestCase.java In the Eclipse-IDE offers a way to add a TestSuite and name this "AllTests", so it woud be good to include **/*Tests.java into the default pattern.
One risk with this is that if you have Test1 Test2 Test3 and AllTest being a suite of the 3 previous one, then a new pattern would basically run Test1, Test2 and Test3 twice: one as standalone testCases, and once as part of the suite.
Thats true but in fact in my case a "Suite" is only used because of all other tests don't match in name.
(In reply to Christoph Laeubrich from comment #2) > Thats true but in fact in my case a "Suite" is only used because of all > other tests don't match in name. It's not the general case. Platform has plenty of suites structured to cover different parts, different package, with some different settings... Also, different tools (JDT even) may provide extra-value for suites that make people define them anyway. So we cannot assume that people are fine getting of suites to make a decision here. IMO, it's still about always better to explicit the `test` in the pom.xml.
Okay, I see, will close this request as it seems to be not suitable.
I noticed that Eclipse-Platfrom-Test uses the following setup: <packaging>eclipse-test-plugin</packaging> <properties> <testSuite>${project.artifactId}</testSuite> <testClass>org.eclipse.text.tests.EclipseTextTestSuite</testClass> </properties> But I can't find out what these properties actually means, can someone redirect me to the documentation? Maybe we just need support for those in the pomlessbuilds to resolve my issue?
(In reply to Christoph Laeubrich from comment #5) > <properties> > <testSuite>${project.artifactId}</testSuite> > <testClass>org.eclipse.text.tests.EclipseTextTestSuite</testClass> > </properties> > > But I can't find out what these properties actually means, can someone > redirect me to the documentation? Those are properties to configure the tycho-surefire-plugin: https://www.eclipse.org/tycho/sitedocs/tycho-surefire/tycho-surefire-plugin/test-mojo.html#testClass The testSuite may actually be useless.
Thanks I'll test this, can these properties also be specified in the surefire.properties[1] file or must they be given by maven-properties? [1] https://www.eclipse.org/tycho/sitedocs/tycho-surefire/tycho-surefire-plugin/test-mojo.html#surefireProperties
(In reply to Christoph Laeubrich from comment #7) > Thanks I'll test this, can these properties also be specified in the > surefire.properties[1] file or must they be given by maven-properties? I don't know, sorry.
After some more investigation I think what we really need is supporting to pass some properties "pomless" to the tycho-surefire plugin, I'll prepare a patch for this so we can review/discuss.
(In reply to Christoph Laeubrich from comment #9) > After some more investigation I think what we really need is supporting to > pass some properties "pomless" to the tycho-surefire plugin, I'll prepare a > patch for this so we can review/discuss. Either there is a stamdard file for surefire oraven pomless to pass those properties and we should reuse those, otherwise.wecan use the build.properties fileas source for build properties. It's essential that Tycho doesn't define a new convention, a nez file name, whatever.
Yep, build.properties could be used as it already is used for marking/skipping a bundle as a test. I just want to investigate some setups in the wild to check if we can guess some properties from the manifest for example.
*** This bug has been marked as a duplicate of bug 564670 ***
