Open selenareneephillips opened 6 years ago
@juherr @krmahadevan @cbeust
I am exploring ways to fix this issue and I wanted to confirm something. I cannot actually add a new method, getMetaGroups() to the ITestNGMethod interface, correct? When fixing this defect, should I go forward with the assumption that no additional accessors can be be added to any of the public interface classes?
@selenareneephillips - Yes, that is correct. We cannot alter any existing interfaces because we can break compatibility for our users. But you could have BaseTestMethod
implement a new interface which would house the new method getMetaGroups()
. That way you dont break anything, and you can always run an instanceof
check and then type cast to the new interface accordingly.
For an example you can refer here wherein I had to do the same thing when fixing #1046
Hope that helps.
@krmahadevan Sounds great. I'm gonna follow that strategy.
I don't know if it is possible, but you may manage meta-groups at introspection time and replace meta-groups by their groups. At runtime, meta-groups will be lost but maybe we don't need them.
TestNG Version
6.13.1
Expected behavior
When a meta group is defined in either the test or the suite xml tag and that group is included in the test run, the method object should correctly indicate membership in that meta group.
Actual behavior
Method membership in meta groups is not correctly handled when the metagroups are defined on either the test or the suite tag. The only group membership recorded on the method object is for groups defined inside @Test annotations.
Is the issue reproductible on runner?
Test case sample
groupsbug.zip