Мы готовимся к Assert (js), первой конференции, посвященной тестированию для разработчиков JavaScript, и у нас есть потрясающий список спикеров. Они уже вызвали несколько разговоров в Твиттере, поэтому мы решили собрать группу на HashBang Show, чтобы дать предварительный обзор того, что готовит конференция!
В состав панели входили:
- Кент С. Доддс (PayPal)
- Джастин Сирлз (Test Double)
- Брайан Манн (Cypress)
- Глеб Бахмутов (Кипарис)
Мы рассмотрели множество тем, связанных с тестированием, как общих, так и специфичных для JS. Подключайтесь к эпизоду ниже и прокрутите вниз, чтобы увидеть основные моменты обсуждения и более подробную информацию о конференции!
Вот несколько основных моментов:
Происхождение моков / тестовых двойников
У Джастина была интересная история происхождения моков / шпионов / прокси / фейков / тестовых двойников:
- Впервые они были представлены в конце 1990-х членами Лондонской группы экстремального программирования.
- Такие люди, как Стив Фриман и Аннетт Прайс, представили их как механизм для изучения устаревшего кода.
- «Представьте себе большую устаревшую кодовую базу как Звезду Смерти, и вы передадите имитацию объекта как натяжную проволоку, и всякий раз, когда с ней будут взаимодействовать, она взорвется».
- Это был способ проинформировать их о том, как с аргументом взаимодействует «неизвестный, сбивающий с толку испытуемый».
- Люди из Лондонской группы XP продолжали использовать тестовые дубликаты как способ получить обратную связь при проектировании при использовании TDD для разработки новой системы.
- … И здесь начинается большая дискуссия о том, как часто ими злоупотребляют.
- Джастин рекомендует прочитать Развитие объектно-ориентированного программного обеспечения с помощью тестов Стива Фримена и Ната Прайса.
«Тестовая пирамида»
- Пирамида тестирования - это концепция, согласно которой автоматизированные тесты в основном должны состоять из модульных тестов, которые образуют основу пирамиды, затем меньше интеграционных тестов, которые образуют середину, и лишь небольшого количества сквозных тестов. тесты, управляющие пользовательским интерфейсом.
- Кент: Пишите тесты. Не так много. В основном интеграция .
- Глеб: Форма пирамиды на самом деле определяется не нашими потребностями, а теми инструментами, которые у нас есть сейчас.
- «Уверенность возрастает по мере того, как вы поднимаетесь по пирамиде», но удобство уменьшается.
- Но у Джастина есть альтернативное мнение: он считает, что, вопреки ожиданиям большинства людей, чистые модульные тесты, которые имитируют все изолированно, на самом деле действительно обеспечивают высокую уверенность. Причина этого в том, что, как объясняется в этой статье, модульное тестирование - это продуманность кодирования, и это приводит к созданию более качественной системы.
Инструменты и рабочие процессы, которые максимизируют интенсивную вдумчивость, как правило, встраивают и кодируют наши желания относительно того, что система должна делать эффективно ... и вот почему я склонен поощрять людей не вкладывать слишком много средств в инструменты автоматизации, особенно в инструменты записи / воспроизведения, потому что, если что-то они выбирают для легкомыслие.
- Брайан о сквозных тестах:
Неудача сквозного тестирования заключается в следующем: когда есть предварительное условие [для состояния, которое вы хотите протестировать], вы затем используете пользовательский интерфейс для генерации состояния для другого предварительного условия, и в основном здесь все идет не так ... Если вы Тестируя функциональность корзины покупок, используете ли вы пользовательский интерфейс для посещения области администрирования, чтобы создать 100 продуктов, а затем добавить их в корзину? Точно нет. Мы рекомендуем следующее: у вас есть несколько незафиксированных, незагруженных интеграционных тестов, которые тестируют действительно критические области приложения. И как только вы это сделаете, как только вы убедитесь, что это работает, у вас будет 100% уверенность, что вы никогда больше не будете использовать эту часть пользовательского интерфейса. Это в основном философия Cypress, и именно это делает его совершенно другим инструментом, потому что с архитектурной точки зрения он позволяет вам делать подобные вещи.
Чем отличается тестирование на JavaScript
Тестирование асинхронного кода:
- Инструменты, которые у нас есть в последние годы, значительно улучшили асинхронное тестирование, например обещания и async / await.
- Во многом причиной асинхронного кода является ввод-вывод, который должен находиться на периферии приложения, но «мясо и кости» должны быть бизнес-логикой, и разделение этих двух аспектов действительно полезно.
Чего ждать
Участники дискуссии с нетерпением ждут встречи и разговора с участниками об их подходах к тестированию и проблемах. Мы призываем всех воспользоваться возможностью поговорить со всеми выступающими в небольшой социальной среде. Так что приезжайте в Сан-Антонио и узнайте больше о темах, затронутых в этом выпуске, за напитками и едой!
Напоминаем, если вы пропустили объявление Роберта о специальном промокоде:
Используйте промокод HASHBANG при выезде и получите 20% скидку от обычной цены на билеты!
Билеты и информацию о конференции можно найти на https://www.assertjs.com/.
Мы надеемся увидеть Вас там!
Первоначально опубликовано на www.okgrow.com.