Classic Season 2

Формально это продолжения первого сезона. В этой серии мы рассмотрим много тем, в том числе: Изолированные модульные тесты, будем делать рефакторинг, вспомним о VIM и его возможностях, о которых вы могли еще не знать, поговорим о производительности и тестировании и много другого. Присоединяйтесь, будет интересно.

Обзор уроков Classic Season 2

• 1. Composing a Unix Command Line
  Мы видели много команд Unix, но никогда не переставали говорить о создании большой команды. Это то, что мы сделаем в этом скринкасте: мы разрешим проблему с помощью большой одноразовой команды, но цель - подумать о самой команде. По пути мы увидим большинство утилит, необходимых для обработки текста в Unix. Если вы изучите каждый из них, вы сможете хорошо управлять текстовыми потоками.
• 2. Tar, Fork, and the Tar Pipe
  pipe tar - моя любимая команда Unix. Она объединяет несколько важных концепций Unix вокруг файлов, подпроцессов и межпроцессного взаимодействия всего несколькими символами. Мы рассмотрим pipe tar и то что он делает, а затем погрузимься в то что делает оболочка, чтобы заставить ее работать, включая разветвление и создание pipes. Мы также рассмотрим некоторые сырые данные tar, с которыми вы редко встречаетесь.
• 3. Coupling and Abstraction
  Связывание и абстракция тесно связаны: путем введения метода для подтверждения абстракции вы естественно уменьшаете связь между двумя классами. Мы рассмотрим это с помощью простого примера модели / контроллера, а также случая, когда ситуация не так проста: вызов метода, который выглядит как хорошая, простая абстракция, но на самом деле опасен, потому что он сторонний.
• 4. Test Isolation and Refactoring
  Изолированные модульные тесты имеют много преимуществ, но один из недостатков - потеря уверенности в интегрированной системе. При высоких уровнях изоляции у вас отсутствует механизм обратной связи для изучения того, что части фактически не работают вместе: например, они вызывают неправильные методы или называют их неправильным количеством аргументов. Это может сделать рефакторинг с изолированными тестами страшным. В этом скринкасте мы рассмотрим технику, используемую в качестве первой линии обороны. Это гибрид между полностью изолированным модульным тестированием и медленным, дорогостоящим интеграционным тестированием.
• 5. Spiking and Continuous Spiking
  В этом скринкасте мы рассмотрим пикирование и в частности идею «непрерывного пикирования»: вместо того, чтобы выбросить код, перевести его в производственный код TDD итеративно. Это опасная практика, но осторожность может помочь вам в неясных частях разработки вашего приложения.
• 6. Notes on Stubbing
  В этом скринкасте мы смотрим только на stubbing. Мы рассмотрим три темы: разница между случайными и существенными взаимодействиями; метод тестирования миксинов без зависимости от класса, в который их смешивают; и создание более целенаправленных тестовых примеров.
• 7. Controller Refactoring Demo Part 1
  Это первый из двух скринкастов, показывающий живой рефакторинг большого метода контроллера. В первой части мы разбиваем метод на более мелкие методы, чтобы лучше понять его. Во второй половине мы будем рассуждать об этих небольших кусках, находить для них хорошие имена и прояснять. Конечные цели - это небольшие, понятные методы, лучшие имена, уменьшенные returns, условные обозначения и другие структуры управления и лучшее разъяснение намерений.
• 8. Controller Refactoring Demo Part 2 
  Это второй из двух скринкастов, показывающий живой рефакторинг большого метода контроллера. В этой половине мы пытаемся улучшить имена всех наших новых методов, по крайней мере, немного. По пути мы извлекаем еще более мелкозернистые методы. В конце мы рассмотрим, как нарушение этого класса позволяет легко перемещать код из контроллера и в другие классы. Окончательная версия класса доступна , если вы хотите просмотреть ее.
• 9. Extracting From Controller to Model
  Это продолжение серии рефакторинга контроллеров. Здесь мы выходим за пределы самого контроллера, перемещая в модель небольшие кусочки модельного запроса и логики. Это уточняет намерение контроллера, предоставляет точки для повторного использования и упрощает тестирование как контроллера, так и недавно извлеченных методов модели.
• 10. Acceptance Tests
  В этом обзоре мы рассматриваем Cucumber для написания приемочных тестов высокого уровня с примерами, взятыми из набора Destroy All Software. Мы коснемся названий шагов и абстрактного / подробного разделения функций и шагов, а также некоторых рекомендаций по производительности и примечаний о браузерах.
• 11. Extracting From Models
  Возвращаясь к ChiliProject, мы теперь извлекаем некоторую логику приложения из модели в некоторые голые классы в lib. Это приводит к удалению кода из модели, централизации знаний, устранению дублирования и предоставлению точек для повторного использования. Метод, отмеченный как «"This method [...] is to be kept as is"» сделаем рефакторинг. (Я уверен, все будет хорошо!)
• 12. Some Vim Tips
  Это скринкаст полный советов по изучению Vim. Они варьируются от вводных (как я могу научиться эффективно использовать Vim?) до конкретных вопросов, которые мне задают (какие плагины я использую?) а также для продвинутых (как мне следует использовать мое использование плагинов для максимальной скорости?). Мы также касаемся цветовых схем пару раз: моя цветовая схема grb256, основанная на ir_black (доступна на GitHub ) и Solarized , что является более тонким выбором.
• 13. History Spelunking With Unix
  В этом скринкасте мы еще раз проанализируем историю репозитория git. На этот раз, тем не менее, мы идем дальше: сначала создаем диаграмму, показывающую тестовую продолжительность выполнения изменений, используя только командную строку. Затем мы сосредоточимся на внезапном изменении времени выполнения, которое показывает диаграмма, перепрофилирование git bisect, чтобы git обнаружил фиксацию, которая вызвала изменение автоматически.
• 14. Performance of Different Test Sizes
  На этот раз мы анализируем время выполнения тестирования небольшой части поведения на четырех разных уровнях: от Cucumber, от контроллера, от представления и от изолированного класса Ruby. Это позволяет нам количественно оценить преимущества производительности мелкозернистого тестирования и принять более объективные решения о том, что нужно тестировать на данном уровне.
• 15. Simple Bash Script Testing
  Cowboying shell script - это весело, но как мы его тестируем? Мы рассмотрим базовый метод в этом скринкасте, используя ничего, кроме стандартных инструментов оболочки. В этом процессе мы также увидим простой способ использования репозитория git в качестве инструмента для тестирования инструмента, который работает на нем. Все показанное совместимо с Bash, хотя скринкаст представляет собой смесь Bash и Zsh.
• 16. Splitting Into Fine Grained Tests
  Чем больше один тест, тем хуже обратная связь. Мы рассмотрим тест, который уже хорош, но можно разделить дальше, сравнивая шаблоны отказов, которые он генерирует до и после разделения. Перевернув один тест на три, мы сможем понять ошибки просто, посмотрев на имена тестов, вместо того, чтобы анализировать фактические сбои.
• 17. Which Tests to Write 
  В этом обзоре мы перейдем к примеру «Performance of Different Test Sizes», где мы написали аналогичные пары тестов на четырех разных уровнях. Мы пройдем каждый уровень, спросив, какие из этих тестов мы должны соблюдать, и почему.
• 18. TDDing Spikes Away With Rebase Spike - небольшой, одноразовый эксперимент в коде. Узнав о своей проблеме и решенив ее через Spike, вы выбросите его и перепишите код с помощью TDD. Здесь мы рассмотрим процесс выполнения этого поэтапно, используя Spike как руководство и функциональность rebate git как средство. Это подходит только тогда, когда Spike код сильно ограничен внешними интерфейсами. Но в этом случае он может провести вас через сложные взаимодействия сторонних разработчиков. Поскольку это тонкая тема, скринкаст обязательно демонстрирует упрощенную форму: код Spike и TDD идентичен. Когда это делается на практике, перебалансировки приведут к нетривиальным конфликтам, поскольку реализации не будут идентичными. Чем больше они отличаются друг от друга, тем ближе вы к истинному дизайну, основанному на тестах, и тем менее полезная эта техника.