feat(core): Add setupJasmine test helper

[gribnoysup]

⚠️ This PR is WIP

This is a follow-up to the discussion in #116. I made some slight changes to the code compared to the initial implementation to make it closer to the code style of this repo, but other than that this is basically a port of what was implemented already in https://github.com/gribnoysup/setup-polly-jest

I wanted to open PR as soon as the initial implementation is there so you can see the progress, but there are a couple of things that I feel are needed before this can be considered done:

• implement setupJasmine helper method
• basic unit tests
• update examples that are using jest
• integration tests for jest
• integration tests for jasmine (?)
• documentation

If you feel that something on that list is unnecessary or should be done separately, please let me know 😸

Sorry for the delay with PR, running tests locally wasn't working properly for me at first so it was hard to test the implementation 😅

Closes #116

[gribnoysup]

Not quite sure why the tests are failing... 🤔

[offirgolan]

Im not sure what the exact purpose of this symbol is since its always being enabled at the start of the module and disabled at the end.

[gribnoysup]

This is because of the execution order of the tests. Jasmine (and jest-jasmine2 fork) calls all describe and it methods before runnings specs, so all it calls are using our proxied it method if setupJasmine was used in the file. This behaviour requires us to somehow tell proxied method should they create new Polly instance or not.

Consider a test case like this:

describe('describe one', () => {
  setupPolly({/* Defaults */});

  it('test one', () => {
    expect(fetch('/post/1').id).toBe(1);
  });
});

describe('describe two', () => {
  setupPolly({/* Custom options */});

  it('test two', () => {
    expect(fetch('/post/2').statusCode).toBe(404);
  });
});

describe('describe three', () => {
  // Don't want to proxy this one

  it('test three', () => {
    expect(fetch('/post/3').id).toBe(3);
  });
});

When jasmine runner executes this file, the order of things will be something like this:

• "describe one" callback is called, proxied methods are not attached yet, they will be attached, before/after hooks are added

• "test one" was called with proxied it method

• "describe two" callback is called, proxied methods are already attached, before/after hooks are added

• "test two" was called with proxied it method

• "describe three" callback is called, there is no setupJasmine, but Polly is still attached as there are no ways to figure out when to detach it at this point

• "test three" was called with proxied it method

Now the execution of the suites starts.

• "describe one" beforeAll hook activates Polly with IS_POLLY_ACTIVE flag

• "test one" is executed with Polly

• "describe one" afterAll deactivates Polly

• same for "describe two"

• "describe three" doesn't have before/after hooks, so Polly stays inactive and is not attached during the test run

• "test three" runs with polly not activated

Hope this makes more sense now 😸

[offirgolan]

Whats the reason here to store the passed in default config?

[gribnoysup]

The same as in #118 (comment) but I spotted a bug while implementing integration tests 😅, so this will change a little. Instead of saving options in context when setupJasmine is called as it is right now, it should be applied in beforeAll, before the specs will start executing, otherwise I'm always creating Polly instance with the options from the latest setupJasmine call

[offirgolan]

Not quite sure why the tests are failing...

Hmmm I'll look more into this.

[jasonmit]

Has there been discussion around wrapping the jest API? It's more explicit and wouldn't involve mutating Jest objects (I think). i.e., const { describe, it, setupPolly } = require('@pollyjs/jest');

[gribnoysup]

Hi @jasonmit, thanks for the feedback! 😊

I didn't think about explicit exports for test running methods. There were several reasons I went with this approach:

• I was trying to make the API as close as possible to the Mocha QUnit approach, there are certain differences between those test runners and jest that lead me to proxying solution, this is explained in more details in the original issue: [RFC] setupPolly method for jest #116 (comment)
• When I started with proxying, I tried proxying jest methods directly, but this is much harder to achieve as there are just much more methods that you need to proxy: test, test.only, test.only.concurrent, test.only.each, test.each, test.concurrent.only and then the same for it, but underneath every method there was either jasmine.it or jasmine.fit running the test

I don't mind trying the explicit approach if the team behind polly wants it 👍 I guess you can close this PR in that case and we can go back to the discussion in #116

[jasonmit]

@gribnoysup We appreciate you working on this and definitely see the value in supporting Jasmine.

My concern is maintaining this in the way it extends the Jasmine API. I feel it's best to publish as a third-party package for now. Happy to help promote it in the docs.

[gribnoysup]

Totally get that concern 👍

Not sure where to fit that in the docs, but feel free to link to setup-polly-jest somewhere or point me to a place you feel is appropriate for that 😸

[offirgolan]

@gribnoysup we can add a new Jest/Jasmine page under Test Frameworks as well as update the examples to use setup-polly-jest. A PR is welcome or I can add it sometime this week 😄

[gribnoysup]

@offirgolan thanks! I think I'll have some time on the weekends, but if I'm not fast enough and you have some spare time, feel free to do it yourself 👍