Жасмин Асин c тестовое поколение - PullRequest
Новая
       9

Жасмин Асин c тестовое поколение

0 голосов
/ 20 апреля 2020

давайте представим, что у нас есть обещание, которое выполняет большое количество операций и возвращает вспомогательные функции. Банальный пример: 

const testPromise = testFn => () => {
    const helper = Promise.resolve({testHelper: () => 'an helper function'}) // I/O Promise that returns an helper for testing
    return helper.then(testFn).finally(() => console.log('tear down'));
}

// This describe would work as expected
describe('Async test approach', () => {
    it('A test', testPromise(async ({testHelper}) => {
        expect(testHelper()).toBe('an helper function')
    }))
})

// This part doesn't work

describe('Async describe approach', testPromise(async ({testHelper}) => {

    it('Test 1', () => {
        expect(testHelper()).toBe('an helper function')
    })

    it('Test 2', () => {
        expect(testHelper()).not.toBe('A chair')
    })
}))

}

Я хотел бы добиться чего-то вроде второго примера, где я могу использовать асин c код в описании без переоценки testPromise.

describe не обрабатывает asyn c, поэтому я даже не могу l oop и правильно создавать динамические c тесты.

Я прочитал много комментариев о том, что describe должен только быть простым способом группировки тестов, но ... тогда ... как кто-то может создавать асинхронные c сгенерированные тесты на основе результатов ввода / вывода?

Спасибо

= ДОПОЛНИТЕЛЬНОЕ РАССМОТРЕНИЕ =

Что касается комментариев, которые вы, ребята, любезно добавили, я должен был добавить несколько дополнительных деталей ...

Я хорошо знаю, что тесты должны определяться синхронно :), именно здесь начинаются проблемы. Я полностью не согласен с этим, и я пытаюсь найти альтернативу, которая избегает до / после и делает это без указания внешней переменной. В Jest проблемах был открытый вопрос для решения этой проблемы, кажется, они согласились сделать описание asyn c, но они не будут этого делать. Причина в том, что ... Jest использует реализацию Java для Jasmine, и это "исправление" должно быть сделано там.

Я хотел избегать beforeAll и afterAll, насколько мог. Моей целью было создание простого (и аккуратного) способа определения интеграционных тестов, адаптированных к моим потребностям, не позволяя пользователям беспокоиться об инициализации и разрушении вещей. Я буду продолжать использовать стиль, описанный в примере 1, который мне кажется лучшим решением, даже если это будет явно более длительный процесс.

Ответы [ 2 ]

0 голосов
/ 20 апреля 2020

Как было отмечено, describe служит для групповых испытаний.

Этого можно достичь с помощью beforeAll. Поскольку beforeAll следует вызывать любым способом, его можно переместить в testPromise: 

const prepareHelpers = (testFn) => {
  beforeAll(() => {
    ...
    return helper.then(testFn);
  })
}

describe('Async describe approach', () => {
  let testHelper;

  prepareHelpers(helpers => { testHelper = helpers.testHelper });
  ...
0 голосов
/ 20 апреля 2020

Взгляните на Определение тестов . Do c говорит:

Тесты должны быть определены синхронно, чтобы Jest мог собирать ваши тесты.

Это принцип определения тестовых случаев. Это означает, что функция it должна определяться синхронно. Вот почему ваш второй пример не работает.

Некоторые операции ввода-вывода должны выполняться в методах beforeAll, afterAll, beforeEach, afterEach для подготовки ваших двойников и приборов. Тест должен быть максимально изолирован от внешней среды.

Если вы должны сделать это, возможно, вы можете записать динамически полученную функцию testHelper в файл stati c js, а затем протестировать ее синхронно

...