О, да. Опыт разработчиков с Jest превращает процесс написания тестов из рутины в адское веселое времяпрепровождение, обещаю! 🤓
Этот пост является продолжением моего предыдущего поста о Jest’s Framework:
Логотип
Ой, логотип. Разве это не хорошо?
Как будто пытается сказать тебе: «Ты собираешься писать тесты? это будет весело! »
И именно так это завлекает тебя
Хорошо, но если серьезно, мне просто нужен элемент слева, чтобы выровнять остальные элементы. Прости меня 🤷.️
Анекдот о логотипе, если хотите -
Недавно я узнал, что логотип Jest был создан в последнюю минуту на наброске Джеймсом Пирсом, где он повторил несколько вариантов (ссылка в твиттере), но более забавно Кристоф Наказава упомянул, что… круги, расположенные рядом друг с другом, напоминают ему загрузочную анимацию, которая коррелирует с медлительностью :-)
Визуальные различия и эффективная многословность
Большая часть хорошего опыта разработчика - это повышение вашей продуктивности.
Когда дело доходит до тестирования, когда тесты терпят неудачу, вы хотите быстро определить, что пошло не так с тестом.
Возьмем, к примеру, этот фрагмент кода:
В исходном коде теста есть опечатка.
Вот как Jest покажет ошибку в консоли:
Он предоставляет отличный контекст для фактического файла, номера строки и стрелок, указывающих на точную проблему, а также окрашивает код подсветкой синтаксиса.
Собираетесь ли вы сравнивать два объекта в своих утверждениях?
Нет проблем. Jest настолько многословен, что покажет отличное различие даже для вложенных ключей, которые различаются между объектами, которые вы сравниваете:
примечание: Jest был сделан очень модульным, и многие его возможности были перенесены в отдельные модули, которые может использовать сообщество.
Если вам нравится приведенное выше различие, вы можете использовать его в своем собственном проекте, см. Здесь: http://jestjs.io/docs/en/jest-platform.html#jest-diff
Расслабляющие условности
Соглашения о тестовых наборах
Если вы работаете с разными участниками тестирования или фреймворками, вы знаете, что они различаются по синтаксису наборов тестов.
Некоторые используют describe.only (), в других можно использовать только test ().
В некоторых из них вы отключаете тест с помощью test.skip (), а в других - xit ().
С Jest это не имеет значения.
Он делает все возможное, чтобы оптимизировать продуктивность, вместо строгих соглашений.
Вы можете написать test () или вложенные описать () и test (), или просто используйте it ().
Понятно.
Какое соглашение об именах файлов следует использовать для тестов?
Какая разница! 😜
Jest автоматически подберет любые расширения файлов * .test.js или * .spec.js. как любые файлы в каталоге __tests__.
Дружественный интерфейс командной строки
У Jest есть удобный интерфейс командной строки, который поможет вам понять, что вы имеете в виду под спагетти-пальцами:
Конечно, это не путешествие во времени, а еще один краеугольный камень в повышении производительности и дружелюбности Jest к разработчикам.
Самое главное - это мелочи.
Тестовые пары
В автоматизированном тестировании, когда мы пишем и выполняем модульные и интеграционные тесты, обычной практикой является использование различных типов тестовых двойников для изоляции различных частей системы.
Существуют разные методы изоляции с разными целями и поведением, но все они вместе называются тестовыми двойниками.
В то время как другие библиотеки, такие как Sinon, требуют от вас явного объявления и выбора типа тестового двойника для вашего теста (заглушка, макет, шпион), Jest объединяет все в единую точку входа, называемую Mock-объектом (jest.fn) .
Доступ к Mock и его использование по-разному осуществляется через тестовый код, но, по сути, вам не нужно беспокоиться о таких решениях в своем тестовом коде относительно типов тестовых двойников. Это еще одно повышение производительности с Jest.
Тем не менее, вы все равно должны понимать принципы тестирования.
Рекомендуемая литература о Test Doubles в блоге Мартина Фаулера: https://martinfowler.com/bliki/TestDouble.html
Иммерсивный режим просмотра
Некоторые преимущества режима просмотра Jest, который упрощает рабочий процесс разработки:
- Очевидное - мгновенный запуск тестов по мере появления изменений (в среде IDE или, скажем, вы переключаете ветку).
- Jest решает, какие тесты запускать автоматически.
Он управляет метаданными исходного кода, чтобы узнать, как запускать только соответствующие тестовые файлы при изменении файла исходного кода. - В интерактивном режиме просмотра Jest вы увидите, фильтруете ли вы файлы любого типа. Например, если вы запустили jest с определенным путем к глобу, он отобразит его как активный фильтр:
- Больше не тестируйте test.only (), вставляя его в ваш тестовый код и случайно попадая в ваш PR. С помощью Jest вы можете легко отфильтровать тестовый запуск по имени файла или имени теста прямо из консоли. Поэтому просто отфильтруйте тест по имени, и только он будет запускаться повторно всякий раз, когда вы вносите изменения в тестовый файл:
Еще кое-что, что вам следует знать о средстве выполнения тестов:
- Jest сначала запускает самые медленные тесты, чтобы оптимизировать параллельную работу ЦП и сократить общее время выполнения теста.
- Jest сначала запустит тесты, которые ранее не давали результата, чтобы обеспечить быструю обратную связь.
- Jest выберет порядок запуска тестов, поэтому вам определенно не следует ожидать, что они будут запускаться в алфавитном порядке или каким-либо другим способом.
Для вас они запускаются совершенно случайным образом, и было бы плохой практикой иметь тестовые файлы с именем 01_loginFucntions.spec.js, 02_createUsers.spec.js.
Итак, что вам нравится в опыте разработчиков при использовании Jest?
