Global before() and after() hooks are executed multiple times when running tests with Command Line but only one time when running tests with Test Runner

[TomaszG]

Current behavior:

If user defines global before() or after() hook in the support file (support/index.js) then the hook is executed only one time when running all tests with the Test Runner (npx cypress open => Run all specs button).

However if we run the same code with CLI (npx cypress run) then the global hooks are executed for each .spec file in the suite.

Desired behavior:

Global before() and after() hooks should be run only once per test run.

Steps to reproduce: (app code and test code)

1. Define global hooks in support/index.js

// support/index.js

(...)

before(() => {
  cy.log('Global Before Hook');
});

after(() => {
  cy.log('Global After Hook');
});

2. Add multiple spec files
3. Run all tests with CLI - npx cypress run
4. Run all tests with Test Runner - npx cypress open => Run all specs button
5. Check in logs/videos how many times global hooks were executed.

Versions

Cypress 3.4.1

[jennifer-shehane]

The 'Run all specs' doesn't reflect how the tests are run during cypress run. There is an issue open to change this behavior. #1586 So going to close this as duplicate.

The intended behavior is to close and reopen the browser in between each spec file, so the before and after hooks would run once before and after each spec file is run. So the 'Run all specs' button will be changed to reflect this behavior also.

[jprealini]

@jennifer-shehane I am still trying to find a way to solve workaround this. I opened the feature request #29432 a couple of weeks ago.

One thing I can´t completely understand is why does Cypress run what is supposed to be a global before and after hook (from the support file) actually before and after every spec.... Doesn't each spec have its own "before" and "after" hooks for that?

I would expect, by logic, that the hooks would work something like this:

Support file "before" hook - RUN ONCE AT THE BEGINNING OF THE TEST RUN
Support file "beforeEach" hook - RUN BEFORE EACH SPEC (in case there is some common logic you need to run before every spec ... This is what the global before does now)
Support file "afterEach" hook - RUN AFTER EACH SPEC
Support file "after" hook - RUN ONCE AT THE END OF THE TEST RUN

And this would simplify a lot scenarios where one has to run custom commands to setup data (call apis to populate databases with test data or similar)

Do you think this could be possible to implement?

Thanks

[jennifer-shehane]

@jprealini If you're running specs in parallel machines, would we run the before spec one time? On which machine? Would the other machines get the effect of that before run?

[jprealini]

@jennifer-shehane hmm... I guess you have a point there. I didn´t think about that. I was following up on some threads about this same feature requested a few years ago, and I see the before:run after:run events where added to solve this. The caveat here is that if we have some logic that needs to run inside the before:run but which has heavy dependency on Cypress, then we can't run it and we need to refactor/redesign our code to NOT use any cypress commands to be able to run it inside the before:run event...
It would be great to have the chance to make use of cypress (custom commands, cy.request, etc) as part of a "real global before" hook...
In my particular case, I need to hit an api to create test users/customers with a lot of test data, configurations, etc... The whole process consumes about 3 minutes. It's a piece of cake to use cy.request to hit that api.... The only option I have if I want to run that only once and use those customers/users across the whole test run, is using a third party library like Axios or whatever and redo all my code....
Hope that explains the insistence... 😄 In the feature request I created you said this: "I'm not sure if we could hook into this once a spec has begun, so that you could run Cypress tests.... it would require quite a bit of rework anyway" #29432 (comment)

Do you think there is a remote possibility that this could be achieved sooner or later?

Thanks

[jennifer-shehane]

@jprealini It's not currently something that we're looking at unfortunately.