web-dev-qa-db-fra.com

Meilleure façon de tester les promesses à Jest

À moins que je ne comprenne quelque chose, les résolutions et les refus ( https://facebook.github.io/jest/docs/expect.html#resolves ) ne seront pas disponibles avant vNext. Quelle est la méthode recommandée maintenant/dans l'intervalle pour tester les promesses avec Jest? Est-ce simplement mettre des attentes dans les thens et les captures?

Par exemple:

describe('Fetching', () => {
    const filters = {
        startDate: '2015-09-01'
    };
    const api = new TestApiTransport();

    it('should reject if no startdate is given', () => {
        MyService.fetch().catch(e => expect(e).toBeTruthy()); // see rejects/resolves in v20+
    });            

    it('should return expected data', () => {
        MyService.fetch(filters, null, api).then(serviceObjects => {
            expect(serviceObjects).toHaveLength(2);
        }).catch(e => console.log(e));
    });            
});

MISE À JOUR 15 juin 2019 : Peu de temps après avoir posté cette question, Jest a commencé à prendre cela en charge. J'ai modifié la réponse acceptée ci-dessous pour refléter la meilleure façon de procéder actuellement.

javascriptjestjs
12
Ambrose Little

De nos jours, vous pouvez également l'écrire de cette façon: docs

describe('Fetching', () => {
    const filters = {
        startDate: '2015-09-01'
    };
    const api = new TestApiTransport(); 

 it('should reject if no startdate is given', () => {
   expect.assertions(1);
   return expect(MyService.fetch()).rejects.toEqual({
     error: 'Your code message',
   });
 });          


 it('should return expected data', () => {
   expect.assertions(1);
   return expect(MyService.fetch(filters, null, api)).resolves.toEqual(extectedObjectFromApi);
 });            
});

Mise à jour (06.01.2019)

Acceptez que la réponse acceptée ne fonctionne pas correctement car la ligne expect.assertions(1); fait toute la magie. Lien vers les documents

expect.assertions (number) vérifie qu'un certain nombre d'assertions sont appelées lors d'un test. Ceci est souvent utile lors du test de code asynchrone, afin de s'assurer que les assertions d'un rappel sont effectivement appelées.

Donc, mettre cette ligne en haut contrôlera que le nombre spécifique d'assertions est fait au moment où le test est exécuté.

15
Yevhenii Herasymchuk

Soit renvoyer une promesse et attendre dans le resolve ou catch

describe('Fetching', () = > {
  const filters = {
    startDate: '2015-09-01'
  };
  const api = new TestApiTransport();
  it('should reject if no startdate is given', () = > {
    return MyService.fetch()
      .catch (e => expect(e).toBeTruthy()); // see rejects/resolves in v20+
  });
  it('should return expected data', () = > {
    return MyService.fetch(filters, null, api)
      .then(serviceObjects => {
        expect(serviceObjects).toHaveLength(2);
      })
  });
});

ou en utilisant async/await

describe('Fetching', () = > {
  const filters = {
    startDate: '2015-09-01'
  };
  const api = new TestApiTransport();
  it('should reject if no startdate is given', async() = > {
    try {
      const r = await MyService.fetch()
    } catch (e) {
      expect(e).toBeTruthy()
    }
  });
  it('should return expected data', async() = > {
    const serviceObjects = await MyService.fetch(filters, null, api)
    expect(serviceObjects).toHaveLength(2);
  });
});
12
Andreas Köberle

J'ai pu tester JEST avec AXIOS pour HTTP REST appels comme celui-ci.

it('has an API worth testing', async () => {
  let httpResult = null;
  await callThefunctionThatReturnsPromiseToMakeTheAxiosApiCall()
    .then(function(result) {httpResult=result;})
    .catch(function(err) {httpResult=err;});
  expect(httpResult.data.myData).toBe("myExpectedValue");
});

ou

it('has an API worth testing', async () => {
  let httpResult = await callThefunctionThatReturnsPromiseToMakeTheAxiosApiCall();
  expect(httpResult.data.myData).toBe("myExpectedValue");
});
0
Sagan