Classic Season 3

Добро пожаловать в третью серию скринкастов Classic Season 3. Эта серия получилась почти полностью одержимой TDD. Мы будем делать тесты, разбирать много чего по полочкам, ну и конечно делать рефакторинг и еще раз рефакторинг. Присоединяйтесь.

Обзор скринкастов Classic Season 3:

• Что происходит в Active Records
  Несколько скринкастов говорили о перемещении логики из моделей и в голые классы Ruby, но что мы должны оставить в моделях ActiveRecord? Вот что мы рассмотрим здесь: прогулка по типам методов, которые принадлежат к AR-моделям, и почему они там присутствуют.
• Что происходит в Active Records Часть 2
  Во второй части этой серии мы фактически удалим различные части модели, которые не принадлежат ей, как показано в части 1. Большая часть времени будет потрачена на удаление двух обратных вызовов ActiveRecord, заменив их классом который находится между контроллером и моделью, опосредуя жизненный цикл объектов API User и Braintree. Мы также кратко заменим два других метода реализацией вне класса ActiveRecord.
• Вне TDD: Stubs против Stash
  При выполнении TDD снаружи, заглушки являются нормой. Сначала мы создаем внешний класс, ограничивая его зависимости, которые возможно еще не существуют. Эти заглушки говорят нам, каким должен быть интерфейс следующего слоя; это то, как TDD управляет дизайном. Однако, когда мы не изолируем наши тесты, мы не можем этого сделать. Мы все еще можем начать вверху, но мы не можем пройти тест без реальной реализации. Это может привести к большим, громоздким обязательствам. Мы рассмотрим, как избежать этих больших коммитов с помощью git stash, а затем сравнить результаты внешнего TDD с заглушками и внешним TDD с помощью stash.
• Веб-приложения: когда тестировать в изоляции
  С 40 скринкастами в каталоге, многие из которых обсуждают тестирование, теперь у нас достаточно контекста, чтобы говорить о том, когда тестировать изолированно и когда интегрироваться. Это сводится к одному главному вопросу: кому принадлежат интерфейсы, от которых вы зависите? Мы рассмотрим основные компоненты в современном веб-приложении, рассматривая, почему каждый из них может быть протестирован изолированно или нет, или почему они находятся где-то между этими крайностями.
• Untested Code Part 1: Introduction
  Это часть первая из трех частей, посвященных работе с устаревшим кодом. Мы начнем с полностью непроверенного контроллера Rails, разместим тесты вокруг него, которые охватывают все случаи, а затем извлекут фрагменты кода безопасно с помощью тестов, одновременно подталкивая тесты к более низким уровням изоляции. В этом скринкасте мы вводим код и пытаемся создать исчерпывающий список ожидающих контекстов RSpec и примеров.
• Untested Code Part 2: Adding Tests
  В части 2 этой серии мы пишем фактические тесты для структуры контекста, которые мы обнаружили в первой части. По пути мы проверим, что каждый тест на самом деле проверяет, нарушая код очень маленьким способом, чтобы увидеть  сбой. (В идеале это может привести к сбою каждый раз, некоторые тесты ошибок позволяют проскальзывать ради скорости.) (Блок response_to, используемый в этом скринкасте, может быть заменен на `post: foo,: id => 12,: format =>: js`, оставив производственный код без изменений.)
• Untested Code Part 3: Refactoring 1
  Теперь, когда у нас есть тесты, мы можем наконец делать рефакторинг! Мы сделаем небольшую очистку в структуре действия контроллера, а затем извлечем некоторую модельную логику в новый модельный метод. Во время процесса мы будем распутывать логику поиска книг из логики добавления книги. Это позволит нам извлечь логику поиска книг в часть 4, уменьшив контроллер до очень маленького кода.
• Untested Code Part 4: Refactoring 2
  В заключительной части этой серии мы вытаскиваем большой кусок кода из контроллера, перемещая его в свой класс. Этот класс тестируется изолированно, используя тесты интеграции контроллера в качестве руководства. Несмотря на это, один из тестов отличается сложнотой, поэтому мы делаем небольшое изменение дизайна, чтобы упростить его. Наконец, мы отступаем и смотрим на окончательный набор тестов, которые мы создали.
• Emacs, Chainsaw of Chainsaws
  Большинство скринкастов Destroy All Software использовали Vim, поэтому давайте немного поразмышляем над Emacs, другим «One True Editor». Мы рассмотрим некоторые мои настройки из моего прошлого как пользователя Emacs, а также некоторые функции, которые я пропускаю, когда я нахожусь в Vim. (После публикации Авди Гримм напомнил мне «Зло», в котором вы можете попробовать улучшить эмуляцию Vim в Emacs.).
• Stubbing Unloaded Dependencies
  Написание быстрых тестов часто означает тестирование без загрузки остальной части приложения. Когда вы хотите заглушить метод в классе, который не загружен, как вы это делаете? Есть много способов, и здесь мы быстро рассмотрим пять из них, четыре из которых не имеют никакого влияния на производительность теста.
  
  Примечание. После публикации этого скринкаста RSpec получила функцию «stub_const». Использование этого, как правило, проще, чем создание пустого класса, но дает аналогичные результаты. Компромиссы немного отличаются от подхода с пустым классом, но почти все рассуждения в этом скринкасте сохраняются.
• Brittle and Fragile Tests
  Термины «Brittle» и «Fragile» бросаются вокруг: сторонники интеграционных тестов утверждают, что Brittle хрупка; сторонники Fragile заявляют об обратном. Оказывается, они оба правы, и мы посмотрим, почему, а затем закончим с рассмотрением, возможно, неправильным использованием терминов применительно к действительно изолированным тестам.
• Repository Statistics in Raptor
  Мы пересматриваем старую тему: вычисляем статистику по репозиторию. На этот раз у нас есть конкретный пример, взятый из веб-фреймворка Raptor, который имеет свой собственный скрипт статистики, который приводит к очень подробным графикам. По пути мы увидим некоторые детали оболочки, включая некоторые запутывающие действия из встроенного `time`. Сценарий статистики Raptor и сценарий run-command-on-git-revisions доступны, если вы хотите попробовать их.
• Generating Coupons With Bash
  Коды купонов Destroy All Software, каждый из которых состоит из трех случайных слов Unix, таких как «ls ruby fi». Мы построим скрипт генерации купона с нуля. Он начинается со списка man-страниц в главной системе и превращает их в случайные трехсловные коды купонов. Хотя сценарий - это по сути одна длинная цепочка pipes, мы позаботимся о том, чтобы все названия и структуры были удобными для чтения.
• Shorter Class Syntax
  Насколько кратким может быть определение класса Ruby без изменения языка или влияния на читаемость? Мы сделаем это выстрелом в этом скринкасте, на удивление легко превратить шесть строк декларации в два. Полученный хелпер-код был очищен, удалены его обезьяны и доступен как gem.
• When to Generalize in TDD
  Когда тест TDD терпит неудачу, вы можете часто пропускать его с помощью «sliming»: заставить рассматриваемый метод вернуть твердое значение, а не вычислять ответ «правильным» способом. Вы пишете этот сокращенный код, когда вы должны обобщить его на полную реализацию, и когда вы должны написать еще один тест, чтобы заставить обобщение? Мы рассмотрим некоторые конкретные случаи, когда я перехожу прямо к обобщению.
• The .vimrc
  По многочисленным просьбам мы поговорим о поездке через мой .vimrc-файл,  не по очереди, но посмотрим на самые интересные части, которые вы можете украсть. Мы увидим перегрузку ключа табуляции, настройки, чтобы облегчить грубые края синтаксиса Ruby, и моя система для запуска только тех тестов, которые необходимы. Мой vimrc находится на GitHub, также как и упомянутый тестовый плагин.
• Pushing Complexity Down
  Вытеснение сложности до более низких уровней - это общий рефакторинг. Мы создадим во время TDD небольшой класс для работы, а затем посмотрим на два способа подталкивания определенного условного вниз на более низкий уровень. Один из них приведет к гораздо лучшему дизайну, чем к другому. Это показывает, что просто нажимать вниз недостаточно; иногда это просто перерисовывает линии в том же плохом дизайне.
• Three Test Shapes
  При проведении тестов, они имеют тенденцию неоднократно формировать несколько согласованных форм. На этот раз мы рассмотрим три основные формы теста, которые имеют отношение к изменчивости: неизменность, локальная мутация и глобальная мутация (или, что эквивалентно: неразрушающий, локально разрушительный и глобально разрушительный). Затем мы рассмотрим три способа, с помощью которых эти тесты могут пойти не так, будучи одержимыми реализацией.