Последний Classic Season. В этой серии вы разберете несколько знакомых уже вам проектов и изучите различные методы их тестирования. Мы также обсудим язык программирования C и некоторые его интересные особенности.
В серии What Goes in Active Records мы рассмотрели ограничения для моделей ActiveRecord, которые иногда приводят к созданию очень маленьких классов, что может быть неудобно.
Этот скринкаст фокусируется на минимизации кода сервиса путём объединения его в единый класс значений, что оптимизирует тестирование. Этот подход позволяет создать тесты, которые проще анализировать, и новую абстракцию, подтвержденную кодом. После такой реорганизации, тесты становятся изолированными от Rails и выполняются в восемь раз быстрее.
Это продолжение предыдущего скринкаста, Collapsing Services to Values. Тут мы преобразуем объект значения Subscription в таблицу базы данных и модель ActiveRecord.
Несмотря на очистку системы, класс User остаётся перегружен информацией о подписках. Вынесение подписок в отдельную таблицу и модель устраняет это излишнее знание. Однако, это вновь поднимает вопрос: где же должна быть логика приложения?
Rubinius – это реализация Ruby, известная тем, что она частично написана на Ruby. Мы изучим структуру Rubinius, удалим из неё функцию и обновим связанные исходные файлы. Затем проверим изменения запуская тесты и визуально контролируя результат.
Обратите внимание: ошибка в начале скринкаста была исправлена. Система объектов требует деликатного обращения!
Сравним объектные системы Python и Ruby, фокусируя внимание на различиях. Python работает с атрибутами, а Ruby – с методами. Несмотря на их динамическую выразительность, реализация этих систем различна. Это скринкаст подчеркивает свойства обоих языков в работе с методами и атрибутами.
Многие приложения Rails полагаются на проверку данных на уровне контроллера. Этот скринкаст демонстрирует использование ActiveRecord для проверки данных. Однако, такие проверки могут быть обойдены. Мы рассмотрим механизмы подобных обходов и их решения с помощью реальных ограничений баз данных.
Жесткая привязка имени одного класса внутри другого создает проблемы в проектировании и тестировании. Этот скринкаст показывает, как разделить организацию и работу через поток данных между объектами, что позволяет перейти к модели, основанной на актерах.
Primitive Obsession – это чрезмерное использование примитивных типов вместо абстракций. В этом скринкасте мы изучаем класс Screencast и заменяем его на более удобную структуру. Это демонстрирует важность хорошего дизайна.
Скринкаст направлен на написание изолированных тестов без использования заглушек. Мы разделяем значения объекта от его поведения и тестируем их отдельно, избегая несоответствий между тестами и тестируемым кодом.
Продемонстрируем рефакторинг кода через три парадигмы. От императивного подхода, через объектно-ориентированный, к функциональному – показывая, как функции и данные взаимодействуют на каждом этапе.
Переводим отчеты об ошибках в тесты, чтобы проверить исправления. Рассмотрим, как эффективно отлаживать систему, не заглядывая в код, используя наименьшие изменения стека и попутно создавая тесты.
Сравним тестирование в стиле «тестовых случаев» и «примеров». Переводим набор тестов Hamster из одного стиля в другой, сталкиваясь с компромиссами на каждом шагу.
Примечание: возможные ошибки в RSpec требуют акцентированного внимания!
Многие программы реализованы на C. Этот скринкаст показывает проект на C, фокусируясь на модульных тестированиях и применении современных подходов проектирования. Ожидается знание C, так как это не учебник.
Примечание: В коде есть ошибка указателя, обнаруженная Лео Кассарани.
Для анализа работы систем доступны различные инструменты, от среднего значения нагрузки до /usr/bin/time. Мы рассмотрим пользу этого метода для вычисления количеств переключений контекста, предоставляя отправную точку для анализа производительности.
Примечание: Потенциальная переоценка влияния IO на уровень нагрузки. Требуется более глубокий анализ.
Используем гибкость Ruby для реализации Actor Syntax. Скринкаст иллюстрирует теоретический синтаксис и его практическую реализацию, подчеркивая возможности Ruby и объясняя Actor model.
Большинство тестов запускаются синхронно. Мы покажем способ асинхронного запуска тестов с помощью tmux и Unix-примитивов, таких как именованные каналы и shell скрипты.
Показывает случаи, когда использование примитивов Rails является правильным решением. Мы реорганизуем контроллеры для улучшения архитектуры, сохраняя их роль только в делегировании и переводе.
Примечание: Ошибка в методе Account.create_with_schema должна быть исправлена для получения параметров от контроллера.
Заключительный скринкаст подводит черту под двумя годами работы над Destroy All Software. Рассказ о внутренняя организации и инструментах, используемых в течение этого времени. Благодарим всех подписчиков за их поддержку!
Destroy All Software — это интересный и уже классический образовательный проект, в котором собраны лаконичные и содержательные видео по веб-разработке и смежным IT-направлениям. Несмотря на возраст, материалы остаются актуальными благодаря фокусу на фундаментальных принципах разработки, а не на быстро устаревающих технологиях.В рамках проекта рассматриваются реальные задачи программирования: работа с кодом, автоматизация, тестирование, архитектур
