Closed andre2007 closed 3 years ago
@linkrope thanks a lot.
I'm not happy that dunit.framework
has to be changed in three places for each of the new attributes.
Instead of just copying the attribute values to testClass
, it should be possible to transform all of them to DisabledIf
. Because, EnabledIf
has just the negated condition. And the special forms Disabled/EnabledIfEnvironmentVariable
and Disabled/EnabledOnOs
just hide conditions that the users don't want to write. So, two of the places have to be changed once for supporting DisabledIf
. While even futher similar attributes could be added in a single place, where each is transformed into a corresponding DisabledIf
.
One problem is that the "reason" must be precomputed in this case. During the transformation only a less helpful reason can be provided.
The other option would be to transform all the attributes already to Disabled
. The "reason" would be as helpful as it is now. But all conditions are evaluated at the start of the (test) program. I don't know what's the intended behavior: now it's possible that one test case sets an environment variable to a value, that's required for a Disabled/EnabledIfEnvironmentVariable
of a test case that runs later. This would not be possible if all conditions are evaluated at the start of the program.
Also, I'm not sure whether it's OK that there can only be one DisabledIf
per test case. I would have preferred multiple occurrences (as for Tag
). But even JUnit warns that all but one occurrence will be silently ignored.
Yes, all you said is true.
In my opinion the test cases should be independent of each other. One test case should not be able to influence the behaviour of another test case.
Therefore this can be refactored in future. On the other hand, there are these 3 attributes, nothing more (the properties attribute from junit5 is not relevant).
New junit attributes added: