Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Istanbul Coverage + Svelte: Incorrectly Identifying an If / Else Block #1893

Closed
6 tasks done
kgladfelder opened this issue Aug 21, 2022 · 3 comments
Closed
6 tasks done
Labels
feat: coverage Issues and PRs related to the coverage feature upstream

Comments

@kgladfelder
Copy link

Describe the bug

In a svelte.kit application, while outputting data in an each block, any time the iterator is accessed, Istanbul is reporting that I never go into an if block that doesn't exist. Also, in the coverage report it shows line 97 as partially covered and the HTML shows it as fully covered.

image

image

Reproduction

https://github.com/kgladfelder/vitest-issue-repro

System Info

System:
    OS: Windows 10 10.0.22000
    CPU: (16) x64 Intel(R) Core(TM) i7-10875H CPU @ 2.30GHz
    Memory: 7.88 GB / 15.86 GB
  npmPackages:
    vite: ^3.0.7 => 3.0.7
    vitest: ^0.22.0 => 0.22.0

Used Package Manager

npm

Validations

@sheremet-va sheremet-va added the feat: coverage Issues and PRs related to the coverage feature label Aug 22, 2022
@AriPerkkio
Copy link
Member

I don't think there is anything we can do on Vitest's codebase. Changes in Svelte compiler could fix this.

Looking at @kgladfelder's repro we can see that Svelte compiler is adding helper-functions which end up getting instrumented. I think these helper functions are included in source maps so that debugging tools can stop on breakpoints. But when instrumenting code, we end up collecting coverage from these unnecessary if-blocks. When the transpiled code is mapped back to sources, we can see covered and uncovered lines on unexpected lines+columns.

This is why }</span> is seen in coverage report as uncovered:

Look at these lines+columns in sources:

12 |   <span>{result.gameName}</span>
                              ^^^^^

In the transpiled code those map into this single character here:

225 |   if (dirty & /*searchResults*/ 1 && t0$_value$ !== (t0$_value$ = /*result*/ ctx[2].gameName + "")) set_data_dev$(t0$, t0$_value$);
                                                                                                 ^

Now looking at the instrumented transpiled code. A branch counter is added here. When code is executed it is never reached.
This will mark those original lines in source code as uncovered.

4980 |      if ((cov_1a56qtdo1c().b[7][0]++, dirty &
4981 |      /*searchResults*/
4982 |      1) && (cov_1a56qtdo1c().b[7][1]++, t0$_value$ !== (t0$_value$ =
4983 |      /*result*/
4984 |      ctx[2].gameName + ""))) {
4985 |        cov_1a56qtdo1c().b[6][0]++;
     |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Branch counter!
4986 |        cov_1a56qtdo1c().s[92]++;
4987 |        set_data_dev$(t0$, t0$_value$);
4988 |      } else {

In the same repro repo there are also some 100% correctly working source maps. Here is one example:

16 |  {#if !searched}
            ^^^^^^^^
17 |   <h6>Please search for a game.</h6>
18 |  {:else}
44 | if (!/*searched*/ ctx[1]) return create_if_block$;
                       ^^^
4672 |    if (!
4673 |    /*searched*/
4674 |    ctx[1]) {
4675 |      cov_1a56qtdo1c().b[0][0]++;
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Branch counter!
4676 |      cov_1a56qtdo1c().s[6]++;
4677 |      return create_if_block$;
4678 |    } else {

I'm 99% sure I've seen some code transformer tool adding /* istanbul ignore */ comments around their helper functions. I think it was in Babel's codebase but can't find it anymore.

A possible solution here would be if Svelte compiler excluded its helper functions from instrumenters.

@AriPerkkio
Copy link
Member

Upstream issue open sveltejs/svelte#7824.

@AriPerkkio
Copy link
Member

This is fixed on Svelte 5.

@github-actions github-actions bot locked and limited conversation to collaborators Apr 22, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feat: coverage Issues and PRs related to the coverage feature upstream
Projects
None yet
Development

No branches or pull requests

3 participants