How to know if xdebug is right?

Question

I'm running some tests and some reports don't make sense for example:

I also have another example: Why xdebug marks 587 and 588 as not executed and 589 as executed?

Are you sure you have a test case that covers when `$op` is neither of the two? — Rarst, Feb 21 '19 at 15:11
I don't have because I test if value is `combinator` before. — Andrei Lupuleasa, Feb 21 '19 at 15:13

score 2 · Accepted Answer · answered Feb 21 '19 at 15:56

2

If you don't have a test where switch is non–matching then xdebug coverage is correct.

If execution is only ever returned from switch in tests then end of method (implicit void return) is never ever reached/executed and as such not covered.

You can be confident that at this time there is no problem here, but over time this is brittle. What if you add a third possibility, but forget to handle it? And so on.

Coverage does its job here — it points out a (potential) code path that isn’t being tested.

answered Feb 21 '19 at 15:56

Rarst

2,335
16
26

Can you explain this? https://stackoverflow.com/questions/54828254/why-xdebug-marks-lines-as-not-executed – Andrei Lupuleasa Feb 22 '19 at 13:33
Nope, that one does look strange. – Rarst Feb 22 '19 at 15:28
I've understood what happens. The line 586 has multiple conditions and not all cases are covered and for those cases that are not covered 587 and 588 are listed as not executed. It's the same issue even though it looks strange. – Andrei Lupuleasa Feb 25 '19 at 13:37
The legend should be updated though because is confusing. – Andrei Lupuleasa Feb 25 '19 at 13:44

score 1 · Answer 2 · answered Feb 21 '19 at 15:58

1

By looking at the example you provided xdebug is actually "right", since the return statements are all inside the switch, you never get to the last line of that function.

Also there are options to allow "strict" coverage, to exclude code invoked recursively, so be careful you are not running some of these if it's not the behaviour you are expecting

answered Feb 21 '19 at 15:58

Riccardo Cedrola

1,270
1
10
16

So if code is executed recursively I have to coverage all conditions on every recursion? – Andrei Lupuleasa Feb 21 '19 at 16:07
1

Let me try to explain: if you have tests for the method `methodTested()` you will see that method as green in your xdebug report. If the `methodTested()` calls another method called like `methodNotTested()` you could expect the lines of this method to be red inside the xdebug report, but they are actually going to be green, because for xdebug the code has been run and since no errors where thrown, it is considered "safe". So a 100% coverage of a class/method is not itself a reason to consider the code bugproof – Riccardo Cedrola Feb 21 '19 at 16:10
1

My advice is always to use xdebug as a tool while covering the code, don't follow it religiously, don't hassle too much to get that 100% code coverage. Just cover the important stuff and use xdebug to ensure you covered each scenario – Riccardo Cedrola Feb 21 '19 at 16:15
What about when `methodTested()` recalls itself and on recursion not all case from inside of it are covered? – Andrei Lupuleasa Feb 21 '19 at 16:25
1

I can't give you a sure answer about that but my instinct says that the reports are going to be merged, so you will see everything green even if the recursion didn't cover all the scenarios. Btw if you ask me is not a problem, once you are sure that a method behaves as expected, you could also assure that on recursion it will work the same way. Don't know if this makes sense to you – Riccardo Cedrola Feb 21 '19 at 16:32
Can you explain this https://stackoverflow.com/questions/54828254/why-xdebug-marks-lines-as-not-executed ? – Andrei Lupuleasa Feb 22 '19 at 13:33

How to know if xdebug is right?

2 Answers2