https://github.com/zhigalov/dump-tests-slides

Слайды доклада про тестирование приложений на DUMP
https://github.com/zhigalov/dump-tests-slides

Last synced: 2 months ago
JSON representation

Слайды доклада про тестирование приложений на DUMP

• Host: GitHub
• URL: https://github.com/zhigalov/dump-tests-slides
• Owner: Zhigalov
• Created: 2016-03-31T11:33:30.000Z (about 9 years ago)
• Default Branch: gh-pages
• Last Pushed: 2016-04-08T13:11:49.000Z (about 9 years ago)
• Last Synced: 2025-02-07T09:33:29.157Z (4 months ago)
• Language: JavaScript
• Homepage: https://zhigalov.github.com/dump-tests-slides
• Size: 10 MB
• Stars: 0
• Watchers: 3
• Forks: 1
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
# 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. С чего начать

  * Самое трудное сделать первый шаг

  * Начните с самого простого, возможно сбазовых моделей или хелперов