Мы готовимся к Assert (js), первой конференции, посвященной тестированию для разработчиков JavaScript, и у нас есть потрясающий список спикеров. Они уже вызвали несколько разговоров в Твиттере, поэтому мы решили собрать группу на HashBang Show, чтобы дать предварительный обзор того, что готовит конференция!

В состав панели входили:

Мы рассмотрели множество тем, связанных с тестированием, как общих, так и специфичных для JS. Подключайтесь к эпизоду ниже и прокрутите вниз, чтобы увидеть основные моменты обсуждения и более подробную информацию о конференции!

Вот несколько основных моментов:

Происхождение моков / тестовых двойников

У Джастина была интересная история происхождения моков / шпионов / прокси / фейков / тестовых двойников:

  • Впервые они были представлены в конце 1990-х членами Лондонской группы экстремального программирования.
  • Такие люди, как Стив Фриман и Аннетт Прайс, представили их как механизм для изучения устаревшего кода.
  • «Представьте себе большую устаревшую кодовую базу как Звезду Смерти, и вы передадите имитацию объекта как натяжную проволоку, и всякий раз, когда с ней будут взаимодействовать, она взорвется».
  • Это был способ проинформировать их о том, как с аргументом взаимодействует «неизвестный, сбивающий с толку испытуемый».
  • Люди из Лондонской группы XP продолжали использовать тестовые дубликаты как способ получить обратную связь при проектировании при использовании TDD для разработки новой системы.
  • … И здесь начинается большая дискуссия о том, как часто ими злоупотребляют.
  • Джастин рекомендует прочитать Развитие объектно-ориентированного программного обеспечения с помощью тестов Стива Фримена и Ната Прайса.

«Тестовая пирамида»

  • Пирамида тестирования - это концепция, согласно которой автоматизированные тесты в основном должны состоять из модульных тестов, которые образуют основу пирамиды, затем меньше интеграционных тестов, которые образуют середину, и лишь небольшого количества сквозных тестов. тесты, управляющие пользовательским интерфейсом.
  • Кент: Пишите тесты. Не так много. В основном интеграция .
  • Глеб: Форма пирамиды на самом деле определяется не нашими потребностями, а теми инструментами, которые у нас есть сейчас.
  • «Уверенность возрастает по мере того, как вы поднимаетесь по пирамиде», но удобство уменьшается.
  • Но у Джастина есть альтернативное мнение: он считает, что, вопреки ожиданиям большинства людей, чистые модульные тесты, которые имитируют все изолированно, на самом деле действительно обеспечивают высокую уверенность. Причина этого в том, что, как объясняется в этой статье, модульное тестирование - это продуманность кодирования, и это приводит к созданию более качественной системы.

Инструменты и рабочие процессы, которые максимизируют интенсивную вдумчивость, как правило, встраивают и кодируют наши желания относительно того, что система должна делать эффективно ... и вот почему я склонен поощрять людей не вкладывать слишком много средств в инструменты автоматизации, особенно в инструменты записи / воспроизведения, потому что, если что-то они выбирают для легкомыслие.

  • Брайан о сквозных тестах:

Неудача сквозного тестирования заключается в следующем: когда есть предварительное условие [для состояния, которое вы хотите протестировать], вы затем используете пользовательский интерфейс для генерации состояния для другого предварительного условия, и в основном здесь все идет не так ... Если вы Тестируя функциональность корзины покупок, используете ли вы пользовательский интерфейс для посещения области администрирования, чтобы создать 100 продуктов, а затем добавить их в корзину? Точно нет. Мы рекомендуем следующее: у вас есть несколько незафиксированных, незагруженных интеграционных тестов, которые тестируют действительно критические области приложения. И как только вы это сделаете, как только вы убедитесь, что это работает, у вас будет 100% уверенность, что вы никогда больше не будете использовать эту часть пользовательского интерфейса. Это в основном философия Cypress, и именно это делает его совершенно другим инструментом, потому что с архитектурной точки зрения он позволяет вам делать подобные вещи.

Чем отличается тестирование на JavaScript

Тестирование асинхронного кода:

  • Инструменты, которые у нас есть в последние годы, значительно улучшили асинхронное тестирование, например обещания и async / await.
  • Во многом причиной асинхронного кода является ввод-вывод, который должен находиться на периферии приложения, но «мясо и кости» должны быть бизнес-логикой, и разделение этих двух аспектов действительно полезно.

Чего ждать

Участники дискуссии с нетерпением ждут встречи и разговора с участниками об их подходах к тестированию и проблемах. Мы призываем всех воспользоваться возможностью поговорить со всеми выступающими в небольшой социальной среде. Так что приезжайте в Сан-Антонио и узнайте больше о темах, затронутых в этом выпуске, за напитками и едой!

Напоминаем, если вы пропустили объявление Роберта о специальном промокоде:

Используйте промокод HASHBANG при выезде и получите 20% скидку от обычной цены на билеты!

Билеты и информацию о конференции можно найти на https://www.assertjs.com/.

Мы надеемся увидеть Вас там!

Первоначально опубликовано на www.okgrow.com.