Class Rants
- java.lang.Object
-
- com.carrotsearch.randomizedtesting.Rants
-
final class Rants extends java.lang.Object
Rants about blocker limitations of JUnit...
-
-
Nested Class Summary
Nested Classes Modifier and Type Class Description (package private) static class
Rants.RantType
-
Field Summary
Fields Modifier and Type Field Description static Rants.RantType
RANT_1
This if freaking dumb...static Rants.RantType
RANT_2
Default assumption methods (and constructors in AssumptionViolatedException) do not allow specifying a custom message?static Rants.RantType
RANT_3
Why is failed assumption propagated as a Failure? This is weird an unnatural.static Rants.RantType
RANT_4
JUnit is inconsistent in how it treats annotations on methods.
-
Constructor Summary
Constructors Constructor Description Rants()
-
-
-
Field Detail
-
RANT_1
public static Rants.RantType RANT_1
This if freaking dumb... there's absolutely no way to carry test class/ test name separately from the display name, so we can't easily include seed info on the test case. If we do, Eclipse complains it cannot find the target class/ test name. If we don't, Eclipse's JUnit runner gets confused and doesn't show test case execution properly. We can't even use a proxy or a subclass because Description has a private constructor. Eh. Having a Description properly indicate the test case/ class is useful because we could re-run a concrete repetition of a given test from the UI. Currently this is impossible - we can re-run the entire iteration sequence only (or fix the seed on the method, but this requires changes to the code).
-
RANT_2
public static Rants.RantType RANT_2
Default assumption methods (and constructors in AssumptionViolatedException) do not allow specifying a custom message?
-
RANT_3
public static Rants.RantType RANT_3
Why is failed assumption propagated as a Failure? This is weird an unnatural.
-
RANT_4
public static Rants.RantType RANT_4
JUnit is inconsistent in how it treats annotations on methods. Some of them are "inherited" and some require presence on the exact sameMethod
as the one used for testing. This has awkward side effects, for exampleIgnore
andTest
must co-exist on the same method, not on virtual method hierarchy. You cannot makeTest
methods protected and publish them in subclasses. Shadowing ofBeforeClass
methods is inconsistent (non-annotated shadowed method will not be called, shadowed method annotated withBeforeClass
prevents the shadowed method from being called), etc.
-
-