Система Orphus

Экстремальное программирование.
Разработка через тестирование

Библиотека программиста

Автор: Кент Бек
Издательство: "Питер", 2003
224 страницы

Материал предоставил: Валерий Лаптев
Найти в магазинах

Аннотация

Содержание
Комментарии

Аннотация

Изящный, гибкий и понятный код, который легко модифицировать, который корректно работает и который не подкидывает своим создателям неприятных сюрпризов. Неужели подобное возможно? Чтобы достичь цели, попробуйте тестировать программу еще до того, как она написана. Именно такая парадоксальная идея положена в основу методики TDD (Test-Driven-Development - разработка, основанная на тестировании). Бессмыслица? Не спешите делать скороспелых выводов! Рассматривая применение TDD на примере разработки реального программного кода, автор демонстрирует простоту и мощь этой новой методики. В книге рассматриваются два программных проекта, целиком и полностью реализованных с использованием TDD. За рассмотрением примеров следует обширный каталог приемов работы в стиле TDD, а также паттернов и рефакторингов, имеющих отношение к TDD. Книга будет полезна для любого программиста, желающего повысить производительность своей работы и получить удовольствие от программирования.

Содержание

Предисловие

Храбрость

Благодарности

От издательства

Введение

Часть I. На примере денег

Глава 1. Мультивалютные деньги
Глава 2. Вырождающиеся объекты
Глава 3. Равенство для всех
Глава 4. Данные должны быть закрытыми
Глава 5. Поговорим о франках
Глава 6. Равенство для всех, вторая серия
Глава 7. Яблоки и апельсины
Глава 8. Создание объектов
Глава 9. Потребность в валюте
Глава 10. Избавление от двух разных версий times()
Глава 11. Корень всего зла
Глава 12. Сложение, наконец-то
Глава 13. Делаем реализацию реальной
Глава 14. Обмен валюты
Глава 15. Смешение валют
Глава 16. Абстракция, наконец-то!
Глава 17. Ретроспектива денежного примера
Что дальше?
Метафора
Использование JUnit
Метрики кода
Процесс
Качество тестов
Последний взгляд назад

Часть II. На примере xUnit

Глава 18. Первые шаги на пути к xUnit
Глава 19. Сервируем стол (метод setUp)
Глава 20. Убираем со стола (метод tearDown)
Глава 21. Учет и контроль
Глава 22. Обработка несработавшего теста
Глава 23. Оформляем тесты в набор
Глава 24. Ретроспектива xUnit

Часть III. Паттерны для разработки через тестирование

Глава 25. Паттерны разработки, основанной на тестах
Тест
Изолированный тест (Isolated Test)
Список тестов (Test List)
Вначале тест (Test First)
Вначале оператор assert (Assert First)
Тестовые данные (Test Data)
Понятные данные (Evident Data)
Глава 26. Паттерны красной полосы
One Step Test (Тест одного шага)
Starter Test (Начальный тест)
Explanation Test (Объясняющий тест)
Learning Test (Тест для изучения)
Another Test (Еще один тест)
Regression Test (Регрессионный тест)
Break (Перерыв)
Do over (Начать сначала)
Cheap Desk, Nice Chair (Дешевый стол, хорошие кресла)
Глава 27. Паттерны тестирования
Дочерний тест (Child Test)
Mock Object (Поддельный объект)
Self Shunt (Самошунтирование)
Log String (Строка-журнал)
Crash Test Dummy (Тестирование обработки ошибок)
Broken Test (Сломанный тест)
Clean Check-in (Чистый выпускаемый код)
Глава 28. Паттерны зеленой полосы
Fake It (Подделка)
Triangulate (Триангуляция)
Obvious Implementation (Очевидная реализация)
One to Many (От одного ко многим)
Глава 29. Паттерны xUnit
Assertion
Fixture (Фикстура)
External Fixture (Внешняя фикстура)
Test Method (Тестовый метод)
Exception Test (Тест исключения)
All Tests (Все тесты)
Глава 30. Паттерны проектирования
Command (Команда)
Value Object (Объект-значение)
Null Object (Нуль-объект)
Template Method (Шаблонный метод)
Pluggable Object (Встраиваемый объект)
Pluggable Selector (Встраиваемый переключатель)
Factory Method (Фабричный метод)
Imposter (Самозванец)
Composite (Компоновщик)
Collecting Parameter (Накопление в параметре)
Singleton (Одиночка)
Глава 31. Рефакторинг
Reconcile Differences (Согласование различий)
Isolate Change (Изоляция изменений)
Migrate Data (Миграция данных)
Extract Method (Выделение метода)
Inline Method (Встраивание метода)
Extract Interface (Выделение интерфейса)
Move Method (Перемещение метода)
Method Object (Метод в объект)
Add Parameter (Добавление параметра)
Method Parameter to Constructor Parameter (Параметр метода в параметр конструктора)
Глава 32. Развитие навыков TDD
Насколько большими должны быть шаги?
Что не подлежит тестированию?
Как определить качество тестов?
Каким образом TDD ведет к созданию инфраструктур?
Сколько должно быть тестов?
Когда следует удалять тесты?
Каким образом язык программирования и среда разработки влияют на TDD?
Можно ли использовать TDD для разработки крупномасштабных систем?
Можно ли осуществлять разработку приложения исходя из тестов уровня приложения?
Как можно перейти к использованию TDD в середине работы над проектом?
Для кого предназначена методика TDD?
Зависит ли эффективность TDD от начальных условий?
Каким образом методика TDD связана с паттернами?
Почему TDD работает?
Что означает имя?
Как методика TDD связана с практиками экстремального программирования?
Нерешенные проблемы TDD

Послесловие

Приложение I. Диаграммы взаимовлияния

Обратная связь
Контроль над системой

Приложение II. Фибоначчи

Алфавитный указатель

Комментарии

Валерий Лаптев

Когда я читал первые книги по экстремальному программированию, то не мог отделаться от мысли, что это - очередная "беллетристика" о технологии создания ПО. То, что программировать (и вообще выполнять практически любую умственную деятельность) в паре значительно эффективнее, я знал давно ("Одна голова - хорошо, а две - лучше" - это мы все знаем). Остальные положения экстремального программирования тоже не казались откровениями. Однако один принцип XP не давал мне покоя: я никак не мог сообразить (думаю, и многие другие программисты тоже), как же это сначала писать тесты, а потом уже код? Как я напишу тест, если еще не знаю, что, собственно, тестировать?! И вот наконец-то я получил исчерпывающий ответ в книге Кента Бека "ХР. Разработка через тестирование". В книге описана методика Test-Driven Development (TDD) - разработка посредством тестов.

"Чистый код, который работает, - в этой короткой фразе кроется весь смысл методики TDD. Чистый код, который работает, - это цель, к которому стоит стремиться" - так начинается эта книга. Благие намерения - это, конечно, здорово, но мы знаем, куда они обычно заводят. В этой книге благие намерения оказались подкреплены совершенно конкретными делами - изложением такой нужной программистам методики. Она основана на применении xUnit. Однако мне не показалось, что без этого методику нельзя применять. После прочтения первой части у меня сложилось стойкое убеждение, что и без xUnit можно делать все то же самое. Судите сами - в рамках TDD нужно выполнять всего два простых правила:

У Кента Бека слово "автоматический" написано без скобок, так как он привязывает процесс разработки к автоматическому выполнению тестов посредством xUnit, выделяя три этапа:
  1. Красный - напишите небольшой тест, который не работает, а возможно, даже не компилируется;
  2. Зеленый - заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал.
  3. Рефакторинг - удалите из написанного вами кода любое дублирование.
"Красный-зеленый-рефакторинг - это мантра TDD." Красный и зеленый - это цвет полосы в JUnit при прогоне тестов.

В первой части очень подробно, со всеми рассуждениями и принятыми решениями, описан процесс доработки некоей системы, оперирующей одной валютой, до мультивалютного варианта. Примеры даны на Java, но это не особенно напрягает, поскольку шаги настолько элементарны, что конкретный код занимает не более 5 строчек. С++-программист все легко понимает.

Во второй части Кент Бек применяет тот же процесс для разработки xUnit. Мне уже давно не давало покоя практически полное отсутствие автоматизированных инструментов для тестирования. Первый раз я наткнулся на упоминание о JUnit при прочтении "Рефакторинга". И тут такой подарок - описание разработки от автора! После прочтения этой главы у меня возникло стойкое желание САМОМУ для себя написать CppUnit. Знаю, знаю, что уже написано. Однако процесс описан Кентом Беком столь увлекательно, что в буквальном смысле "вводит во искушение". Почитайте книгу - я уверен, что с вами случиться то же самое. Когда я писал эту рецензию, я поймал себя на том, что следую методике TDD:

Кстати, разработку xUnit Кент Бек выполняет на Python, но это опять не вызывает никаких затруднений.

С легкой руки "Банды четырех", мы теперь все приемы разработки (от проектирования до тестирования) можем называть паттернами. То же делает и Кент Бек. Третья часть представляет начальный каталог паттернов разработки через тестирование. Автор сюда еще добавил "кусочек" каталога паттернов рефакторинга и "кусочек" каталога паттернов "Банды четырех". Это сделано просто для того, чтобы читатель понял взаимосвязь всех паттернов.

Собственные впечатления. Если кто помнит, раньше разработки велись методом "снизу-вверх". Потом придумали "сверху-вниз", потом еще много чего, основное из которого (ИМХО) объектно-ориентированный подход и UML. Я преподавал студентам технологию программирования и постоянно сталкивался с одной проблемой: как научить студента на практике применять все эти прекрасные методики, методы, методологии. Даже не научить, а заставить - как известно, студенты сначала пишут программу, а потом уже проект под нее. Все студенческие проекты - это разработки "для себя". По собственному опыту знаю, что в работе "для себя" непреодолимо хочется писать программу, а не чертить диаграммы UML. Теперь у меня есть прекрасная возможность учить студентов естественной технологии разработки. Кент Бек описал метод "снизу-вверх" в объектно-ориентированной постановке. Конечно, если система большая, то это не избавляет нас от необходимости иметь хотя бы черновой проект всей системы, однако любую часть ее мы можем начинать писать по методике TDD. И при этом будем совершенно уверены, что все будет работать, так как двигаемся мы мелкими шагами и на каждом шаге имеем работающий код. "Серебряная пуля" найдена? Конечно, нет - в последней главе Кент Бек пишет об ограничениях применимости методики TDD.

Выводы. Эта книжка, наряду с "Рефакторингом" и "Паттернами", должна обязательно быть под рукой у программиста при ЛЮБОЙ разработке. По соотношению "стоимость-производительность" (программиста) ей нет равных.