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
Currently, to make fixtures appears in the report, a user has to apply [AllureBefore] or [AllureAfter] to constructors and/or Dispose methods. Moreover, a correct attribute should be used, otherwise the fixture goes to the wrong section of the report.
This seems redundant. Ideally, we should pick the fixtures up automatically. In other words, this:
Put allure-xunit more in line with other allure integrations.
Consideration
The following should be supported to not take away features, users already have:
Specify a custom name of a fixture (via a new single attribute that replaces [AllureBefore] and [AllureAfter], a special attribute like [AllureTitle] or [AllureName] or, probablty, a built-in [DisplayName]).
Provide an ability to exclude a fixture from the report for those who prefer to hide some technical fixtures (again, via a new abovementioned attribute or something like [AllureIgnore] or maybe other means).
Backward compatibility
[AllureBefore] and [AllureAfter] should still be supported (although, marked as obsolete).
The text was updated successfully, but these errors were encountered:
Currently, to make fixtures appears in the report, a user has to apply
[AllureBefore]
or[AllureAfter]
to constructors and/orDispose
methods. Moreover, a correct attribute should be used, otherwise the fixture goes to the wrong section of the report.This seems redundant. Ideally, we should pick the fixtures up automatically. In other words, this:
should produce the same report as this:
Motivation
Consideration
The following should be supported to not take away features, users already have:
[AllureBefore]
and[AllureAfter]
, a special attribute like[AllureTitle]
or[AllureName]
or, probablty, a built-in[DisplayName]
).[AllureIgnore]
or maybe other means).Backward compatibility
[AllureBefore]
and[AllureAfter]
should still be supported (although, marked as obsolete).The text was updated successfully, but these errors were encountered: