How to identify which lines are covered but not actually tested using Jest Coverage

Whenever a line is executed by a test, it'll be considered as covered.

But in your test, it can happen that there is no assertion regarding this line.

Let's take a really simplified React component:

function BasicComponent() {
  return <div>
    <h1>Hello there</h1>
    <p>This is a basic component</p>
  </div>;
}

Now, if I write a simple test using Jest and React-Testing-Library:

import { render, screen } from '@testing-library/react';

describe('<BasicComponent />', () => {
  it('should render correctly', () => {
    render(<BasicComponent />);

    expect(screen.getByText('Hello there')).toBeInTheDocument();
  });
});

This test will render the BasicComponent, executing every lines of it.

But if you take a closer look at the test, you'll notice that we never assert for the text This is a basic component to be in the document.

It's not tested, however the code coverage will still be 100%.

I wanted to know if there was a way to find which lines are covered but not actually tested?

> I wanted to know if there was a way to find which lines are covered but not actually tested?

I do not believe so out of the box.

The way Jest and most test coverage tools work is by tracking which lines of code get executed during the test run, not necessarily which lines of code get "tested" in the sense of being included in an assertion.

All you can try (using a code coverage tool alone) is followed best practices, like the ones mentioned in "11 Jest Best Practices to Get the Most Out of Your Tests", from Ferenc Almasi.

But you can also combine a code coverage too with mutation testing, using a framework like Stryker Mutator: it will deliberately introduce small bugs ("mutations") into your code and running your tests to see if they catch the bugs. If a line of code can be changed without causing any test to fail, that is a sign that line is not adequately tested.

That would help detect your missed assertion for the text This is a basic component to be in the document.

With Stryker, a "mutant" is a piece of code in your application that has been changed in one small way, and if your tests still pass with that change, then Stryker would identify that as a 'surviving mutant'.

When applied to a React component, Stryker will make a variety of changes to the component's code and rerun your tests to see if they still pass.
For example, it could change the string 'That is a basic component' to 'That is not a basic component' or delete the line of code that renders that text.
If your tests still pass with these changes, Stryker will report that your component has surviving mutants and indicate the specific mutations that survived.

Since your test would still pass even when the text is changed ("mutated"), you will know that the test is "incomplete" (missing assertion).

However, Limon Monte points out in the comments to stryker-mutator/stryker-js issue 4375: "Possibility to mutate string nodes in JSX/TSX"

Skyler can sometimes incorrectly identify lines of code as uncovered when they are actually covered by tests.
This is because it uses a static analysis approach to identify uncovered lines of code, and this approach can sometimes be inaccurate.

However, the issue with Skyler is not a reason to not use it. It is still a valuable tool for identifying uncovered lines of code, and the issue with incorrect identification is relatively rare.

Note, The issue with Skyler:

• is not specific to Jest. It can incorrectly identify uncovered lines of code in any project that uses Jest.
• is not a security vulnerability. The issue does not affect the correctness of the code, it just affects the accuracy of the Skyler report.
• is being tracked by the Stryker team. The team is working on a fix for the issue, but there is no ETA for the fix yet.