Как проверить, была ли функция void async успешной с помощью jest? - PullRequest
1 голос
/ 19 марта 2019

Как вы можете лаконично проверить, успешно ли выполняется асинхронная функция void с помощью jest? Я использую TypeScript.

// foo.ts
export class Foo {
  public async bar(): Promise<void> {
    await someAsync();
  }
}

Как проверить, что new Foo().bar() не выдает ошибку?

Ответы [ 2 ]

2 голосов
/ 19 марта 2019

Это лучший способ, который я нашел.Надеюсь, есть что-то более элегантное.

describe("Foo.bar()", () => {
  it("should not throw", async () => {
    expect.assertions(1);

    try {
      await new Foo().bar();
      expect(true).toBeTruthy();
    } catch {
      // should not come here
    }
  });
});
0 голосов
/ 19 марта 2019

... альтернатива - resolves утверждение.

describe("Foo.bar()", () => {
  it("should not throw", () => {
      return expect(new Foo().bar()).resolves.toEqual();
  });
});

Здесь вы должны вернуть результат, так как это обещание (и заставить шутить ждать, пока оно не выполнится). Это немного более лаконично, если вам нужно просто проверить разрешение (или отклонено - есть аналогичная опора rejects для проверки значения отклонения).

Но если вам нужно выполнить несколько проверок после запуска функции, основанной на обещаниях, как

describe("Foo.bar()", () => {
  it("should not throw", () => {
      const promise = new Foo().bar()
      expect(promise).resolves.toEqual();
      expect(someMock).toHaveBeenCalled();
      return promise;
  });
});

вы можете найти вариант с async/await более ... удовлетворительным?

PS как для вас вариант

describe("Foo.bar()", () => {
  it("should not throw", async () => {
    expect.assertions(1);

    try {
      await new Foo().bar();
      expect(true).toBeTruthy();
    } catch {
      // should not come here
    }
  });
});

Я считаю, что нет необходимости отлавливать ошибку - поэтому expect.assertions также становится избыточным. Зачем? uncaught исключение провалит ваш тест, и оно не ожидается, исключение, поэтому это нормально, чтобы провалить его. такая структура понадобится, если вы ожидаете исключения и хотите проверить его свойства.

Также, если проверка не удалась, опция expect.assertions сообщит вам только о сбое, а необработанное исключение выделит конкретный оператор (полезно, если в тесте есть несколько операторов, исключающих возможные исключения)

[UPD] также я пропустил начальную точку, что вам нужно проверить, разрешено ли обещание с любым результатом (моя версия проверяет, что оно разрешается с undefined, что не очень хороший ход (это не разрушает) что-нибудь, если функция начинает возвращать что-то , если она возвратила ничего раньше). Между тем мы должны иметь хотя бы одну проверку в тесте ...

Так что, возможно, ваш подход с заглушкой expect(true) здесь такой же законный.

Но я бы дважды проверил, если вы не хотите делать больше expect в том же тесте. это тестируемое утверждение действительно такое изолированное? или вы просто разбираете связанные чеки на отдельные it()?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...