Запустить шутливые тесты в группах? - PullRequest
0 голосов
/ 04 мая 2018

Я пишу обширные тесты для нового API с помощью шуток и супертестов. Перед запуском тестов я настраиваю тестовую базу данных и заполняю ее пользователями:

Команда тестирования

jest --forceExit --config src/utils/testing/jest.config.js

jest.config.js

module.exports = {
  rootDir: process.cwd(),

  // Sets up testing database with users
  globalSetup: './src/utils/testing/jest.setup.js',

  // Ensures connection to database for all test suites
  setupTestFrameworkScriptFile: './src/utils/testing/jest.db.js',

}

Итак, я начинаю с базы данных некоторых пользователей для тестирования. Проблема заключается в следующем:

Некоторые из моих тестов основаны на успехе других тестов. В этом приложении пользователи могут загружать изображения и группировать их в пакеты. Поэтому мой набор конечных точек группировки зависит от успеха моего пакета загрузки изображений и т. Д.

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

Есть ли способ сгруппировать шутливые сюиты? Например, запускать наборы по порядку:

jest run creationSuite
jest run modificationSuite

Таким образом, все мои тесты "creationSuite" могут быть запущены одновременно, и при успешном выполнении all будет запускаться "ificationSuite "и т. Д. Без сбоев.

В качестве альтернативы было бы неплохо указать внутри набора тестов зависимости от других наборов тестов:

describe('Grouping endpoint', () => {
    // Somehow define deps
    this.dependsOn(uploadSuite)

1 Ответ

0 голосов
/ 04 мая 2018

Наборы тестов Jest выполняются в несколько потоков, это одно из его основных преимуществ. Таким образом, тестовые прогоны могут быть выполнены намного быстрее, но последовательность тестов не сохраняется по проекту.

Эту функцию можно отключить с помощью опции runInBand.

Можно выбирать тесты и наборы по их именам с помощью опции testNamePattern или по их путям с помощью опции testPathPattern

Поскольку один комплект зависит от другого, их, возможно, можно объединить в один комплект в том порядке, в котором они должны выполняться. Они по-прежнему могут находиться в разных файлах (убедитесь, что они не соответствуют Jest), например ::

// foobar.test.js
describe(..., () => {
  require('foo.partial-test.js');
  require('bar.partial-test.js');
});

Проблема заключается в следующем:

Некоторые из моих тестов основаны на успехе других тестов.

Это настоящая проблема здесь. Подход, основанный на предыдущем состоянии теста, считается ошибочным в любых видах автоматических тестов.

Я не хочу тщательно настраивать условия тестирования (например, искусственно создавать группу пользовательских изображений перед запуском тестов), потому что: (1) это просто дублирование логики и (2) это увеличивает возможность что-то сломать.

Нет необходимости устанавливать условия тестирования (приборы) искусственно. Светильники могут быть извлечены из существующей среды, даже из результатов ваших текущих тестов, если вы уверены в их качестве.

  • Избыточность и тавтология естественным образом возникают в автоматических тестах, с ними все в порядке. Тесты могут быть сделаны DRYer с надлежащим управлением приборами и общим кодом.

  • Наоборот, ошибки всегда накапливаются. Тест, который создал ошибочные предварительные условия, может пройти, но другой тест не пройдёт, что создаст загадку отладки.

...