Какие среды тестирования можно использовать для Node? В следующей статье мы познакомим вас с некоторыми средами тестирования Node.js. Надеюсь, она будет вам полезна! 
Краткое введение в Node.js: войдите, чтобы узнать
Примечание редактора: автор этой статьи — Тяньжу, инженер Node.js в Ant Group. Сначала он представит часто используемые библиотеки классов в каждой части. В конце статьи он обсудит, необходимо ли модульное тестирование. Добро пожаловать. обсудить вместе.
Обычно используются мокко и шутка. Официальный тест нового узла все еще дорабатывается, и будущее многообещающее.
$мокко test/egg-view-ejs.test.js оказывать ✓ должен рендериться с местными жителями ✓ должен рендериться с кешем ✓ должен отображаться с макетом ✓ должен отображать ошибку рендерСтрока ✓ должен отображать строку с данными ✓ должна отображать ошибку String 6 проходов (398 мс)
Несмотря на то, что Runners очень много, все их стандарты вывода имеют формат TAP, а результаты выводятся через разные Reporters.
Просто написать один тест недостаточно. Нам нужно знать, покрыты ли все ветвящиеся процессы кода, поэтому обычно приходится использовать инструменты покрытия кода.
Раньше это были istanbuljs, но позже автор переписал nyc. В основном они несут две обязанности: одна — трансляция кода для вставки кода свай, а другая — поддержка различных репортеров для создания отчетов о покрытии.
Позже встроенная статистика покрытия V8.
, то есть больше нет необходимости транслировать код, а сбор данных о покрытии поддерживается изначально.
Затем этот автор написал c8, ориентированный на создание отчетов о покрытии.
Чтобы проверить переменные результаты, утверждение необходимо.
Исторически сложилось так: «expect.js», «должен.js», «chai» и «power-assert», jest также имеет свой собственный встроенный метод «ожидание».
Но теперь официальный метод Assert/strict Node.js на самом деле довольно хорош.
Среди них мы в EggJS используем power-assert. Я также упоминал об этом много лет назад: «Наверное, лучшая библиотека JS Assert — Новая одежда императора».
const Assert = require('power-assert');
описать('test/showcase.test.js', () => {
const arr = [1, 2, 3];
it('power-assert', () => {
утверждать (arr[1] === 10);
});
});
//выход:
4) test/showcase.test.js power-assert:
AssertionError: # test/showcase.test.js:6
утверждать (arr[1] === 10)
|
2 ложные
[1,2,3]
[число] 10
=> 10
[число] обр[1]
=> 2PS: Если вы хотите проверить содержимое файла, я также написал файл утверждения, попробуйте его.
Поскольку это модульный тест, часто необходимо моделировать среду или последующие реакции.
sinonjs неплох и поддерживает макеты, заглушки и т. д. jest также имеет собственную встроенную библиотеку макетов.
Если это HTTP-тестирование, nock очень мощный инструмент, который поможет вам имитировать ответ сервера.
нок('http://www.example.com')
.post('/login', 'username=pgte&password=123456')
.reply(200, { id: '123ABC' })Однако официальная библиотека запросов undici Node.js также имеет встроенные возможности Mock.
Существует также термин, называемый моментальным снимком, который означает сброс данных во время работы и непосредственное использование их в качестве макетных данных для следующего теста, что может в определенной степени повысить эффективность написания тестов.
Для тестирования сценариев HTTP-сервера необходима библиотека supertest.
описать('GET /users', function() {
it('отвечает с помощью json', async function() {
запрос на возврат (приложение)
.get('/пользователи')
.set('Принять', 'приложение/json')
.expect('Тип контента', /json/)
.ожидать(200)
.then(ответ => {
Assert(response.body.email, '[email protected]');
});
});
});Одним из основных сценариев использования Node.js является интерфейс командной строки командной строки, такой как Webpack и Babel, которые сами по себе также требуют модульного тестирования.
Вот что мы рекомендуем:
GitHub — node-modules/clet: тестирование E2E в командной строке
GitHub — node-modules/coffee: проверка командной строки на Node.js
импорт {бегун, КЛЮЧИ} из 'clet';
it('должно работать с шаблоном', async () => { await runner() .cwd(tmpDir, { init: true }) .spawn('npm init') .stdin(/name:/, 'example') // ждем стандартного вывода, затем отвечаем .stdin(/version:/, new Array(9).fill(KEYS.ENTER)) .stdout(/"name": "example"/) // проверяем стандартный вывод .notStderr(/ npm ERR/) .file('package.json', { name: 'example', version: '1.0.0' }) // проверяем файл });
Для упрощенного сканирования страниц вы можете напрямую использовать HTTP для запроса библиотеки. Рекомендуется Unci.
Для имитации фактического выполнения браузера на первых порах использовались selenium и phantomjs.
Затем Google официально выпустил puppeteer. Благодаря накоплению Chromium и основанному на протоколе devtools-protocol он быстро стал популярным и убил первые два. К аналогичным конкурирующим продуктам относятся драматург и кипарис.
Кстати, я собираюсь загрузить macacajs, инструмент для многотерминального тестирования. Помимо браузеров, он также поддерживает тестирование мобильных и настольных приложений. Его исходный код разработан инженерами Yuque.
Когда мы пишем открытый исходный код, нам часто нужны автоматизированные службы непрерывной интеграции, которые помогут нам в тестировании.
Среди игроков в этой области: Travis, Appveyor, GitHub Actions и т. д.
Сейчас я в основном использую GitHub Actions, и уровень интеграции такой крутой.
Нет сомнений в том, что модульное тестирование очень важно. Это необходимое умение и профессиональное качество квалифицированного программиста.
Конечно, мы не фанатики 100% покрытия. Во многих случаях нам необходимо стремиться к достижению баланса рентабельности инвестиций.
Прежде всего, позвольте мне исправить распространённую точку зрения новичков: написание модульных тестов — пустая трата времени?
На самом деле написание модульных тестов сэкономит вам время. Причина такого нелогичного взгляда заключается в том, что условия сравнения часто не объективны. Нам необходимо учитывать стоимость регрессии после двукратного изменения кода при одних и тех же требованиях к качеству.
Для справедливого сравнения, помимо учета «времени на написание одного теста», легко упустить из виду «время выполнения регрессионного тестирования после каждой модификации кода»:
При написании одного теста на ранней стадии создайте различные макеты ветвей, а время для регрессионного тестирования — это просто набор текста на клавиатуре;
Не написав ни одного теста, вам необходимо обновить код приложения, а затем вручную смоделировать различные ситуации для тестирования, например, открытие браузера и нажатие на множество разных мест.
Насколько трудоемки эти два процесса, понятно с первого взгляда.
Это не что иное, как первоначальные вложения + стоимость обслуживания + упор на качество отдачи. У каждой компании своя шкала при принятии решений после их взвешивания.
Конечно, многие из упомянутых мной сценариев представляют собой библиотеки фреймворков (включая интерфейсные и Node.js), серверные приложения, инструменты командной строки и т. д. Это правда, что некоторые интерфейсные приложения, в которых происходят большие изменения, Отображение пользовательского интерфейса или быстрая загрузка и выгрузка. Для страницы активности соответствующие затраты на обслуживание одного теста действительно очень высоки. В настоящее время разумно отказаться от отдельных тестов некоторых неосновных ветвей на основе рентабельности инвестиций.
Но мы должны понимать, что это последнее средство. Мы можем снизить стоимость поддержки модульного тестирования различными способами, но мы не можем утверждать, что модульное тестирование бесполезно.
Существует также полуавтоматический регрессионный тест во внешнем интерфейсе, который основан на различиях и автоматизирует сравнение, а затем напоминает владельцу о необходимости обратить внимание на влияние изменений. Это похоже на библиотеки инструментов, описанные выше, которые помогают снизить затраты на написание отдельных тестов.
Это тоже ошибочное мнение. Юнит-тесты должны писать сами программисты , потому что это ваш собственный код, и вы должны за него отвечать. Это своего рода профессионализм. Любая команда, имеющая хоть немного стандартизации, нуждается в CI-тестировании при отправке кода, иначе не будет качественного сотрудничества по проверке кода.
Студенты-тестировщики отвечают за работу более высокого уровня, такую как интеграционное тестирование, регрессионное тестирование и сквозное тестирование .
Разделение труда другое, поэтому, пожалуйста, не обвиняйте других.
Модульное тестирование очень необходимо. Написание модульных тестов — это основное профессиональное качество программистов. Пишите как можно больше. В отдельных сценариях вы можете делать выбор, исходя из рентабельности инвестиций.