Vasileios Karakasis

And we should remove the migration guide from 2 to 3.

I'm not convinced that we should deprecate `sanity_patterns`, because it allows us to define the sanity checking in the class body if we don't need to refer test attributes, such...

We decided not to deprecate this now as it would be a major disruption for the framework's users. Nonetheless, none of the new examples in the framework use `perf_patterns` since...

Hi @boegel, this is related to #97 and it is in our roadmap.

As discussed, we will not deprecate `variables` because this would cause a major disruption. The same way we have not deprecated the override of `__init__` in tests. We could introduce...

@brandongc that’s a valid feature request. I’m not sure yet what would be the best place to implement this. Do you want the notifications to be controlled per test or...

@brandongc I see this mostly as a separate or alternative reporting step at the end rather than part of the logging. Logging was conceived mainly for logging framework's activities rather...

Another argument towards a separate test result notification component is that a site might also like to open automatically issues to a JIRA board in case of failures.

@bcfriesen There is no difference in implementing binary or non binary notifications. All this information is available to the framework and this is what it reports. Adding notifications should be...

Hi @brandongc > I think we also want to make sure this is controllable, maybe via a CLI opt-in option like --notifications=on? I don't want to get spammed by people...