You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are (still) problems we see with the current state:
The stack traces of "filtered" elements from templates are lost for the "Run History". The root cause is that the UI elements are serialized (and restored later) and if we filter children with stack traces in UI, we also don't serialize them and so on restore there is nothing... Stack for that (where getFailureTrace() returns null and there are no children):
The "diff" (CompareResultDialog) dialog shown if the test fails comparing results is not shown for the "filtered out" template test results, because the code that asks for the diff checks org.eclipse.jdt.internal.junit.model.TestElement.isComparisonFailure() which is not true for the "parent" node that shows the fail after filtering out children.
The fixes in #946 and #1022 were unfortunately not complete.
One possibility to fix them would be replace parent TestSuiteElement element with one of the failed child elements instead of filtering children, or fully mimic "I'm not a suite, I'm a test" behavior by overriding some testsuite methods.
For the later, I will propose a PR in a moment, which will fix observed issues.
For 4.31 we can either take that or revert changes as proposed in #1203.
As before, the test case to play with is following:
In case the testsuite contains a single dynamic test (like repeated
tests), provide the relevant test data if asked for that, not suite
data.
Fixeseclipse-jdt#1216
Follow up on #946 and #1022.
There are (still) problems we see with the current state:
getFailureTrace()
returns null and there are no children):CompareResultDialog
) dialog shown if the test fails comparing results is not shown for the "filtered out" template test results, because the code that asks for the diff checksorg.eclipse.jdt.internal.junit.model.TestElement.isComparisonFailure()
which is not true for the "parent" node that shows the fail after filtering out children.The fixes in #946 and #1022 were unfortunately not complete.
One possibility to fix them would be replace parent
TestSuiteElement
element with one of the failed child elements instead of filtering children, or fully mimic "I'm not a suite, I'm a test" behavior by overriding some testsuite methods.For the later, I will propose a PR in a moment, which will fix observed issues.
For 4.31 we can either take that or revert changes as proposed in #1203.
As before, the test case to play with is following:
The text was updated successfully, but these errors were encountered: