Как начать писать тесты за 10 шагов по 10 минут
Дайте-ка угадаю: вы согласны с тем, что писать тесты — это хорошо. Это повышает надежность системы, ускоряет разработку, проект с хорошим тестовым покрытием поддерживать легко и приятно, а TDD — это вообще почти идеал процесса разработки. Но не у вас в проекте. То есть, оно клёво, но, к сожалению, сейчас столько работы — просто завал. Куча задач, одних только критических багов — два десятка, плюс надо срочно дописать этот модуль и еще написать письмо заказчику… Так что тесты, наверное, будем прикручивать уже в конце, если время останется. Или в следующем проекте. Нет, ну там точно полегче будет. Скорее всего.
Как, узнали ситуацию?
Так вот — чушь всё это. Сфера ИТ — бесконечна, как вселенная, куча работы будет всегда. Можно или начать писать тесты прямо сейчас, или не сделать этого никогда. Я тут набросал короткий план, как начать это делать за 10 шагов, по шагу в день, по 10 минут на шаг. И когда я говорю «10 минут» я имею в виду не «3 с половиной часа» и не «ну сколько-то времени, лучше побольше», а именно 600 секунд. Если у вас нету в день 600 секунд свободного времени — срочно меняйте проект, работу, профессию, страну проживания (нужное подчеркнуть), потому что это не жизнь, а каторга какая-то. Поехали.
1. Выбираем фреймворк для тестов
Не вздумайте начинать писать собственный фреймворк с нуля — оно вам надо? Тратить неделю на выбор оптимального фреймворка (да, я видел такую оценку времени на это в планах) — тоже глупо. Вот вам рецепт: набирайте в Гугле best test framework for %language% site:stackoverflow.com. Открываете первые 5 ссылок. Закрываете те из них, где рейтинг вопроса или первого ответа около нуля. Из оставшихся вкладок можно смело брать любой рекомендованный фреймворк из первой тройки с максимальным рейтингом. С вероятностью в 99.5% он вам подойдет. Поскольку на данный шаг вы пока потратили минуты 3, то оставшиеся 7 можно потратить на то, чтобы перейти на сайт фреймворка и посмотреть примеры его использования. Скорее всего, там всё будет просто и понятно (иначе он не был бы в топе рекомендаций). Но если вдруг нет — выберите другой по тому же алгоритму.
2. Пишем Hello world!
Во-вторых, вынесем написанные функции куда-нибудь из данного файла. В зависимости от подхода и применяемого языка это могут быть просто отдельные файлы кода или библиотека. Это нужно для того, чтобы потом эти функции вызывать из тестов.
У нас будет так:
3. Подключаем фреймворк к Hello world!
О подключении фреймворка к проекту наверняка очень хорошо написано на сайте фреймворка. Или на stackoverflow. Или на Хабре. Вот я, к примеру, когда-то описывал подключение Google Test. Обычно всё сводится к созданию нового проекта консольного исполняемого приложения (в скриптовых языках — отдельного скрипта), подключению к нему фрейворка парой include (import\using), подключению к проекту тестируемого кода (включением самих файлов с кодом или подключением библиотеки) — ну и всё. Если вы не верите, что этот шаг можно сделать за 10 минут — откройте Youtube, напишите в поиск название своего фреймворка и пронаблюдайте 20 видеороликов примерно одинакового содержимого, которые это доказывают.
4. Разбираемся с возможностями фреймворка
Для начала нам нужно выяснить:
- Как написать один юнит-тест
- Как запустить юнит-тесты
На эти вопросы обычно отвечают все те же самые статьи, о которых я говорил выше. Не лезьте сразу в дебри фреймворка. Начните с простых тестов, которые проверяют простые вещи. Тут ведь как в спорте — не надо сразу рвать большой вес, нужно сначала поставить правильную технику.
Вот, к примеру, пару тестов для нашего Hello world! на упомянутом выше Google Test:
5. Подключаем фреймворк к настоящему проекту
Мы уже умеем подключать фреймворк к проекту. Помните, делали на шаге №3? Всё получилось. Теперь давайте сделаем это для боевого проекта. Положите все необходимые файлы фреймворка себе под SVN\Git\TFS\чего-у-вас-там. Сделайте тестовый проект. Подключите к нему фреймворк. Включите сборку тестового проект в процесс сборки вашего продукта. Проверьте сборку в дебаг и релиз-конфигурациях. Комитните тестовый проект, запустите сборку на билд-сервере. Всё должно быть ок. Не нагружайте пока ваших коллег появлением тестового проекта — во-первых, вы ничего не сломали, во-вторых, хвастаться вам тоже пока нечем.
6. Тестируем что-нибудь простое
Вы помните, каким образом мы выше вынесли из Hello world! часть функционала во внешний код? Обратите внимание, какими получились эти функции: они не зависят ни от глобальных переменных, ни от состояния каких-то объектов, ни от внешних данных из файлов или баз данных. Резальтат зависит только от переданных аргументов. Найдите в своём проекте что-то аналогичное. Наверняка ведь у вас есть какие-нибудь функции конвертации чего-то куда-то, сериализации\десериализации, упаковки\распаковки, шифрования\дешифрования и т.д. Не думайте пока о том, насколько нужный и полезный функционал вы тестируете. Ваша задача — написать простой тест, но для боевого проекта. Запустить, увидеть «1 тест успешно пройден».
Кстати, именно на этом этапе очень часто к скептикам приходит озарения. Вдруг оказывается, что самый простой тест, на самую элементарную функциональность — вдруг провалился. Лезем в код — и вдруг находим что-то типа
И оказывается, что основной код просто пока вызывал эту функцию с такими аргументами, что всё было ок, но в любой момент это могло измениться.
7. Тестируем что-нибудь посложнее
Вы уже умеете тестировать простые вещи. Теперь разберитесь как тестировать что-то, имеющее внешние зависимости. Посмотрите, как ваш фреймворк предлагает делать подготовку к запуску теста и очистку после него. Разберитесь, что такое моки и стабы. Подумайте как протестировать какой-нибудь ваш код, читающий данные из файла или из базы. Легко ли подменить источник входных данных? Может быть стоит слегка изменить код, чтобы это стало легче? Сделайте это, если нужно. Напишите для этого кода тест.
8. Пишем тест на баг
Как обычно выглядит ваша работа над багом? Вы берёте его из багтрекера, пробуете воспроизвести, если не получается — возвращаете тестеру, если получается, занимаетесь отладкой для понимания его местоположения, находите кусок кода с ошибкой, исправляете, тестируете, отдаёте тестеру. Отлично. А теперь попробуйте при работе над следующим багом между шагами «находите ошибку» и «исправляете» добавить ещё один шаг — написать тест на эту ошибку. Такой, чтобы он падал для текущего кода. Это огромное кайф, исправить код — и не лезть тестировать его руками, а запустить падавший пару минут назад тест и увидеть «успешно» на его выходе. Кроме этого эстетического удовольствия, этот тест можно отдать тестеру и использовать в дальнейшем для регрессионного тестирования (а ещё — для тестирования побочных веток продукта, проекта «в поле», и т.д.). Конечно, не всё и не всегда можно так протестировать, бывает тяжело с UI, с кроссбраузерностью, с многопоточностью. Не заморачивайтесь в случае, если написание теста займёт у вас много-много часов. В конце-концов, эта технология ведь призвана облегчить вашу жизнь, а не заставить плясать под свою дудку.
9. Первый раз TDD
Как обычно выглядит ваша работа при разработке нового функционала? Наверное, вы сначала думаете. Потом проектируете то, что будете делать — набрасываете названия интерфейсов, классов, потом названия методов, наполняете их реализацией, запускаете, отлаживаете. Отлично, менять почти ничего не надо. Просто в тот момент, когда у вас уже есть интерфейсы, классы и названия методов, но еще нет их реализации — напишите для них тесты. Простенькие — вызвали метод — проверили результат. Обратите внимание, как уже на этом этапе вы заметите нелогичность некоторых имён, недостаток или излишество аргументов в методах, ненужные или отсутствующие зависимости и т.д.. При этом сейчас пока что это исправить — почти ничего не стоит (ведь реализация ещё не написана). Подправили архитектуру, дописали тесты, запустили — увидели кучу проваленных тестов. Отлично, так и должно быть. Написали реализацию, запустили тесты — увидели большинство из них пройденными, исправили ошибки, добились успешного прохождения всех тестов — отлично, дело сделано. Вы чувствуете, как хорошо стало, какое моральное удовлетворение вы получили? Оно слегка напоминает удовольствие от получения какой-то ачивки в игре. А почему? А потому, что его можно измерить! «Код проходит 18 тестов при тестовом покрытии в 90%» — это звучит круче, намного круче чем «ну, фича вроде бы реализована, я так потыкал немножко, кажется, не падает». Это даёт право гордится. Идешь домой — и чётко понимаешь, что-то за день сделал полезное, это «что-то» измеримо, ощутимо, реально.
10. Прикручиваем запуск тестов к CI-серверу
В тестах мало смысла, если их не запускать. Запускать их вручную — долго и бессмысленно. Наверняка у вас есть билд-сервер с каким-нибудь TeamCity или CruiseControl, где собирается ваш продукт. Так вот, большинство хороших билд-серверов сразу, из коробки, поддерживают запуск тестов и даже парсят их логи и рисуют красивые отчёты. Соответствие тут, конечно, не «все совместимы со всеми», но если вы взяли тестовый фреймворк по совету в начале статьи — шансы на то, что всё заработает очень высоки. К примеру, упомянутые мною TeamCity и Google Test прекрасно дружат между собой.
Послесловие
Дотошный читатель может заметить, что пункты начиная где-то с седьмого-восьмого скорее всего не впишутся в заявленные в заголовке «10 минут на шаг». Что тут можно сказать? Считайте, что я, нехороший человек, вас слегка наколол. Однако, если вы на практике с праведным негодованием прошли эти пункты, то:
- У вас уже есть проект, к которому прикручены тесты. Они запускаются, работают, их больше нуля и они уже приносят вам пользу.
- Вы получили опыт во всём этом деле.
- Во второй раз у вас получится серьёзно быстрее.
Вот и решайте, стоило оно того или нет.
Где-то пункта после 8-го — хорошее время чтобы представить тестовый проект вашей команде. Объясните в 2-3 абзаца что и как, покажите простенький пример теста, заметьте, что, мол, «feel free to add your own tests», но особо не напирайте пока. Если у вас писать тесты было не принято, скорее всего первым впечатлением будет осторожный скепсис и непонимание. Это быстро лечится после второго-третьего упоминания на совещании о том, что, мол «а этот баг мы нашли благодаря тесту» или «а вот тут написан тест и мы сразу узнаем, если оно сломается снова». Программисты — народ рациональный, они поймут и подтянутся.
Источник
Как сделать хороший тест: 10 правил
А еще примеры и шаблоны
Содержание
Как только у вас родилась идея теста, сформулируйте черновой заголовок. Во-первых , если короткий и понятный заголовок не будет получаться, то это признак, что с вашей идеей что-то не так или тема для теста слишком сложная, — это повод доработать идею. Во-вторых , так вам будет проще понять, о чем именно будет тест. Это поможет определиться с тем, как лучше всего выстроить тест с точки зрения логики, какие именно нужны вопросы и результаты, и отсечь все лишнее. Лучше всего, когда в заголовке есть вопрос и читатель хочет узнать на него ответ. Еще лучше, когда заголовок касается конкретно человека и мы предлагаем узнать читателю что-то о себе: все любят узнавать себя.
Наверняка вы не хотите делать тест ради теста. А хотите чего-то большего:
- донести до читателей определенную мысль;
- достичь своих целей.
С первым все ясно: читатель должен пройти тест и узнать что-то новое или о чем-то задуматься. Например, о своих личных предпочтениях или о том, как на самом деле устроена жизнь вокруг:
Со вторым тоже все просто. Цель может быть прикладной — например, мы хотим ненавязчиво рассказать о нашем курсе по инвестициям. Тут все понятно: на заголовок кликают люди, которые интересуются темой и хотят узнать про себя что-то новое. Получают развлекательный контент и в конце узнают о курсе.
Или, наоборот, цель может быть более призрачной — например, нам важно писать про бизнес. У нас есть целый раздел про это, мы хотим подогревать интерес к теме разными способами: тот, кому пока скучно читать длинный текст, возможно, клюнет на что-то развлекательное. Скорее всего, человеку выпадет хороший результат, мы заложим в его голову идею, и, вероятно, в следующий раз он уже созреет для более серьезных форматов.
Чтобы результаты теста выглядели убедительно, нужно придумать, на чем именно будут основаны ваши расчеты. Вам может казаться, что вы делаете максимально шуточный тест и придумывать какое-то обоснование необязательно. Но чаще всего это заметно, и у читателей возникнут вопросы:
В некоторых тестах результат можно выдавать рандомно. Подумайте, насколько такое решение уместно в конкретном тесте: оно должно выглядеть как фича, а не баг.
Примеры разных видов логики:
- «Какой вы миллиардер из кино?» — мы взяли список богатейших выдуманных персонажей «Форбса», выбрали из них киногероев, изучили их биографии, нашли пересекающиеся моменты и спрашиваем у человека, какая из описанных ситуаций больше похожа на его. В результатах рассказываем читателю краткую сводку о персонаже, с чьей биографией было больше всего пересечений, сумму его состояния и выделяем положительные свойства характера.
- « Относитесь ли вы к среднему классу?» — лучше всего, когда тест опирается на проверенный источник, будь то соцопрос или список «Форбса». В этом случае мы взяли несколько исследований, посвященных среднему классу, и сделали из них тест. Еще в тестах с такой логикой можно предлагать читателю проверить, насколько хорошо он разбирается в какой-то теме. Например, в зарплатах россиян или их мнениях по самым разным поводам.
- « Знаете ли вы, как супермаркеты нарушают ваши права?» — пример полезного теста на тему конкретной проблемы. Мы собрали случаи супермаркетного произвола, нашли законодательные акты, регулирующие эти ситуации, и предлагаем читателям рассказать, как бы в этих ситуациях они себя повели, и заодно узнать, на чьей стороне закон.
- «Финансовые предсказания: что вас ждет в следующем году?» — здесь результаты как раз распределяются более-менее рандомно, цель таких тестов — порадовать читателя, сказать ему что-то приятное, подбодрить. Но логика в распределении результатов все равно присутствует.
Бывают тесты, в которых главное — результаты. Бывают тесты, в которых главное — вопросы. Здесь важно продумать, как правильно расставить акценты, чтобы и читатель был доволен, и вы рассказали людям все, о чем хотели.
- «Насколько хорошо вы питаетесь по сравнению с другими россиянами?» — в этом тесте важны вопросы. По сути, мы интерактивным способом рассказываем человеку о том, что известно статистике о пищевых пристрастиях россиян. Поэтому после ответа на вопрос мы даем уточняющую расшифровку и ссылку на источник. Обязательно собирайте все пруфы!
- «Какой страны вы достойны?» — а в этом тесте интереснее результат. Мы собрали 5 профайлов разных стран, основываясь на статистике, реальных ценах и культурных особенностях. Спрашиваем читателей об их предпочтениях, вкусах и привычках и делаем вывод, где условия для всего этого благоприятнее.
10 вопросов всегда лучше, чем 15, а 7 — лучше, чем 10. Можно пойти еще дальше и сделать тест из двух вопросов — и даже из одного! Все зависит от цели и от того, что в вашем тесте главное, — не стоит прятать это слишком далеко.
Также старайтесь соблюдать баланс: если вопросов много, то пусть и вопросы, и варианты ответов будут максимально короткими. Если вопросов мало, то можно себе позволить сделать вопросы или варианты ответов подлиннее. Варианты с картинками выбирать проще, даже если на этих картинках написан текст. Конечно, это не всегда возможно. Просто помните об этом и стремитесь к идеалу.
Старайтесь формулировать вопросы емко, убирайте лишние подробности. Избегайте длинных придаточных и громоздких фраз. Ваш вопрос должен быть понятным и конкретным.
В идеальном мире текст результата всегда должен отвечать на вопрос в заголовке. Человек заинтересовался вопросом в заголовке и хочет получить на него ответ. А если ответа нет, то, вполне вероятно, человека постигнет разочарование. Это не те эмоции, которые нужно получать от тестов.
Желание увидеть результат — это главное, почему человек проходит наш тест. Проходить тест трудно. Нужно думать, читать и нажимать на кнопки. Кнопок бывает много: узнать правильный ответ, перейти к следующему вопросу, узнать результат. Это активное потребление контента. Поэтому в тестах результат — это награда. Если человек получит слишком короткий или неинтересный результат, он также будет разочарован. У него останется ощущение, что результат не стоил затраченных усилий. Поэтому к результатам надо отнестись внимательно и сделать их с любовью.
Если человек получил удовольствие от прохождения теста и от его результата, он становится довольно лояльным пользователем и благосклонно отнесется к нашему предложению продолжить вечеринку. Поэтому при создании теста мы сразу думаем о том, что еще предложить читателю. Мы можем предложить пройти еще один тест или прочитать текст по теме. В каждом результате может быть что-то уникальное: например, если человек показал слабый уровень знаний по какому-то предмету, мы можем отправить его читать про азы, а если высокий — проходить более сложный тест. Или во всех результатах может быть ссылка на что-то одно. Все зависит от цели.
- «Какой ваш финансовый возраст?» — здесь в каждом из восьми вариантов результатов читателю предлагаются разные тесты в зависимости от контекста.
- «В какую теплую страну вам пора переехать?» — здесь мы сопроводили каждый результат ссылкой на статью про конкретную страну.
- «Какой вы модератор Т—Ж ?» — здесь тоже восемь вариантов результатов, но в рекомендациях — один и тот же тест.
Тесты — это развлекательный формат. Возможно, читателю скучно и он хочет развлечь себя. Возможно, у читателя был тяжелый день и он хочет отвлечься. Но он точно не хочет прочитать что-то неприятное про себя. Поэтому старайтесь даже в самых плохих результатах описывать недостатки мягко, упоминайте возможные сильные стороны и добавляйте во все это самоиронии и дружеского подмигивания.
Помните, что и механики тестов, и сама концепция таких тестов построены на допущениях — мы даем очень приблизительный результат. Кроме того, продумать абсолютно все довольно тяжело и весьма вероятно, что где-то в вашей логике найдется слабое место. Поэтому нужно максимально застраховать себя от провалов. Если вы сами чувствуете, что халтурите или чересчур притягиваете нечто за уши, убирайте: это однозначно заметят.
Используйте слова: «возможно», «вероятно», «кажется» и так далее. Старайтесь не упоминать в результатах конкретные вещи, если механика теста не гарантирует вам, что читатель выбрал определенный результат. Зачастую бывает так: один из вариантов ответа — «обожаю хот-доги», читатель фыркает про себя, выбирает другой ответ, но по ответам в других вопросах оказывается, что он должен основать компанию по производству сосисок. Поэтому результат нужно завуалировать таким образом, чтобы даже тем, кто не любит хот-доги, было понятно, почему им выпал такой результат. Добавляйте в описание результата примеры не из вопросов, а другие, из жизни, которые расширяют картину.
Помните, что правила созданы, чтобы их нарушать. Если вы понимаете, что какое-то правило противоречит вашей идее или цели, и вы знаете, как сделать лучше, — делайте. Но сначала согласуйте все с редактором: возможно, он уже сталкивался с подобным и знает, как поступить, или просто поможет найти решение.
Виды тестов
Тесты-квизы: с правильными и неправильными ответами:
Источник
