Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Rspec

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

by
Length:LongLanguages:
This post is part of a series called RSpec Testing for Beginners.
RSpec Testing for Beginners, Part 2

Russian (Pусский) translation by Svetlana (you can also view the original English article)

Вы новичок в 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 в пределах Рельсов. Так как вы можете посмотреть из продукции выше, этот генератор инициализировал директорий спекуляции с несколькими файлами, которые вам будут нужны позже.  .rspec файл - конфигурационный файл, пока который нам не нужно будет манипулировать. Я только что захотел позволить вам знать, что вы имеете перед вами. Другие файлы самоочевидны, но я захотел упомянуть их отличия.

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

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

Терминал

Выход

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

Spec/Models/dummy_model_spec.RB

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

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

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

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

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

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

Терминал

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

Терминал

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

Выход

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

Терминал

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

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

Терминал

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

Терминал

Так просто!

Базовый синтаксис

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

  • Опишите

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

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

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

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

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

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

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

  • Это

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

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

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

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

  • Ожидай ()

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

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

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

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

Терминал

Выход

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

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

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

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

Выход

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

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

Лучшие практики в тестировании рекомендуют, чтобы мы составили наши тесты в четырех отличных фазах:

  •  испытательная установка
  • смотровое учение
  • испытательная проверка
  • испытательное разрушение

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

установка

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

упражнение

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

Проверяй

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

разрушение

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

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

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

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

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

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

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

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

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

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

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

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.