-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run only a test of a class with Parameterized runner #664
Comments
Fixing this would be great, we end up having to comment UTs in large test classes which is undesirable. |
The Maven Surefire plugin allows to to specify globs (see http://maven.apache.org/surefire/maven-surefire-plugin/examples/single-test.html). Have you tried that? |
Yes, that's how we would like to use, but it doesn't work. Are you saygin that this is a problem of the surefire plugin and not from junit? |
@diogoeag I believe it's a problem with the Surefire plugin. You can verify that by writing a class with a main method that uses JUnitCore to run the tests of a class that used |
Hi Kevin, Take a look at these two samples: First test without parameterized:
output
Second test with parameterized:
output
The Description passed to the Filter by the Parameterized is not correct right? |
@diogoeag Thanks for the code example. What version of JUnit did you try this on? I think we fixed a related issue in 4.12 but I am not sure. |
@kcooney, I've tested with the current master 4.12-SNAPSHOT and also with 4.11. Both have the same problem. |
Thanks. Fixing this would like require changes that are not backwards compatible. Setting milestone to 5.0 |
Just to clarify, fixing this would only need to go to BlockJUnit4ClassRunnerWithParameters and remove the override of the #testName method. That is replacing the default
by
And the consequencies would be that the reporting of the tests would not have the parameter name in the testHeader (at least the tests that have failed were only these)? |
@diogoeag but wouldn't we want the parameter name in the description? I think the fixes would best be made on top of the Description builder we are working on for JUnit 5.0. |
@kcooney Yes to be correct we should have the parameter name in the description, but the description should not affect the test name. I agree with you that the Description should have a test name that should be the correct name and the display name that should be used in user facing descriptions and include the parameter. Do you have any estimates on the target date to 5.0 ? I was looking to the usages of getDisplayName to submit a pull request to 5.0 with the fix, however it is used 23 times in the project (sources and tests) and I don't have the enough knowledge of JUnit source to make such change. Meanwhile I will make a fork for my personal usage with that intermediate fix for me. Having the parameter names is not critical, however allowing us to run single tests saves us many hours in many developers running tests in our source. Thanks |
If anyone needs to have access to this temporary fix: feedzai@be41d29 |
@diogoeag |
@Tibor17 I'm not sure. Because shoudlRun will use the description also. I don't know enough of the codebase to know if it will work. Only testing it. My sample code can be one of the tests for your fix also. Using parameterized tests has the problem of changing the test name. |
@diogoeag
If you want to tolerate the JUnit issues, you can commit hotfix by yourself in Maven Surefire project. |
@diogoeag we don't yet have a target date for JUnit 5.0, but it would likely be the release after 4.12. We are currently focusing on getting 4.12 out the door |
@kcooney thanks. We will use our internal release meanwhile. |
Hello, what about this issue? Is there a workaround to use Parameterized.class and have the possibility to run a single test using maven surefire? Or do we have to wait the 5.0 version for it? |
@Fanch- there is no current fix. We thought would fix this on too of the ImmutableDescription work we were working on, but that effort was abandoned. |
As long as all |
We could set the unique ID in the description to make them unique. However, I'm wondering if/why they need to be unique in the whole subtree? |
Yes, |
Point taken. So, I think we should add a new factory method to |
@marcphilipp there already is a method in Description for creating a test Description with a given unique ID: https://github.com/junit-team/junit4/blob/master/src/main/java/org/junit/runner/Description.java#L109 I don't think that |
Yeah, but that one does not have a class parameter. So we need a different one.
I didn't mean that. I meant that |
SGTM. Even though we dropped the idea of having immutable Description instances for JUnit 4, should we add a builder to avoid having so many static creational methods? |
Sure! 👍 |
Are there any estimates when it'll be fixed ? |
@SqAutoTestTeam no one is actively working on this. I did update the Description builder branch recently so an ambitious contributor could start from there. Alternatively, we could add yet another static method to Fixing this would require new APIs on Description. We wouldn't want JUnit 5 to require those new APIs (currently JUnit 5 would work on just about any version of JUnit 4.x) |
@diogoeag Filtering parameterized tests works since of version |
@kcooney and @marcphilipp, What do you guys thinking about "backporting" the fix in https://github.com/junit-team/junit5/pull/1018/files#diff-42ed8b618527eb1521dbe3cd9100e949R48 to JUnit 4? |
@sbrannen that looks like a reasonable change. I would just want to make sure that if we backported those changes we wouldn't make JUnit 4.13 incompatible with JUnit 5, or require projects with JUnit 4-style tests to upgrade to 4.13 before they can run their JUnit 4-style tests using the JUnit 5 runner APIs. |
👍
In JUnit 4 the change would only be to a single line in So, unless I'm overlooking something, that should avoid any compatibility issues. What do you think? |
@sbrannen SGTM |
When using the Parameterized runner there is no possibility to run only a test method of a test class.
For example when running in maven: mvn test -Dtest=TesClass#testName
No tests are run when using the Parameterized runner.
That would be great to have this feature, has for development is comon to the developers trying to run only the test they are working on.
The text was updated successfully, but these errors were encountered: