salsify / ember-cli-pact Goto Github PK

Minimally, unit test coverage request dispatching and pact verification

Hi @dfreeman,

So as I mentioned in Slack yesterday, my team and I are trying to integrate ember-cli-pact with our repo, which uses a RestSerializer, and have come across the error "`Invalid attempt to destructure non-iterable instance."

After downloading your repo and ensuring all tests were passing, I was then able to reproduce the error in your repo by changing the mirage application.js file to the following:

import { RestSerializer } from 'ember-cli-mirage';
import { PactEnabled } from 'ember-cli-pact/mock-provider/mirage';

export default class ApplicationSerializer extends PactEnabled(RestSerializer) {

}

If you're able to offer any insight that would be awesome. Thanks in advance!

I wanted to log the issue here for visibility, as this appears to be an issue with Ruby's pact-support Gem, but it might be good for folks here to know that the pact files that ember-cli-pact generates are currently incompatible with pact verification on Ruby systems if they are using the official pact-support Gem.

pact-foundation/pact-support#62

Hi there,

I'm evaluating ember-cli-pact for the organisation I work for. I've previously worked with:

https://github.com/pact-foundation/pact-js

These guys are based in Melbourne but I was wondering if you had come across them? And perhaps more importantly for us, if you had plans to integrate some of their work into ember-cli-pact? Would also be keen to hear what your plans are for ember-cli-pact - is it just a proof of concept or will you be extending and enhancing it?

Sorry, not so much of an 'issue' but would be keen to hear more.

Fraser

The addon-test-support/ tree automatically gets added to the test-support.js asset (as opposed to vendor.js). By default, these assets are transpiled to <addon-name>/test-support, but you can easily modify that to remove the /test-support suffix if the addon is "test only" (see ember-test-helpers for an example).

The following should be supportable when the host app has [email protected] or higher:

import { module, test } from 'qunit';
import { setupTest } from 'ember-qunit';
import { setupPact } from 'ember-cli-pact';

module('stuff', function(hooks) {
  setupTest(hooks);
  setupPact(hooks, {
    provider: 'my-api',
    consumer: 'my-app'
  });

  test('locating a person by ID', async function(assert) {
    this.given('a person exists', { id: '123', name: 'Alice' });

    let person = await this.interaction(() => this.store().findRecord('person', '123'));

    assert.equal(person.get('id'), '123');
    assert.equal(person.get('name'), 'Alice');
  });
});

I believe that this change should reduce fairly significantly the amount of custom glue code that is present today...

Need coverage for:

• provider state management
• explicit interaction config
• captured request/response cycles
• Mirage integration
• QUnit and Mocha integration

Hi, @dfreeman – I'm hoping we can get a new release of Ember-cli-pact out. The last release was on October 19th, and the last PR I submitted was on the 22nd of October. I've been running builds against my own github fork since then but would prefer to be building against mainline ember-pact-cli if possible? Thanks! 😄

Hi,

We are trying to create a delete request using ember-pact-cli and mirage using the following steps:
`
let model = server.create('model', {
name: 'some model'
});

given('a model item exists', model);

let actualModel = await this.store().findRecord('model', 1);

actualModel.deleteRecord();

await interaction(function() {
actualModel.save();
});`

OR

`
let model = server.create('model', {
name: 'some model'
});

given('a model item exists', model);

let actualModel = await this.store().findRecord('model', 1);

await interaction(function() {
actualModel.destroyRecord();
});`

Everytime I run the ember tests to generate the pact file, I am getting the following error:
cannot read property 'method' of null

I've cloned this repo and added a delete test on the examples here and the same error is being thrown as well.

I was wondering if this is the correct way of creating a DELETE request or wether this could be a bug or not.

Thanks in advance.

ember-cli-pact has nested dependency decompress/4.2.0 with a security vulnerability: https://nvd.nist.gov/vuln/detail/CVE-2020-12265. This is from a direct dependency on pact-node^8.4.0. The newest version of pact-node does not have this vulnerability. Would it be possible to update the dependency to a version of pact-node that removes the vulnerability?

Hello, sorry if this is a user-error question, but I cannot seem to figure out why it is that I have camelized model-names, but when doing pact-testing, I am getting errors because pact/mirage is searching for dasherized names.

My test looks like this:

module('Pact | certificates', function(hooks) {
  setupTest(hooks)
  setupPact(hooks, { provider: 'my-api', consumer: 'my-app' })

  test('tls/certificates endpoint', async function(assert) {
    given('the customer exists')
    given('a generic certificate exists')
    const query = {filter: {'customer.id': '123456'}}
    const tlsCertificates = await interaction(() => this.store().query('tls-certificate', query))
    assert.equal(tlsCertificates[0].get('id'), '123456')
  })
})

However, in mock-provider/mirage.js, ember-cli-pact is looking for this.schema.modelFor(resource.modelName). Unfortunately, the resource.modelName value is dasherized here (i.e. tls-certificate), and all of the models in the schema are camelcased (i.e. tlsCertificate).

Using camelized model names in the test does not have any affect, and all production code uses this.store.query('tls-certificate') just fine. Does anyone have any thoughts as to how I can get ember-cli-pact to cooperate with my camelized models or how to change all my models within mirage to be dasherized if that's the only way to go?

We need a bunch of contextual information that should probably be defaulted in environment.js and overridable on a per-module basis:

• consumer name (effectively constant, since the project is the consumer)
• provider name (may be constant, may vary widely from test to test)
• where to look for provider state definitions
• what mock provider to use (Mirage out of the box, but would be totally reasonable to support raw Pretender or pact-web)
• where to persist pact files

Hi,

I don't really understand how to configure the matching rules to check all the items of an array.

Let's say for example that we are fetching a list of articles, each with a title. How can we configure it to have a resulting $.data[*].attributes.title ?

According to the doc I may use arrayElements(matcher) but I don't find out how to 😊 . I tried :

    specifyMatchingRules({
      response: {
        body: {
          data: {
            attributes: {
              title: arrayElements[type()],
            }
          }
        }
      }
    })

What is the default behavior? Persist or verify?

There's some interesting work to be done in terms of combining:

• observed request/response data
• generated match rules from the provider (e.g. from Mirage model metadata)
• explicit request/response expectations provided with the interaction