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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Skipped describe block is run #10776

Closed
cdoublev opened this issue Nov 3, 2020 · 5 comments
Closed

Skipped describe block is run #10776

cdoublev opened this issue Nov 3, 2020 · 5 comments

Comments

@cdoublev
Copy link

cdoublev commented Nov 3, 2020

馃悰 Bug Report

To Reproduce

Steps to reproduce the behavior:

  • Run the tests below:
describe.skip('a', () => {
    console.log('run a')
    test('1', () => expect(0).toBe(0))
})

describe('b', () => {
    it('2', () => expect(0).toBe(0))
})

Expected behavior

Short version: I expect run a not be logged in output.

Long version:

In my real test cases, I initialize a variable above all tests in the describe block a. This variable is initialized by instantiating a class that ultimately runs a function for caching instances of another class.

This caching function is also involved in the test cases in the describe block b, and they are failing if the variable in the head of the describe block a is not removed.

I tested with several previous versions of Jest (as well as the current latest v26.6.2) and it seems that this behavior has always existed. I couldn't find an existing issue asking for the behavior I'm expecting. The current description in docs is:

You can use describe.skip if you do not want to run a particular describe block

If the behavior I'm expecting couldn't be implement, I think the current behavior should be explicited in the docs, at least.

Link to repl or repo (highly encouraged)

https://github.com/cdoublev/jest-issue

envinfo

  System:
    OS: Linux 4.19 Debian GNU/Linux 10 (buster) 10 (buster)
    CPU: (1) x64 Intel(R) Core(TM) i7-3612QM CPU @ 2.10GHz
    Memory: 1.05 GB / 1.95 GB
    Container: Yes
    Shell: 5.0.3 - /bin/bash
  Binaries:
    Node: 15.0.1 - /usr/bin/node
    npm: 7.0.3 - /usr/bin/npm
  Managers:
    Apt: 1.8.2.1 - /usr/bin/apt
    Composer: 2.0.1 - /usr/bin/composer
    RubyGems: 2.7.6.2 - /usr/bin/gem
  Utilities:
    Make: 4.2.1 - /usr/bin/make
    GCC: 8.3.0 - /usr/bin/gcc
    Git: 2.27.0 - /usr/bin/git
  IDEs:
    Nano: 3.2 - /usr/bin/nano
    Vim: 8.1 - /usr/bin/vim
  Languages:
    Bash: 5.0.3 - /usr/bin/bash
    Perl: 5.28.1 - /usr/bin/perl
    PHP: 7.3.19 - /usr/bin/php
    Python: 2.7.16 - /usr/bin/python
    Python3: 3.7.3 - /usr/bin/python3
    Ruby: 2.5.5 - /usr/bin/ruby
  Databases:
    MySQL: 10.3.25 (MariaDB) - /usr/bin/mysql
@SimenB
Copy link
Member

SimenB commented Nov 3, 2020

Yeah, wording is imprecise - we will run the describe (so we can say test named a 1 is skipped), but we won't run any tests inside of it. If you have some setup that should be skipped within the describe, but it in beforeAll or beforeEach within the describe block.

Happy to take a PR specifying this in the docs 馃憤

@cdoublev
Copy link
Author

cdoublev commented Nov 3, 2020

Done. But I signed the CLA after my (first) PR, sorry. I'm still wondering why a describe.skip block needs to be run.

@cdoublev cdoublev closed this as completed Nov 3, 2020
@SimenB
Copy link
Member

SimenB commented Nov 3, 2020

I'm still wondering why a describe.skip block needs to be run.

See

we can say test named a 1 is skipped

Essentially, we run all describes and execute their callback (recursively), and collect all tests defined within them. But if skipped, we don't execute the test's callback

@cdoublev
Copy link
Author

cdoublev commented Nov 3, 2020

Oups, got it, thank you.

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants