Opened 3 years ago
Last modified 3 years ago
#42045 new defect (bug)
@expectedIncorrectUsage annotation fails under specific scenerio
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | Build/Test Tools | Keywords: | close |
Focuses: | Cc: |
Description
Suppose if there is test case(the function with @expectedIncorrectUsage annotation above it) with two functions where one of the function doesn't make any call to _doing_it_wrong
whereas other function makes more than one call to _doing_it_wrong
.
as The expected result is
FAILURES! Tests: 1, Assertions: 2, Failures: 1.
But it returns
OK (1 test, 2 assertions)
The @expectedIncorrectUsage should check if each function has made a call to the _doing_it_wrong
instead of checking the number of time _doing_it_wrong
was called in a test case and mapping it to the number of assertion
Earlier Reported Case
:
https://core.trac.wordpress.org/ticket/42040#comment:7
Change History (3)
#2
@
3 years ago
@swissspidy yes one test case per assertion will definitely solve this issue, but i still don't have a way to check if the call to _doing_it_wrong
was made from my part of snippet or not.
Also, I feel @expectedIncorrectUsage needs to be fixed as there is a chance that other developer will be able to write failed test cases and still make it look okay. Or if we can make one assetion per test as a testing standard in wordpess and scripts should be written to ensure that. But the later will involve most of the test already present to be broken down and re written to different test functions.
#3
@
3 years ago
- Keywords close added
This isn't really any different from PHPUnit's built-in expectedException
functionality. There's no way to assert exactly which part of the code threw the exception. The best way to tackle this is to write small, tightly focused tests to minimise the chance that the unexpected usage is triggered elsewhere.
My advice is usually to only write one assertion per test. When you have multiple assertions per test method it's just harder to debug and not very readable. If you'd do that in #42040, you don't run into this problem.
I don't think we should encourage having multiple assertions per test by "fixing" the
@expectedIncorrectUsage
annotation.