Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Unite 2023 Registrations are now LIVE! We are thrilled to announce that Unite 2023 Registration is now live and open for all!
    Dismiss Notice
New Forum User Notice Unite 2023 Registrations are now LIVE!

Bug Code coverage showing unreached code that is actually reached

Discussion in 'Testing & Automation' started by AdamBebko, Mar 10, 2022.

  1. AdamBebko

    AdamBebko

    Joined:
    Apr 8, 2016
    Posts:
    161
    Screen Shot 2022-03-10 at 1.29.11 PM.png

    Note the closing brackets are marked as uncovered, when they are clearly covered if the lambda is called. There is no way that's not covered.
     
    AdamBebko, Mar 10, 2022
    #1

  2. sbergen

    sbergen

    Joined:
    Jan 12, 2015
    Posts:
    49
    sbergen, Mar 11, 2022
    #2

  3. JuliusJ

    JuliusJ

    QA Minion of the month Unity Technologies

    Joined:
    May 20, 2015
    Posts:
    33
    This happens because statement lambda is never fully executed as StartPlaying throws an exception (even if there's only one method call).
    Here's an illustration of what's happening. When thrower() throws an exception, Debug.Log and everything that could come after is not executed.
    Screenshot 2022-03-11 at 10.17.30.png

    If you want to get full coverage of your test, you could rewrite your test to use expression lambda by removing curly brackets. Then it will always be fully executed.
    Screenshot 2022-03-11 at 10.50.12.png

    Finally, we have a bug report for this behaviour. You can find it here https://issuetracker.unity3d.com/is...n-line-is-just-brackets-in-a-covered-function. At the very least, we'll add a section to our documentation explaining this behaviour.
     
    JuliusJ, Mar 11, 2022
    #3

  4. AdamBebko

    AdamBebko

    Joined:
    Apr 8, 2016
    Posts:
    161
    What you are saying makes perfect sense for why it's not covered. But is very counter intuitive from a user perspective, couldn't you have a simple rule where any lines with just closing brackets are covered by default?

    In your example, the fact that the debug log is not covered makes perfect sense. that's useful info. But the line after with the closing brackets is fudging the coverage numbers.
     
    AdamBebko, Mar 11, 2022
    #4

  5. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,614
    It may be counterintuitive, but I think the current behaviour is correct - it is rightly showing you that there is an unexercised path in your code - the path from "successful return from StartPlaying -> end of the code block".

    Now, given that you expect the called function to always throw, that unexercised path does not matter to you - but I don't think it is a good idea for the tooling to make assumptions like that on everyone's behalf, not least because I don't see how it could tell the difference between "I'm expecting this method that I'm calling to always throw" and "I'm expecting it to sometimes throw and sometimes not" in a mechanical way.
     
    superpig, Mar 12, 2022
    #5

  6. AdamBebko

    AdamBebko

    Joined:
    Apr 8, 2016
    Posts:
    161
    I can't imagine a case where a developer would care that closing brackets are not reached when running code coverage tools. Sure, a line of code, but not closing brackets. It just ruins that sweet sweet green 100% in my opinion. But agree to disagree I suppose.
     
    AdamBebko, Mar 15, 2022
    #6
    sgt3v likes this.