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

Ability to skip rest test cases if one fails #8387

Open
vilicvane opened this issue Apr 27, 2019 · 17 comments
Open

Ability to skip rest test cases if one fails #8387

vilicvane opened this issue Apr 27, 2019 · 17 comments

Comments

@vilicvane
Copy link

vilicvane commented Apr 27, 2019

🚀 Feature Proposal

Provide ability to skip rest test cases in a file or describe block if one test fails.

Motivation

For E2E testing, the test cases are usually written to be run sequentially, and a failed test should stop the rest from running.

Example

test('should login', async () => {});

test('should edit profile', async () => {});

test('should render profile', async () => {});

Or with describes:

describe('#1', () => {
  test('should login', async () => {});

  describe('#1.1', () => {
    test('should edit profile', async () => {});

    test('should render profile', async () => {});
  });
});
@Mouvedia
Copy link

keyword: step
prior art: https://github.com/rprieto/mocha-steps

@jeysal
Copy link
Contributor

jeysal commented Apr 27, 2019

Duplicate of #6527 (for hooks and tests)

@jeysal jeysal closed this as completed Apr 27, 2019
@Mouvedia
Copy link

No it's not a duplicate. We are requesting mocha-steps not jasmine-fail-fast.

TL;DR: skip (and auto fail) the following steps after the first failing step within the current describe (not exit on first failure)

@jeysal please reopen.

@jeysal
Copy link
Contributor

jeysal commented Apr 27, 2019

Okay then, we can keep this open to track fail-fast within a describe block (although the OP does not explicitly request this).
I think it's unlikely that this goes into Jest core though, while #6527 might as it's a logical extension of bail.

@jeysal jeysal reopened this Apr 27, 2019
@G-Rath
Copy link
Contributor

G-Rath commented Apr 29, 2019

Personally I think this makes sense, and would love to see it in the jest core under step, as it lets you break tests into smaller parts (allowing you to describe them better, since they each have an it/step message), and increase performance for when you're testing something that is dependent on prior tests.

Take for example this test:

describe('.root', () => {
  it('contains the root package.json', () => {
    // eslint-disable-next-line @typescript-eslint/no-require-imports
    const requirePackageJson = () => require(path.join(pathTo.root, 'package.json'));

    expect(() => requirePackageJson()).not.toThrow();
    expect(requirePackageJson()).toStrictEqual(packageJson);
  });
});

It's checking that pathTo.root points to a directory with a package.json, and that the package.json is the actual root package.json (by comparing the object returned by the require to one imported via the normal module loader).

Since require throws an error if it can't find the file (the first expect), it makes no sense to test contents of the file (the second expect) if this happens.

But, since its are independent of each other, I either will have two tests failing (which while technically correct means I've got pointless noise that adds nothing to the situation), or one "big" it that combines two tests.

Meanwhile, if we had step:

describe('.root', () => {
  // eslint-disable-next-line @typescript-eslint/no-require-imports
  const requirePackageJson = () => require(path.join(pathTo.root, 'package.json'));

  step('has the root package.json', () => {
    expect(() => requirePackageJson()).not.toThrow();
  });
  step('contains the root package.json', () => {
    expect(requirePackageJson()).toStrictEqual(packageJson);
  });
});

This maybe be a result of me being relatively new to the testing game, but it seems to me that step would empower jest further, as it enables you to do feature-like testing letting you nicely test apps as a whole.

I know that step is pretty self explanatory in its advantages, I felt like it could be valuable to put one to paper - I've got a lot of tests that are similar to that.

I don't mind step not being in the jest core, just so long it's as easy to use as it, describe, #each, etc are today.

I'm just really excited at the idea of having this feature in jest, as I've come across this problem a lot! 😄

@cinderblock
Copy link

Smoke tests in front of more substantial tests save people time. Without the ability to short circuit subsequent test, the time saving is mitigated.

Where does this functionality need to be added? Would this live in a test runner or is this a jest issue? (Many people don't even realize the distinction between jest and test runners...)

@k1832
Copy link

k1832 commented Feb 25, 2020

Here is my temporary solution.

describe("test", () => {
  let skipOther = false
  test("check something", async () => {
    try {
      await checkSomething()
    } catch(e) {
      skipOther = true
      throw new Error("error")
    }
  })

  test("might be skipped", async () => {
    if(skipOther) throw new Error("error occured in previous tests.")
    console.log("display this, if there is no error before this.")
  })
})

@MrLoh
Copy link

MrLoh commented May 1, 2020

I would be interested in implementing a test.step function in jest circus, I don't see a way to do this outside of the jest-circus core though, as it requires adding some flag to the state.

@MrLoh
Copy link

MrLoh commented May 1, 2020

I created a PR that implements asynchronously canceling tests as described in #8604. With that in place, one could implement this functionality through easy monkey patching in user land like this:

let prevFailed;
const _describe = global.describe;
global.describe = (...args) => {
  prevFailed = false;
  return _describe(...args);
};
global.test.step = (name, fn, ...args) => {
  test(name, async function(...fnArgs) {
    if (prevFailed) {
      return this.skip();
    }
    try {
      return await fn(...fnArgs);
    } catch (e) {
      prevFailed = true;
      throw e;
    }
  }, ...args);
};

@FezVrasta
Copy link

@MrLoh where's the PR? I only see the issue

@MrLoh
Copy link

MrLoh commented Sep 3, 2020

#9944 But I doubt it will ever be merged, I haven't heard back a single word from any contributor.

@davidglezz
Copy link

davidglezz commented Jan 14, 2021

My solution to skip rest tests after first failure #6527 (comment)
image

@ali-hellani
Copy link

Here is my solution #7245 to skip test programmatically and on run time after test began. the key is to call pending()

@rdeangelis83
Copy link

rdeangelis83 commented Oct 18, 2021

Playwright already provides a test.step https://playwright.dev/docs/api/class-test/#test-step
And this would also make sense for jest specially for e2e tests.

@Raaghu
Copy link

Raaghu commented Dec 1, 2021

I have created the Jest Environment for this usecase

https://www.npmjs.com/package/jest-environment-steps

@github-actions
Copy link

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

@github-actions github-actions bot added the Stale label Jun 20, 2023
@Mouvedia
Copy link

.

@github-actions github-actions bot removed the Stale label Jun 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests