Тестирование RSpec для начинающих, часть 1

Вы новичок в Rails? Новое в кодировании? Интересуетесь RSpec и как начать тестирование? Если это так, эта статья должна стать хорошей отправной точкой для вас, чтобы начать разработку через тестирование. Он объяснит вам, почему и как, и даст вам набор для выживания, который вы сможете использовать для первого теста.

темы

• В чем смысл?
• RSpec?
• Начиная
• Запуск тестов
• Основной синтаксис
• Четыре этапа испытаний
• Трудная вещь о тестировании

В чем смысл?

Для чего нужен RSpec? RSpec очень полезен на уровне модульного тестирования, тестируя более тонкие детали и бизнес-логику вашего приложения. Это означает тестирование внутренних компонентов, таких как модели и контроллеры вашего приложения. Тесты, которые охватывают ваши представления или функциональные тесты, которые имитируют более полные пользовательские потоки, такие как покупка предмета, не будут в центре внимания RSpec. RSpec не использует веб-драйвер, как, например, Capybara, который имитирует взаимодействие пользователя с реальным сайтом или его представлением.

Разработка через тестирование (TDD), какой в ​​этом смысл? Ну, это не так просто ответить, не дав вам клише. Надеюсь, это не звучит уклончиво. Я мог бы дать быстрый ответ, но я хочу избежать отправки вас домой голодным после того, как вы перекусите. Результат этой небольшой серии статей о RSpec и тестировании должен не только дать вам всю информацию для самостоятельного ответа на этот вопрос, но и предоставить вам средства и понимание, с которых можно начать тестирование, и при этом почувствовать себя немного увереннее в тестировании.

Новичкам, кажется, труднее попасть в RSpec и рабочий процесс TDD, чем начать опасно работать с Ruby или Rails. Это почему? На данный момент я могу только догадываться, но, с одной стороны, литература, в основном, ориентирована на людей, у которых уже есть некоторые навыки программирования, а с другой стороны, изучение всего, что необходимо для ясного понимания, является немного пугающе. Думаю, кривая обучения может быть довольно крутой. Для эффективного тестирования задействовано много движущихся частей. Много просить новичков, которые только начали понимать фреймворк, такой как Rails, посмотреть на процесс создания приложения с противоположной точки зрения и изучить совершенно новый API для написания кода для вашего кода.

Я думал о том, как подойти к этой «дилемме» для следующего поколения кодеров, которые просто ищут более плавного начала всего этого. Это то, что я придумал. Я расскажу вам о наиболее важном синтаксисе, не предполагая гораздо большего, чем базовые знания Ruby и немного Rails. Вместо того, чтобы охватить все возможные стороны и запутать вас до смерти, мы рассмотрим ваш базовый набор для выживания и попытаемся нарисовать более широкую картину. Мы будем обсуждать «Как?» Довольно многословно, чтобы не потерять новых кодеров на этом пути. Вторая часть уравнения будет объяснять «почему?»

Если мне повезет, у вас будет хорошая база для более продвинутых книг, и вы будете уверенны в общей картине. Хорошо, теперь давайте прогуляемся!

Преимущества и такие

Вернемся к цели тестирования. Полезно ли тестирование для написания более качественных приложений? Ну, это может быть горячо обсуждено, но в данный момент я отвечу на этот вопрос с ответом «да» — я нахожусь в лагере хипстеров TDD, я думаю. Давайте посмотрим, почему тесты предоставляют вашим приложениям пару преимуществ, которые трудно игнорировать:

Они проверяют, работает ли ваша работа как задумано. Постоянная проверка того, что вы пишете работающий код, крайне важна для здоровья вашего приложения и здоровья вашей команды.

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

Мы хотим убедиться, что приложение ведет себя определенным образом, ожидаемым образом. Тесты могут в достаточной степени убедиться в том, что способы взаимодействия пользователей с вашим приложением функционируют, и избежать сценариев ошибок, которые вы могли предвидеть. Тесты проверяют, что ваше приложение работает так, как вы его разработали, и что оно продолжает работать после внесения изменений. Это особенно важно, когда ваш набор тестов информирует вас о сбойных сценариях о реализациях вашего приложения, которые могут быть старыми и, следовательно, уже не совсем у вас в голове и не учитываться, пока вы вводите некоторые новые функции. Короче говоря, это помогает сохранить ваше приложение здоровым и избежать появления множества ошибок.

Автоматизированные тесты заставляют вас чаще тестировать. Представьте, если по какой-то причине вам нужно что-то проверить в 40-й раз. Если это займет немного времени, насколько легко будет скучно и вообще пропустить процесс? Подобные вещи — первый шаг на скользком склоне, где вы можете попрощаться с приличным процентом покрытия кода.

Тесты работают как документация. А? Спецификации, которые вы пишете, дают другим сотрудникам вашей команды возможность быстро освоить новую кодовую базу и понять, что она должна делать. Например, написание вашего кода в RSpec очень выразительно и формирует хорошо читаемые блоки кода, которые рассказывают историю, если все сделано правильно. Поскольку он может быть написан очень наглядно и в то же время является очень лаконичным предметно-ориентированным языком (DSL), RSpec поражает двух зайцев: не будучи многословным в своем API и предоставляя вам все средства для написания понятных тестовых сценариев. Это то, что мне всегда нравилось в этом, и почему я никогда не согревался с Cucumber , который, я думаю, решал ту же проблему чрезмерно дружественным для клиента способом.

Они могут минимизировать количество кода, который вы пишете. Вместо того, чтобы шутить, как сумасшедший, пробовать что-то более вольное, практика тест-драйва вашего кода позволяет вам писать только тот код, который необходим для прохождения ваших тестов. Нет лишнего кода. В будущей карьере вы часто будете слышать, что лучший код — это код, который вам не нужно писать, или что-то в этом роде. Почему? Что ж, чаще всего более элегантные решения включают в себя меньшее количество кода, а также код, который вы не пишете — что может быть ненужным — не вызовет каких-либо будущих ошибок и не требует поддержки. Итак, написание тестов в первую очередь, прежде чем писать реализацию, дает вам четкое представление о том, какую проблему вам нужно решить в следующий раз. Написание только необходимого кода, а не случайно, может быть недооцененным побочным эффектом, который TDD может предоставить вам.

Они положительно влияют на ваш дизайн. Для меня, понимание этой части включило лампочку и заставило меня действительно ценить все тестирование. Когда вы пишете свои реализации вокруг очень сфокусированных тестовых сценариев, ваш код, скорее всего, окажется гораздо более разобщенным и модульным. Поскольку мы все друзья DRY — «Не повторяйся!» — и как можно меньше связей между компонентами в вашем приложении, это простая, но эффективная дисциплина для достижения систем, которые разработаны с нуля с нуля. Этот аспект является наиболее важным преимуществом, я думаю. Да, другие тоже довольно крутые, но когда тесты также приводят к приложениям, качество которых лучше благодаря утонченному дизайну, я бы сказал, Джекпот!

Это также сводится к деньгам. Если у вас есть стабильное приложение, которое легко поддерживать и легко менять, вы в конечном итоге сэкономите немало денег. Ненужная сложность может легко преследовать проекты, и мотивация не будет на рекордно высоком уровне, когда вашей команде придется бороться с вашим кодом, потому что он хрупок и плохо спроектирован. Хороший дизайн приложения может абсолютно соответствовать вашим бизнес-целям — и наоборот. Хотите ли вы представить некоторые новые функции, которые важны для вашего бизнеса, но вы постоянно боретесь со своей архитектурой, потому что она построена на песке? Конечно, нет, и мы все видели множество примеров предприятий, которые быстро исчезли именно по этой причине. Хорошие навыки тестирования могут быть эффективной линией защиты в таких ситуациях.

Другая важная цель — это качество самого кода. Программное обеспечение, которое вы пишете, должно быть легким для понимания другими разработчиками — по крайней мере, насколько это возможно. Ваши тесты могут действительно помочь донести функциональность и цель вашего приложения — и не только другим членам команды, но и вашему будущему себе. Если вы не касаетесь определенной части своего кода в течение долгого времени, будет действительно полезно освежить вашу память о том, как и почему вы написали часть программного обеспечения с помощью документации, которую предоставляет такой инструмент, как RSpec, а RSpec делает это действительно хорошо, исключительно на самом деле.

Поскольку ваш код всегда будет меняться, рефакторинг вашего кода будет и всегда должен быть частью разработки вашего программного обеспечения. И поскольку изменения настолько запутаны в этом процессе, вам нужно убедиться, что эти изменения не вызывают неожиданных побочных эффектов в неожиданных местах. Набор тестов дает вам довольно сплоченную сеть безопасности, чтобы чувствовать себя более комфортно и свободно проводить рефакторинг с удовольствием. Этот аспект, наряду с преимуществами разработки, которые может предоставить TDD, является моим любимым преимуществом, с которым может помочь набор тестов. Модификация и расширение вашего кода — это настолько важный компонент инноваций в уже выпущенном «продукте», что вам нужен инструмент, который дает вам как можно больше свободы в этом процессе. Я не уверен, что люди, которые критически относятся к написанию обширного набора тестов, сильно обеспокоены этим аспектом.

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

В ваших приложениях, особенно если они значительно выросли, вы хотите иметь возможность доверять своему программному обеспечению. 100% покрытие кода звучит намного слаще, если у вас есть сайт, которому несколько лет, и который тронут сотнями разработчиков. Возможность доверять новому коду, который вы вводите, и опираться на него, является одним из блаженств разработки программного обеспечения, которое в дальнейшем нельзя будет купить за деньги.

Начиная

Терминал

-T позволяет пропустить Test Unit, среду тестирования, которая поставляется с Rails.

Gemfile

Терминал

После этого нам нужно запустить генератор, который поставляется с RSpec:

Терминал

Выход

Что это делает, так это устанавливает базовую структуру для ваших тестов RSpec в Rails. Как видно из приведенного выше вывода, этот генератор инициализировал каталог spec с несколькими файлами, которые понадобятся вам позже. Файл .rspec — это файл конфигурации, которым нам пока не нужно манипулировать. Я просто хотел, чтобы вы знали, что у вас перед собой. Другие файлы говорят сами за себя, но я хотел бы упомянуть их различия.

• spec_helper.rb предназначен для спецификаций, которые не зависят от Rails.
• rails_helper.rb , с другой стороны, предназначен для спецификаций, которые зависят от него.

Что не очевидно, так это то, что для запуска ваших тестов один из этих файлов необходим поверх ваших спецификационных файлов (тестовых файлов). Давайте быстро посмотрим! Когда вы генерируете модель через:

Терминал

Выход

Rails не только создаст для вас связанные файлы _spec.rb , но ваши спецификации также автоматически по умолчанию require 'rails_helper' поверх ваших файлов спецификаций. Это означает, что вы готовы к работе, прямо сейчас.

спецификации / модель / dummy_model_spec.rb

Таким образом, с помощью этой настройки вы можете протестировать свое приложение Rails, например, свои модели, и RSpec не будет запутан в отношении классов моделей, используемых в Rails. Это необходимо требовать всякий раз, когда вам нужны такие вещи, как ActiveRecord , ApplicationController и так далее. Так что это ваш нормальный сценарий и, следовательно, должен быть вашим первым логическим выбором в качестве новичка.

spec_helper.rb другой стороны, spec_helper.rb вызовет ошибку, если вы напишите тесты, включающие бизнес-логику, из вашего приложения Rails. В этом случае RSpec не будет знать, о чем вы говорите, например, когда вы хотите протестировать какую-нибудь модель Rails.

spec_helper длинная история, spec_helper не загружает Rails — вот и все! Конечно, вы можете сойти с ума с конфигурациями, но я не хочу, чтобы вы беспокоились о них прямо сейчас. Давайте сосредоточимся на основах, как выполнять тесты и синтаксис. Этого должно хватить для начала. Давайте двигаться дальше!

Запуск тестов

Вы готовы запустить свои тесты. RSpec требует, чтобы у ваших тестовых файлов был определенный суффикс, такой как _spec чтобы понять, какие файлы запускать. Если вы используете генератор, это не проблема, но если вы хотите написать тестовые файлы самостоятельно, это то, как они должны закончиться. Так что вам нужно будет поместить файл наподобие your_first_test_spec.rb в вашу директорию spec .

Использование генератора для создания фиктивной модели уже предоставило нам spec/models/dummy_model_spec.rb . Неплохо! Осталось сделать до того, как тесты будут готовы:

Терминал

Эти команды запускают миграцию для фиктивной модели, которую мы сгенерировали выше, и настраивают тестовую базу данных с этой моделью. Теперь мы фактически запускаем тест:

Терминал

Команда rake запустит все ваши тесты, полный набор тестов. Обычно вам следует использовать эту команду, когда вы завершили какую-то функцию и хотите использовать весь набор тестов.

Выход

Поздравляем! Вы только что провели свой первый тест RSpec. Не так ли плохо, не так ли? Конечно, пока это был фиктивный тест с фиктивным тестовым кодом, сгенерированным Rails. Более сфокусированная версия запуска ваших тестов — у вас на самом деле гораздо больше возможностей, чем только это — это, например, запуск отдельного файла. Как это:

Терминал

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

Другой способ проверить весь набор тестов — просто запустить rspec — с или без bundle exec, зависимости от вашей настройки.

Терминал

Еще одна вещь, которую я должен упомянуть, прежде чем мы продолжим, вы также можете запустить только определенное подмножество тестов. Допустим, вы хотите запустить все свои тесты для кода модели:

Терминал

Так просто!

Основной синтаксис

Я рекомендую начать с простых основ и рассмотреть несколько вариантов, которые RSpec предоставляет в следующих двух статьях. Давайте посмотрим на базовую структуру теста и окунемся в более сложные воды, когда мы разберемся с этим.

• describe

Это будет ваш хлеб с маслом, потому что он организует ваши спецификации. Вы можете ссылаться на сами строки или классы:

Некоторые спецификации

Разделы describe — это основные строительные блоки для организации ваших тестов в логические, согласованные группы для тестирования. По сути, область для различных частей вашего приложения, которые вы хотите протестировать.

Некоторые спецификации

Хороший совет — ужесточить свою сферу еще больше. Поскольку некоторые классы вырастут довольно значительно, не стоит иметь все методы, которые вы хотите протестировать, для одного класса в одном блоке описаний. Конечно, вы можете создать несколько таких блоков и вместо этого сфокусировать их на методах экземпляра или класса. Чтобы сделать ваше намерение более понятным, все, что вам нужно, это предоставить имени класса дополнительную строку, которая ссылается на метод, который вы хотите протестировать.

Некоторые спецификации

Таким образом, вы получаете лучшее из обоих миров. Вы помещаете связанные тесты в их репрезентативные группы, сохраняя при этом сфокусированность и приемлемый размер. Для пользователей, плохо знакомых с Ruby, я должен отметить, что # просто ссылается на метод экземпляра, а точка . зарезервировано для методов класса. Поскольку они находятся внутри строк, они не имеют здесь никаких технических последствий, но они сигнализируют о ваших намерениях другим разработчикам и вашему будущему «я». Не забывайте запятую после имени класса — без него не получится! Через минуту, когда мы expect , я покажу вам, почему этот подход очень удобен.

• it

В рамках групп describe мы используем другую область блоков. Они сделаны для реальных тестируемых примеров. Если вы хотите проверить метод экземпляра #favorite_gadget в классе Agent , он будет выглядеть следующим образом:

Некоторые спецификации

Строка, которую вы передаете в блок it служит основной документацией для вашего теста. В нем вы указываете, какое именно поведение вы хотите или ожидаете от рассматриваемого метода. Моя рекомендация — не переусердствовать и не быть слишком многословным в этом, но в то же время не быть чрезмерно загадочным и не путать других с чрезмерно умными описаниями.

Подумайте о том, что может и должно выполнить самое маленькое и простое выполнение этой части головоломки. Чем лучше вы напишите эту часть, тем лучше будет общая документация для вашего приложения. Не торопите эту часть, потому что это просто струна, которая не может нанести никакого ущерба — по крайней мере, не на поверхности.

• expect()

Теперь мы ближе к сути вещей. Этот метод позволяет проверить или подделать часть системы, которую вы хотите проверить. Давайте вернемся к нашему предыдущему примеру и увидим его в (ограниченном) действии:

Некоторые спецификации

expect() является «новым» синтаксисом утверждения RSpec. Ранее мы использовали вместо этого. Другая история, но я хотел бы упомянуть об этом на случай, если вы столкнетесь с этим. expect() ожидает, что вы предоставите ему объект и примените к нему любой тестируемый метод. Наконец, вы пишете утвержденный результат на правой стороне.

У вас есть возможность пойти положительным или отрицательным путем, например, с помощью .to eq или .not_to eq ( eq , конечно, .not_to eq равно»). Вы всегда можете изменить логику — все, что соответствует вашим потребностям. Давайте запустим этот бессмысленный тест и сосредоточимся на выводе, который мы получили в результате настройки нашего теста:

Терминал

Выход

Читается довольно хорошо, не так ли? **"Agent#favorite_gadget возвращает один элемент, а любимый гаджет agent"** говорит вам все, что вам нужно знать:

• участвующий класс
• тестируемый метод
• ожидаемый результат

Если бы мы оставили строку, описывающую метод в блоке description, результат был бы намного менее понятным и читабельным:

Некоторые спецификации

Выход

Конечно, есть и другие способы обойти и справиться с этим — например, передать эту информацию через свой блок it — но другой подход прост и работает. Конечно, что бы ни делало вашу кровь кровоточащей!

Четыре фазы теста

Лучшие практики в тестировании рекомендуют составлять наши тесты в четыре этапа:

• Испытательная установка
• тестовое упражнение
• проверка теста
• тестовый демонтаж

Эти четыре этапа в основном предназначены для удобства чтения и придания вашим тестам обычной структуры. Это так называемый шаблон тестирования, по сути, практика, которую сообщество широко признало полезной и рекомендованной. Вся эта тема шаблонов — глубокая кроличья нора, поэтому знайте, что я оставлю кучу, чтобы не запутать начинающих среди вас до смерти.

Настроить

Во время настройки вы подготавливаете сценарий, по которому должен выполняться тест. В большинстве случаев это будет включать данные, необходимые для подготовки к каким-либо упражнениям. Небольшой совет: не усложняйте вещи и устанавливайте только минимальное количество, необходимое для работы теста.

Упражнение

Эта часть на самом деле выполняет то, что вы хотите проверить в этой спецификации. Может быть так просто, как:

проверить

Теперь вы проверяете, выполняется ли ваше утверждение о проверке или нет. Таким образом, вы тестируете систему против ваших собственных ожиданий.

Срывать

Фреймворк заботится о проблемах очистки памяти и базы данных — в основном, обнуление. Там нет ничего для вас, чтобы справиться на этом этапе. Цель состоит в том, чтобы вернуть первоначальное состояние для запуска новых тестов без каких-либо сюрпризов от текущих. Давайте посмотрим, что это будет означать на фиктивном примере:

Некоторые спецификации

Как вы можете видеть, в этом примере мы разделили этапы упражнения и четко expect(agent.favorite_gadget).to eq 'Walther PKK друг друга, в то время как в других приведенных выше фиктивных примерах expect(agent.favorite_gadget).to eq 'Walther PKK , мы смешали обе фазы вместе. Оба являются действительными сценариями и имеют свое место. Кроме того, новые строки помогают визуально отделить структуру теста.

Трудная вещь о тестировании

Теперь самое сложное: что тестировать и как. На мой взгляд, именно этот аспект тестирования больше всего сбивает с толку новичков — и это понятно! Вы новичок в языке и структуре и часто даже не знаете, чего не знаете. Как вы пишете тесты для этого? Очень хороший вопрос

Я буду очень откровенен, а вы, скорее всего, не будете, и долго не будете. Освоение этого материала занимает некоторое время. Когда у вас есть наставник или вы посещаете какой-нибудь учебный лагерь и тому подобное, у вас есть возможность напрямую учиться у опытных людей. В этом случае ваш прогресс в этом отделе, конечно, будет другим.

С другой стороны, если — как и многие другие — вы учите себя этому, терпение будет ключевым. Чтение всех книг и статей, безусловно, приведет вас в правильном направлении, но я думаю, что тестирование требует много более сложных кусочков головоломки, чтобы вы имели полный смысл и, возможно, даже более важный, прежде чем вы будете чувствовать себя комфортно с ним ,

«Хорошая» новость заключается в том, что в этом нет ничего необычного, и мы все были там. Настойчивость важна. Вы можете сделать это, это не ракетостроение, но потребуется время, пока вы не сможете эффективно написать приложение с другой стороны — с точки зрения тестов, я имею в виду. Пока продолжайте настаивать, веселиться, делать ошибки, писать приложения, копировать учебники и еще много чего, пока не погаснет лампочка.

Последние мысли

Когда вы пишете свои индивидуальные тесты, вы хотите, чтобы их объекты выполняли простейшую вещь для достижения вашей цели — именно сфокусированные тесты действительно являются ключевыми. Вы хотите спроектировать свое приложение с помощью очень простых шагов, а затем следить за ошибками, которые предоставляет вам набор тестов.

Реализуйте только то, что необходимо, чтобы приложение стало зеленым. Не больше, не меньше! Это «движущая» часть в разработке, управляемой тестами. Ваша работа руководствуется потребностями ваших тестов.