Ладно, давайте считать, что мы познакомились. И раз уж я человек из IT, давайте про него любимого и поговорим.
Для начала будем расширять границы вашего тестового сознания!
На каждой конференции рассказываю про тесты, в моей работе самое сложное - это придумать хороший тест, который спасет нас от дизастер!
Думаю все здешние читатели знаю, что такое Unit тесты?
🤔
52.7% Знаю и пишу units🤔
34.6% Знаю и не пишу🤔
12.7% Не знаюПродолжаем ворошить тему Unit' тестов, часто выделяют в теории и практике тестирования следующие термины: dummy, stub, spy, mock, fake
🤔
18.1% Знаю все 5 терминов🤔
33.1% Знаю больше 3 терминов🤔
36.7% Где-то слышал🤔
12.0% Это не про Unit тестыОбычно я выделаю 3 правила для Unit тестов (вы можете этому не следовать и это нормально):
- детерминизм
- изоляция
- независимость от внешних факторов
- здравый смысл
Unit тесты для слабаков, давайте дальше. Понимаете ли вы мнемонику, когда нужно переходить к интеграционным тестам?
Я вот часто видел, как ребята тестируют то, как работает JVM. Если JVM работает не так, как написано - то у вас явно проблемы немного не уровня json-метателя!
🤔
39.1% Знаю когда писать IT🤔
60.9% Не знаюПочему я сделал предыдущий опрос? Потому что я не нашел адекватного ответа на то, что такое интеграционный тест и чем он отличается от e2e.
На пальцах понятно - но формального определения я так и не вывел
В моем мире IT нужны для предотвращения каскадных разломов, но это далеко не единственный вариант от них защищаться. По этому пробежимся по грязным хакам, которые можно использовать в тестировании.
Можно ли определить качество наших тестов? Если да, то что из пунктов ниже, приближает нас к этой метрике?
🤔
23.0% Когнитивная сложность🤔
33.3% Code Coverage🤔
43.7% Мутационное тестированиеИмхо, все три метрики достойны косвенно подтверждать качество наших тестов, ведь
тесты, которые сложно читать - плохие тесты,
тесты, которые тестирую мало чего - плохие тесты,
тесты, которые не падают, если код поменять - плохие тесты
Мутационные тесты - это офигенно! Идея: поменять/удалить рандомную строчку в коде и запустить тесты -> если ничего не упало, то грош цена вашим тестам, ведь код можно менять и тесты это не задетектят...
попробуйте удалить строчку, поменять + на - или < на >= и потом смотрите с каким трудом синьйоры будут пытаться понять где же ваш код не работает ^^
#blackHatMode
Без шуток, если вы не знаете про мутационные тесты, то настоятельно рекомендую посмотреть: youtube.com/watch?v=9yG1c9…
очень мощный инструмент и сильная идея!
Давайте еще придумаем варианты проверки качества тестов? Как на счет генерировать random seed -> который будет менять порядок запуска тестов? Если тесты упали, потому что были запущенны в неправильном порядке - плохие это тесты или нет?
🤔
47.5% Плохие тесты🤔
11.7% Плохие разрабы🤔
5.0% Хорошие тесты🤔
35.8% It dependsНа самом деле It Depends, но 98% гарантии, что если поменять порядок тестов и они упадут - то ваши тесты ГОВНО.
Чаще всего достаточно init/tearDown (before/after/beforeEach) для того чтоб задать правильное стартовое окружение и почистить его за собой
Я встречал реализацию, где делают "sequence" тесты, где каждый следующий тест идет поверх результатов предыдущего. Это боль! для поддержки и отладки и понимания. Не делайте так без крайней нужды
А если увидите что когда-то так делает ваш сосед - выстрелите ему в ногу, лучше так, чем себе через неделю...
Какие еще идеи тестирования лежат на поверхности?
(до изысканных нам еще далеко)
Lets Talk About SnapShot Testing!
🤔
18.3% Делаю снепшоты🤔
17.1% Перестал🤔
64.6% А что это?Идея снепшот тестов тоже лежит на поверхности. Зачем нам смотреть в код, давайте запихнем на вход что-то, посмотрим что получилось на выходе запишем в файл и скажем, что так и нужно. Это наш эталон! Так должно работать всегда!
Давайте покрутим идею в разные стороны. Если получится - то огонь, если не получится - то и хрен с ним, откажемся от идеи
Снепшот тесты - это риск. Потому что очень часто снепшот тесты могут падать и всегда хочет забить и просто запустить программу в режиме "обнови эталонные данные". За этим нужно следить
Из снепшот тестов - можно сделать скриншот тесты -> зачем записывать в файл текст, если можно картинку из браузера?
И так делают, правда там много дичи с разрешением, шрифтами и еще много чем -> узнаете когда будете делать хД
А еще снепшоты тетсы оказывается можно не писать, а генерировать?!
Все что нужно - вкорячить стейт машину в ваше приложение и наслаждаться!
Как вкорячить: youtube.com/watch?v=VU1NKX…
А потом посмотреть во всякие проекты потипу react-automata и пр. украсть код, адаптировать под свои нужды и получить декларативный UI и автотесты для него. ОХОХОХО! Как сочно?!
🤔
61.4% Не сочно🤔
38.6% СОЧНОПоследнее время снепшоты начали прикладывать по новому. Поговорим про еще одну реинкарнацию!
🤔
13.5% Использую контракты🤔
28.8% Не использую🤔
57.7% Что это?Что это, как это и с чем едят, отлично рассказа @brekelov вот здесь:
youtube.com/watch?v=ikhj3A…
В моей голове это вынужденная мера. Количество людей растет и им нужно договариваться, появились DDD, сторминги, circuit breakers и много других подходов и паттернов с целью защитить нас от лукавого. Контракты - из той же оперы
Что можно тестировать еще:
- зависимости
- код стайл
- когнитивную сложность
- цикломатическую сложность
и еще вагон и маленькую тележку всего :)
А вот теперь вопрос, как вы думаете, что из этого тестировать нельзя?
🤔
3.4% Зависимости и версии libs🤔
6.9% Окружение/environment🤔
34.5% Хаос🤔
55.2% Все можноЯ склоняюсь к ответу "все можно", но если сильно придираться - то правильный ответ - хаос.
Давайте буду приводить примеры как это может быть. И буду рассказывать всякие странные штуки, которые могут спасти вам жизнь или украсть время!
Тестируем окружение: пишем тест, который проверяет: что заданы все переменные окружения, установлены все зависимости (язык программирования, шрифты если нужно etc) и если версии не совпадают - тест падает. (есть готовые решения)
Где использовать: на локальной машине
Кейс такой: длин, у меня сборка локально не работает - сделай так чтоб env тесты стали зелененькие - а потом приходи (экононмит много времени и сил)
Правда докер последнее время подпортил перспективы этого варианта тестирования
В свое время чиф/папет/солт позволяли так проверять и обновлять конфигурации, когда шаловливые ручки по ssh что-то меняли
Тестируем зависимости:
- проверяем лицензионную чистоту (gitlab/nexus/artifactory etc.) умеют это делать
- проверяем наличие OWASP уязвимостей в используемых зависимостях
- банально пишем тесты на exceptions и обработку "невалидных" ответов от библиотеки
- проверяем циклические завимости
- кофликты в используемых библиотеках
- размер и сам факт того, что зависимости используются
- тришейкинг (оптимизируем размер итогового бандла)
Все что нужно знать о приложеньке азбуки вкуса :) pic.twitter.com/gAvZY3rvyP
Если этого не делать, то можно например попасть в такую историю:
twitter.com/Kentilini/stat…
Тестирование хаосом я долгие годы недооценивал, ну мол че такого, взял хаос манки, тыкаешь во все что тыкается и смотришь на результат и посыпавшиеся ошибки в логах.
Сейчас у нас на работе есть возможность проверять модели (которые создают наши пользователи) на устойчивость к стохастике и вот здесь я почувствовал бизнес мощь этой идеи. Но круче всего это не устойчивость к хаосу, а умение им управлять!
Идея тестирования параметризированным хаосом зажгла мою душу своей простотой и элегантностью. Это как взять контрактные тесты и переложить их в серый ящик!
Пример контракта для параметризированного хаоса:
check(
property(
gen.int, gen.int,
(a, b) => a + b >= a && a + b >= b
)
)
Есть функция которая считает сумму двух чиселок и есть контракт: сумма должна быть больше каждого из входных параметров.
Тестирование хаосом показывает, что это не правда и показывает минимальный воспроизводимый результат:
[0, -1] => потому что 0 + (-1) === -1
Давайте повысим градус тестирования:
написали в postman коллекцию тестов -> поставьте newman и включите эти тесты в CI, пусть гоняются всегда
github.com/postmanlabs/ne…
Гоняете ваши тесты в newman -> добавьте JSON Schema для проверки "контрактов" -> чтоб потом не удивляться, почему массив на 20к элементов обрабатывается некорректно в вашем приложении.
bit.ly/2TDokxp
Давайте теперь 2 последних примера вне этого треда, которые вам покажутся наркоманскими (?) цель: показать, что тестировать и разрабатывать можно не всегда под копирку :)
Мне очень нравится этот гитхаб проект: github.com/kgrzybek/modul… он показывает, как можно красиво сделать приложение и описать его. Тут и про тесты и bounded contextы и архитектуру
Кейс №1 (Арх. тесты)
twitter.com/itunderhood/st…
Те кто читали книжку @samnewman или блог @martinfowler знают про паттерн Strangler. Но можно ли его использовать для тестирования? Давайте придумаем как!? pic.twitter.com/qaBKud2pPv
Кейс №2 (branch by abstraction/strangler)
twitter.com/itunderhood/st…
Ярик Астафьев