Итак, начнем с этого чрезвычайно практичного подхода к тестированию.

Тестирование, я должен признаться, где-то всего лишь три или четыре года назад

я принял как религию. И то, что я имею в виду, отчасти так и было: мне говорили, что это

важно, я верил, что это важно, я пытался делать это, но именно этот подход действительно изменил

мою жизнь. И я надеюсь, изменит и вашу тоже.

И нет, я не о выборах, это ни в коем случае. Итак, давайте поговорим о

юнит-тестах. В книге есть небольшая вводная о различных видах тестирования.

Мы сначала заострим внимание на юнит-тестах и немного на функциональных тестах,

и как и со многими другими темами на этих лекциях, есть удобный акроним, который поможет нам запомнить

каким должны быть хорошие юнит-тесты. Итак, для начала - они должны быть быстрыми -

т.е. не должны выполняться слишком долго; они должны быть независимыми.

Это означает, что не должно иметь значения, какой тест надо запускать первым, какой - вторым

порядок не важен. Они не должны иметь зависимостей друг от друга.

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

В некоторых случаях этого легко добиться, в других - довольно непросто.

Самоконтроль. Вот что означало тестирование не так давно для многих компаний:

Программное обеспечение перебрасывали через стену в отдел контроля качества, а там сотрудники отдела

вручную понажимают кнопочки в программе, что-то поделают в ней и - "О, оно работает, оно работает"

Но мы ведь не хотим больше этого, правда? Тест сам должен знать

прошел ли он или сломался. И чтобы принять это решение не должно требоваться человеческое вмешательство.

И, наконец, своевременность. Это означает, что тесты должны быть написаны практически одновременно

с программным кодом. Если код меняется, тесты также также должны быть изменены.

А на самом деле, мы собираемся делать это еще агрессивнее. Бы будем писать тесты в первую очередь, еще до того как будет написан код.

То есть настолько своевременно, насколько вы можете.

Итак что все это значит? Зачем нам нужны быстрые тесты?

Затем, что мы можем запускать какое-то подмножество тестов все время.

И если у нас тысячи и тысячи юнит-тестов, что не является необычным даже для проектов средних размеров,

это может занять, как вы догадываетесь, минуту или две, чтобы выполнить набор тестов и это будет нас тормозить.

Все что нам нужно - возможность быстро запускать только те тесты, которые относятся к конкретному куску кода,

над которым мы работаем таким образом, чтобы не сбиваться с ритма.

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

и в любом порядке, в каком захотим.

Поэтому, плохо, когда есть множество тестов, которые можно запускать

только тогда, когда перед ними запускали какие-либо другие тесты.

Воспроизводимость, как вы снова догадываетесь, означает что запустив тест N раз мы получим одинаковые результаты.

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

Самоконтроль: как я уже говорил, человек не должен проверять результат.

Это означает, что мы можем иметь тесты, выполняющиеся в фоне все время

и когда бы мы не внесли изменения, которые ломают что-то в 25 милях в другом участке кода,

какой-нибудь тест обнаружит это и привлечет наше внимание.

И, наконец, своевременность. Как я и говорил, мы собираемся использовать разработку через тестирование,

в которой тесты пишутся перед тем, как будет написан программный код.

Мы будем использовать RSpec, который я рассматриваю как предметно-ориентированный язык для написания тестов.

Для тех, кто не знаком с подобными языками, скажу, что в основе это вроде небольшого языка программирования

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

На самом деле мы уже видели примеры подобного языка. Миграции являются разновидностью DSL.

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

Т.о., миграции оказались DSL, который встроен в Ruby, т.е.

миграции являются всего лишь кодом на Ruby, но стилизованные под задачи, которые они выполняют.

На самом деле мы увидим, что RSpec - похожий пример. Итак, мы будем называть все подобное внутренним DSL.

Он реализован внутри другого языка. Регулярные выражения - тоже внутренний DSL.

Он как подмножество действий, которые мы можем выполнять в регулярных выражениях.

Другой пример - внешний или автономный DSL - это SQL. SQL-запросы к базам данных.

Это отдельный язык, и те, кто работали с другими фреймворками

перед тем, как перейти к Rails, обычно заканчивали тем, что писали SQL-запросы

и затем передавали кому-то, да? Так вот это очень яркий пример работы с разными языками.

Итак, в RSpec, каждый тест называется спекой - от "спецификация" (specification).

Как ни странно, они размещаются в каталоге, называемом "spec" - потому что нам нравится все делать просто.

В Rails есть генератор, "rspec:install", который создает структуру подкаталогов.

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

что мы уже выполнили эти подготовительные шаги.

Итак, с чего все начинается? Подкаталоги каталога spec организованы так, чтобы отражать структуру

нашего приложения. Так вот: в app/models у вас лежат ваши модели,

а в spec/models у вас лежат spec-файл для каждой модели. Ничего удивительного.

Подобным же образом располагаются спеки для контроллеров. А как насчет представлений (view)?

Вообще, мы не будем делать спеки для представлений. Сделать их можно, но будет это несколько

кривовато - много из того, что мы хотим проверить в представлении, на самом деле

можно проверить в контроллере, и мы увидим это в сегодняшнем примере.

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

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

Таким образом, то, что является частью представления - что должно быть видимым в представлении

и то, что может быть нажато и т.д., мы для всего этого будем использовать Cucumber.

И в дальнейшем мы так и будем поступать.

Таким образом в основном мы будем уделять внимание RSpec с точки зрения

написания спецификаций для наших моделей и контроллеров.

Итак, давайте начнем с примера новой гипотетической фичи для RottenPotatoes,

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

TMDb - реальный сайт. Он вроде IMDb, но только не коммерческий, что-то вроде open-source проекта.

Идея в том, что у них есть вся информация о фильмах, и если мы хотим

добавить фильм в RottenPotatoes, то почему бы нам просто не скачать нужную информацию оттуда?

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

"Я заполняю ключевые слова для поиска, Я хочу найти фильм "Начало",

и когда я нажимаю кнопку, мне предлагают "Искать на TMDb", не так ли?

Таким образом, предполагается, что должна быть кнопка, по нажатию которой наше приложение обратится к TMDb

и проверит, есть ли там "Начало", и если да, возьмет информацию о нем оттуда.

Вопрос в том, что мы должны сделать. Какой код нужно написать

и какой вид тестирования нужно применить.

И прежде, чем мы займемся этим, помните наш разговор о "Кулинарии Rails",

рецептах, как готовить при помощи Rails? Вспомните, что когда мы добавляем какую-либо новую фичу

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

а может и нет, новое представление. Это зависит от того, может ли эта фича использовать существующее представление

или мы должны сделать новое. Эти шаги мы должны выполнять всегда.

Итак, давайте займемся всем этим, но будем делать по одному шагу за раз.

Ладно, так. Это идея, которую мы будем видеть многократно. Я всего лишь приучаю вас к фразе

"Код, который вы бы хотели иметь." Это очень сильная мысль, как только вы к ней привыкнете.

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

Итак, мы спрашиваем себя: "Хорошо, когда пользователь нажимает на эту кнопку "Искать на TMDb", мы знаем, что

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

Так что должен делать этот метод? Что должен делать метод контроллера, когда получает форму поиска?

Если бы нас спросили об этом, и если бы мы написали, что он должен делать на разговорном языке

наш ответ звучал бы как "Ладно, смотри, он должен вызывать метод (который мы еще не написали)

который сходит на TMDb и поищет там фильм". Разумно.

"Если он там найдет фильм, он должен сформировать некоторое представление, чтобы показать результат поиска

(и снова, мы пока еще не создали это представление, но логически, это как раз то, что мы собираемся

написать)." Сегодня на третий шаг нам времени не хватит, но для неуспешного исхода сценарий таков:

"Если фильм не найден, метод должен перенаправить на главную страницу RottenPotatoes и сообщить

"Ничего не найдено". И если если вы просмотрите пример в книге,

мы на самом деле вариант неуспешного исхода проработали в главе, посвященной BDD.

Итак, у нас есть эти два момента. Сосредоточимся на №1 и №2 - это то, что метод контроллера должен делать,

и вот как мы будем это описывать. Где моя мышь? Итак, поехали.

Рассмотрим, как мы опишем все эти требования при помощи RSpec. Итак...

Ничего особенного здесь ни происходит, видите. Все достаточно просто, не так ли?

И это корректный код RSpec. SpecHelper - это просто файл, который RSpec создает как часть шага установки.

Он просто выполняет кое-какие вещи, гарантирующие, что все необходимое подгружено.

И собираемся начать, спросив "Что должен проверять этот тест?"

Или, мы собираемся описать поведение MoviesController.

У контроллера есть много вариантов поведения, но нас волнует одно конкретное, а именно

поведение во время поиска на TMDb. Итак, мы можем представить, для каждого поведения в контроллере

как растет наша спека, мы будем добавлять больше описательных блоков внутри этого внешнего

"describe MoviesController", и так далее вкладывать, вкладывать, вкладывать.

Все, что я здесь сделал - это переписал те три требования, о которых мы говорили.

Итак, "it" - это на самом деле вызов метода в RSpec. Он принимает аргумент, который является

строкой, описывающий, что должно произойти. И как мы увидим,

он принимает также второй аргумент, который является процедурой, которая и выполняет тест.

Но пока, все что мы сделали - лишь сделали перевод. Мы обдумали три требования

которые должен удовлетворять контроллер, и мы написали эти три требования в RSpec.

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

Он соответствует главе книги и в нем как раз все это делается.

Все, что он делает - запускает три теста, которые ничего не делают. Поэтом вывод RSpec желтый, да?

Желтый означает "еще не реализовано", точно как и в Cucumber.