Jest и тестирование
otus.ru
Проверить, идет ли запись
Меня хорошо видно
&& слышно?
Ставим “+”, если все хорошо
“-”, если есть проблемы
Jest и тестирование
Тема вебинара
Игорь Звягин
Frontend team-lead в leadvertex
Во frontend разработке c 2016 года,
разрабатывал, и интернет магазины, и лендинги, и сложную crm систему
Являюсь заклинателем хуков в 5 поколении, вызываю дождь методами жизненного цикла.
Я на связи в телеграмм spirit_drive
Jest
Jest
Фрэймворк тестирования на JavaScript, созданный поверх Jasmine[2] и поддерживаемый Meta (ранее Facebook). Он был разработан Кристофом Наказава с акцентом на простоту и поддержку больших веб-приложений. Он работает с проектами, использующими Babel, TypeScript, Node.js , React, Angular, Vue.js и Svelte. Jest не требует большой настройки для начинающих пользователей платформы тестирования.
© Википедия
Jest настройка
Установка
npm install --save-dev jest ts-jest babel-jest
import {sum} from './sum';
describe('sum module', () => {
test('adds 1 + 2 to equal 3', () => {
expect(sum(1, 2)).toBe(3);
});
});
Первый тест
Файл конфигурации учебного репозитория
Создаем файлы тестов
Тест - это отдельный js/ts файл с постфиксом .test или .spec (по-умолчанию, но можно изменить в конфигурации).
Jest автоматически ищет в проекте все файлы с заданными постфиксом.
Или же папку с названием __tests__, все файлы в этой папке будет запускать как тесты
Jest test Api. Первый тест
Минимально тест состоит из
Jest результат тестов. Успех
Jest результат тестов. Ошибка
Jest test Api advanced
Jest expect Api
jest содержит внушительное api для expect, подробно с которым можно ознакомиться тут.
Jest конфигурация
moduleNameMapper - обработка путей импортов. Здесь можно указать alias, а также как реагировать на различные расширения.
transform - как с помощью чего преобразовывать код перед запуском. Jest из коробки не понимает современный синтаксис js и не понимает ts.
testEnvironment - тестовое окружение, по умолчанию “node”. “jsdom” позволяет в тестах работать с dom элементами, что нам понадобится при работе react-testing-library
Jest cli
jest - запустит все тесты в проекте
jest src - запустит все тесты в директории src
jest -t colors - запустит тест с именем colors
jest src/screens/Lessons/TestingAndJest/colors.test.js - запустит тесты в указанном файле
jest -o - запустит тесты связанные с незакоммиченными файлами
jest --watch - запустит автоматически тесты, связанные с измененными файлами
jest --watchAll - запустит автоматически все тесты и любом изменении
Как правило описывают в скриптах команду test, которая запускает jest
Вопросы?
Ставим “+”,
если вопросы есть
Ставим “–”,
если вопросов нет
Тестирование
Тестирование
Тестирование - это проверка кода. Существует ручное и автоматическое тестирование
Тестирование
Ручное
Автоматическое
Автоматическое vs Ручное
Ручное тестирование - неотъемлемый процесс разработчики. После создания функционала, ручное тестирование либо превращается в автоматическое тестирование, либо перекладывается на плечи ручного тестировщика.
Ручное тестирование - медленное, нестабильное и дешевое и его легко поддерживать.
Автоматическое тестирование - стабильное и быстрое, запускается автоматически при определенных триггерах (коммит, пуш или напрямую в консоли), но этот вид тестирования дорогой. Написанием тестов занимаются сами разработчики либо тестировщики. Автоматические тесты сложно поддерживать.
Тестирование и разработка
проекта по Agile
Agile - это методика разработки проекта. Подразумевает работу циклами. В каждом цикле есть несколько фаз:
Подробнее тут
Тестирование и разработка
проекта по Agile
В контексте тестирования важно понимать, что на этапе разработки преимущество отдается ручному тестированию. И только по завершению этапа разработки наступает фаза тестирования и вот здесь нужно автоматическое тестирование.
Ручное
Автоматическое
Что тестировать и в каком объеме
Важно понимать - тестирование требует затрат. Вначале это написание тестов, но при каждом изменении функционала приходится переписывать и тесты. В какой-то момент может оказаться, что поддержание тестов требует большего труда, чем сама разработка и часто бывает, что это не имеет смысла.
До сих пор нет единого мнения, сколько процентов покрытия тестами должно быть в проекте. Одни компании утверждают, что должно быть не менее 80%, другие говорят, что автотесты не нужны вовсе.
Я считаю, что покрытие тестами зависит от количества пользователей, автономности приложения, цены ошибки и вероятности использования функционала.
Формула покрытия тестами конкретного функционала
Диссертацию пока никто не защищал, поэтому стоит проверить эту гипотезу на своей практике и вывести для себя свою формулу, к тому здесь наверняка нужны уточняющие коэффициенты, но в целом концепцию считаю верной
П - Процент покрытия тестами для конкретного функционала
А - Автономность продукта
Ц - Цена ошибки
К - Кол-во пользователей
В - Вероятность использования функционала
Формула покрытия тестами конкретного функционала
Автономность продукта. Если вы можете самостоятельно обновить работу продукта у клиента - автономность низкая. Если ваш клиент останется на долго один на один с продуктом и вы никак не можете ему помочь - автономность высокая. Соответственно, чем выше автономность, тем больше должно быть покрытие тестами.
Цена ошибки функционала. Если от написанного функционала зависит жизнь и здоровье человека - не может быть компромиссов, покрытие тестами должно стремиться к 100%
Количество пользователей. Чем больше пользователей, тем выше риски, тем выше должен быть процент покрытия тестами.
Вероятность использования функционала. В любом продукте есть основной функционал (он будет использоваться постоянно, потому требует максимального покрытия тестами) и вспомогательный (часто можно обойтись без тестов вообще)
Вопросы?
Ставим “+”,
если вопросы есть
Ставим “–”,
если вопросов нет
Рефлексия
Заполните пожалуйста опрос о занятии по ссылке в чате