-
Notifications
You must be signed in to change notification settings - Fork 149
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
org.junit.runner.Description.fAnnotations array is null with junitparams parameterized junit tests #151
Comments
Thank you kompacher for your fixes, thats great you have had a look into! |
Will this change furthermore come with one of the next version updates of this project? |
Hello, I've just merged PR that fix broken build and we will try to review the main PR in next week. Thanks for your contribution :) |
If everything is ok with the PR we will release new version of JUnitParams since there is quite a lot of changes. |
Dear @kompacher |
Hello @woprzech, |
Any word on when a version with this will be released? I'm having the same issue where I have a JUnit rule which modifies test behaviour based on an annotation and the rule doesn't work properly because JUnitParams does not pass through the annotations |
I am waiting for this fix to get merged in as well. Is this being maintained anymore? |
The main dependency has a bug where annotations added on test methods are not forwarded to any test rules (Pragmatists/JUnitParams#151), which breaks the `ExpectedUnsubscribed` annotation used for hinting to the `RxErrorsRule` that we expect a certain number of `Completable` instances to not be subscribed to. There is a PR to fix it (Pragmatists/JUnitParams#158), but this has been inactive for over a year, so I forked the repository and applied the fix myself and published it via Jitpack.
I forked the repository, applied the fix myself and published it via Jitpack. Repository: https://github.com/vinaysshenoy/JUnitParams |
The main dependency has a bug where annotations added on test methods are not forwarded to any test rules (Pragmatists/JUnitParams#151), which breaks the `ExpectedUnsubscribed` annotation used for hinting to the `RxErrorsRule` that we expect a certain number of `Completable` instances to not be subscribed to. There is a PR to fix it (Pragmatists/JUnitParams#158), but this has been inactive for over a year, so I forked the repository and applied the fix myself and published it via Jitpack.
The main dependency has a bug where annotations added on test methods are not forwarded to any test rules (Pragmatists/JUnitParams#151), which breaks the `ExpectedUnsubscribed` annotation used for hinting to the `RxErrorsRule` that we expect a certain number of `Completable` instances to not be subscribed to. There is a PR to fix it (Pragmatists/JUnitParams#158), but this has been inactive for over a year, so I forked the repository and applied the fix myself and published it via Jitpack.
The main dependency has a bug where annotations added on test methods are not forwarded to any test rules (Pragmatists/JUnitParams#151), which breaks the `ExpectedUnsubscribed` annotation used for hinting to the `RxErrorsRule` that we expect a certain number of `Completable` instances to not be subscribed to. There is a PR to fix it (Pragmatists/JUnitParams#158), but this has been inactive for over a year, so I forked the repository and applied the fix myself and published it via Jitpack.
The main dependency has a bug where annotations added on test methods are not forwarded to any test rules (Pragmatists/JUnitParams#151), which breaks the `ExpectedUnsubscribed` annotation used for hinting to the `RxErrorsRule` that we expect a certain number of `Completable` instances to not be subscribed to. There is a PR to fix it (Pragmatists/JUnitParams#158), but this has been inactive for over a year, so I forked the repository and applied the fix myself and published it via Jitpack.
The Annotation[] array fAnnotations ( -> org.junit.runner.Description.fAnnotations) we need to be not null for failure reporting but it is unfortunately null when using junitparams parameterized junit 4.12 testcases.
We have derived our own TestCaseRule implementation from org.junit.rules.TestWatcher for doing custom evaluations with reporting purposes in every tetcase run context and before each any testcase code itself is being run by junit runner.
Within this relevant rule, which seems not to be working any more with junitparams, junit runner runs startingQuietly(description, errors) method in org.junit.rules.TestWatcher.
This methods description parameter object shows up some unset fields, but only when invoked with junitparams runner annotated testclasses!
Because this description object ( -> org.junit.runner.Decription) contains annotation data in any other testcase case and when called within any testcase context, but its field fAnnotations array is however always empty. In any other parameterized (with junit parameterized runner) or non parameterized junit testcase case the fAnnotations array size is at least 1at time of evaluation / runtime -> because the @test annotation is always included, present at any testcase.
Not so with junitparams even these annotations (@test, @CustomizedAnnotation .. ) are always present!
We have customized Testcase Annotations and a rule to evaluate this we must annotate all our testcase methods with it, but which are unfortunately also not included in this fAnnotations array. For all other Junit Parameterized or NonParameterized Tests it works fine, all annotations which are found at the public testcase method will be found in that array again. Not so with JunitparamsRunner testcase annotations :(
When running a parameterized junitparams Testcase it is beside other member fileds, which are set at this callstack time usually, always null, but for our failures reporting tool necessary not to be null, never!
Would like to keep this runner in our project but if the reporting issue due to null annotations in descriptions objects remains unsolved, other arguments may win...
We still use JUnitParams v.1.1.1
Do you have any idea for a fix or change or workaround?
Cheers!
The text was updated successfully, but these errors were encountered: