У нас опять куча тестов, много рефакторинга, и старое приложение, которое мы будем переписывать. Это четвертая часть Classic Season, присоединяйтесь.
1. Sucks/Rocks 1: The Rails App
В этой серии мы будем восстанавливать Sucks / Rocks с нуля. В настоящее время он нарушен, поскольку службы, на которые он опирается, были прекращены. Мы перестроим его как приложение Rails, используя как TDD loops (прием и блок), так и использование многих принципов проектирования, описанных в предыдущих сценариях Destroy All Software.
2. Sucks/Rocks 2: Computing Scores
Во второй части мы начинаем unit-level TDD Sucks / Rocks. Я пытаюсь объяснить каждое небольшое решение, которое я делаю в TDD: как выбираются примеры, когда обобщать и как заставить код возвращать определенный тип данных.
3. Sucks/Rocks 3: The Search Engine
В третьей части мы интегрируем Bing в качестве нашего источника поисковой системы, используя VCR для записи / воспроизведения взаимодействий при его тестировании. Мы также получаем наш первый сценарий Cucumber, но обнаруживаем ошибку в этом процессе.
4. Sucks/Rocks 4: Caching
Теперь добавим caching layer в Sucks / Rocks. Это еще один простой старый объект Ruby, который использует службу RockScore. Это четвертая часть серии, и в ней мы добавляем третий класс, но нам все равно не нужны никакие Rails!
5. Sucks/Rocks 5: a Bug and a Model
В пятой части мы вернемся и исправим ошибку, которую мы обнаружили в третьей части. Затем мы завершаемcaching layer, нажав на модель ActiveRecord. Наконец, пять скринкастов, мы вводим схему базы данных и используем Rails.
6. Sucks/Rocks 6: a Controller
Наконец, мы фактически используем новое приложение Sucks / Rocks в качестве веб-сайта. Используя старые статические активы, мы вводим крошечный метод контроллера для подключения наших сервисов до Rails. Это приводит к выявлению ошибки, для какой мы пишем тесты.
7. Sucks/Rocks 7: More Cucumber
В предыдущей части этой серии мы провели несколько пробных испытаний, чтобы убедиться, что контроллер работает. Чтобы избежать повторения этой работы в будущем, мы автоматизируем ее, написав больше тестов Cucumber. В этом процессе мы найдем и исправим еще одну ошибку.
8. Sucks/Rocks 8: The Whole Design
В последней части серии мы начинаем с того, что поднимаем функции Cucumber для запуска полного стека, а не только для уровня сервиса. Затем мы отступаем и смотрим на весь дизайн: как мы могли справиться с NoScore без sentinel? Что было результатом навязчивой идеи, чтобы избежать нуля? И как дизайн позволит нам легко переключиться на новую поисковую систему? Полный источник Sucks / Rocks доступен на GitHub.
9. Pretty Git Logs
В этом скринкасте мы получим свой формат журнала git log с нуля. По пути мы увидим пару трюков командной строки, которые раньше не появлялись в скринкасте. Мои файлы gitconfig и githelpers доступны на GitHub.
10. Mutation in Tell Don't Ask
Принцип Tell Do not Ask говорит нам не манипулировать объектами условно на основе их состояния; вместо этого знание того, когда манипулировать, принадлежит объекту. Это звучит как правило о изменчивости, но это не так: оно применяется точно также, когда объекты неизменяемы. Этот скринкаст рассмотрит пример «запроса», преобразует его в «рассказ» и исследует роль (или отсутствие) мутации.
11. A Magical Isolation Story
Система управления именами и модулями Python позволяет инструменту тестирования автоматически проводить тестирования. Мы будем тестировать такой инструмент с нуля, хотя это будет грубая реализация (он не отменит свои изменения после завершения тестов, например). Это даст нам возможность увидеть несколько функций Python, которые отсутствуют в Ruby.
12. Ugly Tests Trigger Refactoring
Обращая пристальное внимание на ваши тесты, вы можете выделить проблемы с дизайном в производственном коде, которые вы, возможно, не заметили. Здесь мы рассмотрим пример, который произошел во время разработки Raptor: тесты содержат глубокие заглушки, нерелевантные имена, все из которых указывают на проблему проектирования.
13. The Mock Obsession Problem
Когда вы впервые узнаете о mocks и isolation, это соблазн переусердствовать, и я это сделал. Мы рассмотрим тест, который я написал несколько лет назад, и рассмотрим его одержимость mocks. Поскольку мы это делаем, мы реорганизуем его, чтобы быть более простым, более прямым и с меньшей косвенностью через mocks.
14. Test Driving Shell Scripts
Чтобы показать, что Bash действительно является полным языком программирования, давайте проверим тестовый сценарий оболочки. У нас будут все знакомые инструменты из инструментов тестирования стиля xUnit, таких как методы и утверждения setUp.
15. Conditional Whac-A-Mole
Удаление условностей иногда может уменьшить сложность. Однако в этом примере выгоды не столь очевидны. Мы заменим условия пять раз, каждый с использованием другой языковой функции, и посмотрим, как это влияет на понятность кода.
16. Time to First Request
На этот раз мы создадим скрипт, который может запустить процесс, дождаться его начала прослушивания в сокете и затем убить его. Это полезно для бенчмаркинга времени запуска веб-фреймворка (или даже веб-приложения). Мы также компенсируем ошибку в измерениях из-за эффектов холодного кеша и из-за постоянных издержек, представленных самим скриптом. Сценарий доступен для загрузки, если вы хотите его использовать.
17. Test Isolation Without Mocks
В этом скринкасте сделаем тест TDD того же кода дважды: один раз в традиционном, императивном OO пути с мутацией; затем снова функциональным способом, возвращая значение. Мы рассматриваем несколько различий между двумя реализациями, но самое интересное в том, что они изолированы. Хотя оба они изолированы от внешнего поведения, только версия OO требует mocks. Функциональная версия достигает изоляции, принимая значение в (объект значения Tweet) и возвращает значение out (массив строк, которые нужно визуализировать). Это избавляет нас от опасности издевательства методов, выходящих из синхронизации. Примечание: Для реализма тесты написаны точно так, как я, естественно, написал их в ходе моей первой практики. Это делает версию OO немного более сложной; mocks может быть упрощена, но, конечно, ее нельзя удалить. Кроме того, поскольку именно так я написал его изначально, он показывает, насколько легко вводить случайную сложность, когда mocks в тестах.
18. Functional Core, Imperative Shell
Чисто функциональный код упрощает понимание некоторых вещей: поскольку значения не меняются, вы можете вызывать функции и знать, что имеет значение только их возвращаемое значение - они ничего не меняют вне себя. Но это затрудняет выполнение многих приложений. В этом скринкасте мы рассмотрим один способ преодоления этого разрыва. Мы рассматриваем клиент Twitter, ядро которого работает: управление твитами, синхронизация временных графиков с входящими данными API Twitter, запоминание позиций курсора в списке твитов и рендеринг твитов в текст для отображения. Это функциональное ядро окружено оболочкой императивного кода: он управляет stdin, stdout, базой данных и сетью, все они основаны на значениях, создаваемых функциональным ядром. У этого дизайна много приятных побочных эффектов. Например, тестирование функциональных элементов очень просто, и это часто, естественно, позволяет изолировать тестирование без тестовых удвоений. Это также приводит к императивной оболочке с несколькими условностями, что значительно облегчает рассуждение о состоянии программы во времени.
