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
Coveragepy 5 now supports coverage provenance in a "who-tests-what" feature. Currently this information is reported on but there's currently no easy way to provide assertions on the information
I'd like to be able to mark modules and classes with @pytest.mark.covers('path.to.some.sut', fail_under=...)
And have them a test suite fail if the coverage by the items contained in the node hierarchy are not sufficient to cover 'path.to.some.sut'
Design
Scope Grouping
The scope of the mark effects the grouping of the coverage assertion:
testing.ham.spam.selenium.test_baz, testing.ham.spam.selenium.TestEggs.test_foo and testing.ham.spam.selenium.TestEggs.test_bar should cover "ham.spam" completely on their own
testing.ham.spam.selenium.TestEggs.test_foo and testing.ham.spam.seleniumTestEggs.test_bar should cover ham.spam.eggs completely on their own - regardless of if testing.ham.spam.selenium.test_baz
happens to cover any of "ham.spam.eggs" or any other test in the suite happens to do so.
A new file
adding a new file, should not weaken any of the above coverage assertions:
In addition: testing.ham.spam.unit.test_baz, testing.ham.spam.selenium.unit.test_foo and testing.ham.spam.unit.TestEggs.test_bar should cover "ham.spam" completely on their own
testing.ham.spam.unit.TestEggs.test_foo and testing.ham.spam.unit.test_bar should cover ham.spam.eggs completely on their own - regardless of if testing.ham.spam.unit.test_baz or any other test in the suite
happens to cover any of "ham.spam.eggs"
Grouping override
an groupe kwarg allows you to explicitly weaken the coverage assertion:
would it be better to disable scope-grouping entirely, and require a group kwarg?
this could result in spooky-action-at-a-distance in which adding testing.ham.spam.unit to a suite implicitly weakens testing.ham.spam.selenium
The text was updated successfully, but these errors were encountered:
Coveragepy 5 now supports coverage provenance in a "who-tests-what" feature. Currently this information is reported on but there's currently no easy way to provide assertions on the information
I'd like to be able to mark modules and classes with
@pytest.mark.covers('path.to.some.sut', fail_under=...)
And have them a test suite fail if the coverage by the items contained in the node hierarchy are not sufficient to cover
'path.to.some.sut'
Design
Scope Grouping
The scope of the mark effects the grouping of the coverage assertion:
testing.ham.spam.selenium.test_baz
,testing.ham.spam.selenium.TestEggs.test_foo
andtesting.ham.spam.selenium.TestEggs.test_bar
should cover "ham.spam" completely on their owntesting.ham.spam.selenium.TestEggs.test_foo
andtesting.ham.spam.seleniumTestEggs.test_bar
should coverham.spam.eggs
completely on their own - regardless of iftesting.ham.spam.selenium.test_baz
happens to cover any of "ham.spam.eggs" or any other test in the suite happens to do so.
A new file
adding a new file, should not weaken any of the above coverage assertions:
In addition:
testing.ham.spam.unit.test_baz
,testing.ham.spam.selenium.unit.test_foo
andtesting.ham.spam.unit.TestEggs.test_bar
should cover "ham.spam" completely on their owntesting.ham.spam.unit.TestEggs.test_foo
andtesting.ham.spam.unit.test_bar
should coverham.spam.eggs
completely on their own - regardless of iftesting.ham.spam.unit.test_baz
or any other test in the suitehappens to cover any of "ham.spam.eggs"
Grouping override
an groupe kwarg allows you to explicitly weaken the coverage assertion:
Problems
I'm not particularly happy with my design for explicit grouping. Would sentinel objects be better?
can mark instances themselves be a sentinel by default?
would it be better to disable scope-grouping entirely, and require a group kwarg?
this could result in spooky-action-at-a-distance in which adding testing.ham.spam.unit to a suite implicitly weakens testing.ham.spam.selenium
The text was updated successfully, but these errors were encountered: