frontend-fellows-test

Слайды презентации для frontend-fellows в Ижевске

Название

• Почему вам не нужно писать тесты
• От нуля до сотни за 3.8
• Белоснежка и семь тестов

Драфт

• Тесты это зло
  • Они отнимают много времени
    • Задача - 5 минут, тесты - 7 часов
    • Их надо ревьювить. Задача решается в 1 строчку и к ней три теста по 40 строк каждый
  • Они могут быть не стабильными. "Да все норм, это просто тест моргнул. Сейчас перезапущу и все ок будет"
  • Они раздражают команду. "Я только стили поправил, почему три интеграционных теста упало? Ну за что..?!"
  • Они могут быть не показательными. Все тесты зеленые, но баги все равно сыплются.
  • Их так сложно начать писать!
    • Не хватает мотивации
    • Нужно организовать инфраструктуру (как и где их запускать)
    • изучить фреймворки (... ох уж эти ваши шпионы, стабы и фейковые таймеры!)
    • понять ЧТО и КАК тестировать: сколько модульных тестов надо написать? Или может бахнуть пару интеграционных?
  • Чтобы написать изолированный тест - сойдет семь потов!
• Почему я в них души не чаю
  • Они делают мой код лучше
    • Я смотрю на свой код когда пишу тесты и начинаю замечать как его улучшить
    • Когда я продумываю тестовые кейсы я нахожу изьяны в своем коде
    • Они заставляют разбивать код на модули, каждый из которых делает только одну задачу. Это великолепно, мне больше не хочется писать код-лапшу который лежит в одном файле.
  • Тесты это лучшая документация
    • README.md в открытых проектах заполнено по разному, где то хорошо, но в основном плохо. Чтобы понять как именно работает чужая тулза я иду смотреть на тесты
    • Их не забудешь актуализировать. Если про обычную документацию можно забыть и ты не сразу спохватишься, то тесты не дадут тебе забыть о них
    • Я пишу человеческую доку по тестам, чтобы ничего не забыть
    • Это отличный TODO лист (тесты без реализации напоминают тебе о том что их пора бы реализовать при каждом запуске)
    • Они пишутся декларативно. Читаешь как предложение!
  • Они помогают мне спать спокойно
    • Не каждый проект может позволить себе ручного тестировщика. Когда я вижу зеленый шилд мне не так страшно мержить. Даже если нужно сразу катить в прод.
    • Теперь у меня нет ощущения что я что-то забыл. Если задача сделана и все тесты проходят - все в порядке.
  • Они держат команду в тонусе
    • Нельзя закоммитить абы какой код
    • Показать фан (и фен!) с ардуино
  • Интеграционный тест - это неплохой способ привести проект развернутый на деве в нужное для разработки состояние без утомительного "прокликивания" через интерфейс.
  • Обновление зависимостей
    • Пример из жизни: если я выкатываю новый бекенд и он ломает фронтовые тесты - то я уж точно незабуду всем сообщить что на беке что-то поменялось. И поменяю все нужное на фронте.
    • Обновляя стороннюю библиотеку я знаю что мой проект по-прежнему работает так как надо. Сразу, в деве, а не после выкладки.
    • Больше чем писать тесты я люблю рефакторить! И без тестов тут совсем туго.
• Как начать писать тесты
  • Mocha
    • describe / it придумать прикольный пример где это раскрывается
    • before / after each удобно но они затрудняют понимание теста
    • Три части: подготовка, действие, проверка
  • Chai
    • по умолчанию можем проверять только на true/false - показать почему не удобно
    • расширяет наши возможности
  • Практика
    • supertest - когда тестируем проект на express
    • mockery - когда хотим протестировать модуль
    • nock - когда хотим избавиться от сетевых зависимостей
• Тонкости (вишенки на торте)
  • А сколько тестов писать?
  • Сконцентрируйся на чем-то одном
  • Прежде чем чинить багу - напиши на нее тест (удобно же)
  • Нокай сетевые запросы
  • Чисти базу перед тестом
  • Экономь миллисекунды (sinon.clock)
  • все тесты в одной нотации - expexted / actual / sut
  • Запускай удобно (интеграция / skip / only )

План

1. Пример с функцией ??придумать прикольный пример?? на котором я расскажу об основах тестирования.

• mocha (+установка)
• beforeEach
• afterEach
• Отчет о тестировании - это отличная документация + TODO-list

2. "Расширяйте границы" - расскажу о том как правильно подбирать тестовые кейсы. И о том что тесты помогают взглянуть на код по другому.

• Много примеров с невалидными значениями

3. "Понятные ошибки" - расскажу о библиотеке ассертов и приведу пару примеров непонятных ошибках которые встречал на своем опыте.
4. "Пишите одинаково" - expexted / actual / sut. Тест делится на три части
5. "Стабильность - признак мастерства". Изолируйте тесты

• mockery. Нужно организовать свой код так, чтобы его легко было разбить на модули
• sinon
  • stub
  • spy
• nock

6. "Готовьтесь заранее" - про то как правильно готовить окружение

• Расскажу о том как правильно подготавливать окружение
• Запуск тестов на примере supertest

7. "Экономте время" - фейковый таймер
8. "Запускайте тесты чаще" - показать как запускать тесты

• only
• skip
• запуск из консоли
• запуск из IDE
• запуск на сохранение
• CI
• способы вывода результата используя CI

9. С чего начать

• Самое трудное сделать первый шаг
• Начните с самого простого, возможно сбазовых моделей или хелперов