(no subject)
Сейчас читаю
Кент Бек
Экстремальное программирование: разработка через тестирование
СПб.: Питер, 2003, 224 стр.
Серия "Библиотека программиста".
Перевёл с англ. П. Анджан
Kent Beck. Test-driven development by example, Addison-Wesley
Содержание
10 ..... Предисловие
11 ..... Храбрость
15 ..... Благодарности
16 ..... От издательства
17 ..... Введение
21 ..... Часть I. На примере денег
22 ..... 1. Мультивалютные деньги
29 ..... 2. Вырождающиеся объекты
32 ..... 3. Равенство для всех
36 ..... 4. Данные должны быть закрытыми
39 ..... 5. Поговорим о франках
42 ..... 6. Равенство для всех, вторая серия
47 ..... 7. Яблоки и апельсины
49 ..... 8. Создание объектов
53 ..... 9. Потребность в валюте
58 ..... 10. Избавление от двух разных версий times()
63 ..... 11. Корень всего зла
66 ..... 12. Сложение, наконец-то
71 ..... 13. Делаем реализацию реальной
76 ..... 14. Обмен валюты
81 ..... 15. Смешение валют
85 ..... 16. Абстракция, наконец-то!
89 ..... 17. Ретроспектива денежного примера
89 ..... Что дальше?
90 ..... Метафора
91 ..... Использование JUnit
92 ..... Метрики кода
92 ..... Процесс
93 ..... Качество тестов
95 ..... Последний взгляд назад
97 ..... Часть II. На примере xUnit
98 ..... 18. Первые шаги на пути к xUnit
104 .... 19. Сервируем стол (метод setUp)
108 .... 20. Убираем со стола (метод tearDown)
112 .... 21. Учет и контроль
115 .... 22. Обработка несработавшего теста
118 .... 23. Оформляем тесты в набор
123 .... 24. Ретроспектива xUnit
125 .... Часть III. Паттерны для разработки через тестирование
126 .... 25. Паттерны разработки, основанной на тестах
126 .... Тест
128 .... Изолированный тест (Isolated Test)
129 .... Список тестов (Test List)
131 .... Вначале тест (Test First)
132 .... Вначале оператор assert (Assert First)
134 .... Тестовые данные (Test Data)
135 .... Понятные данные (Evident Data)
136 .... 26. Паттерны красной полосы
136 .... One Step Test (Тест одного шага)
137 .... Starter Test (Начальный тест)
139 .... Explanation Test (Объясняющий тест)
139 .... Learning Test (Тест для изучения)
140 .... Another Test (Еще один тест)
141 .... Regression Test (Регрессионный тест)
141 .... Break (Перерыв)
143 .... Do over (Начать сначала)
144 .... Cheap Desk, Nice Chair (Дешевый стол, хорошие кресла)
145 .... 27. Паттерны тестирования
145 .... Дочерний тест (Child Test)
146 .... Mock Object (Поддельный объект)
147 .... Self Shunt (Самошунтирование)
149 .... Log String (Строка-журнал)
149 .... Crush Test Dummy (Тестирование обработки ошибок)
151 .... Broken Test (Сломанный тест)
151 .... Clean Check-in (Чистый выпускаемый код)
153 .... 28. Паттерны зеленой полосы
153 .... Fake It (Подделка)
155 .... Triangulate (Триангуляция)
156 .... Obvious Implementation (Очевидная реализация)
157 .... One to Many (От одного ко многим)
159 .... 29. Паттерны xUnit
159 .... Assertion
161 .... Fixture (Фикстура)
163 .... External Fixture (Внешняя фикстура)
164 .... Test Method (Тестовый метод)
166 .... Exception Test (Тест исключения)
166 .... All Tests (Все тесты)
168 .... 30. Паттерны проектирования
170 .... Command (Команда)
170 .... Value Object (Объект-значение)
172 .... Null Object (Нуль-объект)
173 .... Template Method (Шаблонный метод)
175 .... Pluggable Object (Встраиваемый объект)
175 .... Pluggable Selector (Встраиваемый переключатель)
178 .... Factory Method (Фабричный метод)
179 .... Imposter (Самозванец)
180 .... Composite (Компоновщик)
182 .... Collecting Parameter (Накопление в параметре)
183 .... Singleton (Одиночка)
184 .... 31. Рефакторинг
184 .... Reconcile Differences (Согласование различий)
184 .... Isolate Change (Изоляция изменений)
186 .... Migrate Data (Миграция данных)
188 .... Extract Method (Выделение метода)
189 .... Inline Method (Встраивание метода)
190 .... Extract Interface (Выделение интерфейса)
191 .... Move Method (Перемещение метода)
192 .... Method Object (Метод в объект)
193 .... Add Parameter (Добавление параметра)
193 .... Method Parameter to Constructor Parameter (Параметр метода в параметр конструктора)
195 .... 32. Развитие навыков TDD
195 .... Насколько большими должны быть шаги?
196 .... Что не подлежит тестированию?
196 .... Как определить качество тестов?
197 .... Каким образом TDD ведет к созданию инфраструктур?
198 .... Сколько должно быть тестов?
200 .... Когда следует удалять тесты?
201 .... Каким образом язык программирования и среда разработки влияют на TDD?
201 .... Можно ли использовать TDD для разработки крупномасштабных систем?
202 .... Можно ли осуществлять разработку приложения исходя из тестов уровня приложения?
203 .... Как можно перейти к использованию TDD в середине работы над проектом?
204 .... Для кого предназначена методика TDD?
205 .... Зависит ли эффективность TDD от начальных условий?
205 .... Каким образом методика TDD связана с паттернами?
206 .... Почему TDD работает?
208 .... Что означает имя?
208 .... Как методика TDD связана с практиками экстремального программирования?
210 .... Нерешенные проблемы TDD
211 .... Послесловие. Мартин Фаулер (Martin Fowler)
213 .... Приложение I. Диаграммы взаимовлияния
214 .... Обратная связь
215 .... Контроль над системой
217 .... Приложение II. Фибоначчи
220 .... Алфавитный указатель
Цитаты:
стр. 17
стр. 23
стр. 31
стр. 76
стр. 85
стр. 93
стр. 95
стр. 127
стр. 129
стр. 131
стр. 134
стр. 135
стр. 140
стр. 143
стр. 146
стр. 165
стр. 176
стр. 184
стр. 199
стр. 206
стр. 213
стр. 215
стр. 17
Подробнее о подсистеме отчетов рассказано на c2.com/doc/oopsla91.html
стр. 23
Код с душком (code that smells) - распространенная в XP метафора, означающая плохой код (содержащий дублирование).
стр. 31
Мне известны три способа для быстрого получения зеленого индикатора. Вот первые два из них:
* подделать реализацию, иначе говоря, создать заглушку (Fake it) - возвращать константу и постепенно заменять константы переменными до тех пор, пока не получим настоящий код;
* использовать очевидную реализацию (Obvious Implementation) - просто написать сразу настоящую реализацию.
...
Есть еще одна, третья методика, "Триангуляция" (Triangulation), которую мы рассмотрим в главе 3.
стр. 76
Используя игру слов (английское change означает как "изменение", так и "обмен"), автор намекает на свою знаменитую книгу-бестселлер Extreme Programming Explained: Embrace Change. Русский перевод: Бек К. Экстремальное программирование. СПб.: Питер, 2002, 224 с. - Примеч. ред.
стр. 85
Ведь мы пишем эти тесты не только для того, чтобы получить удовольствие от программирования, но также для того, чтобы будущие поколения программистов могли оценить нашу гениальность. Однако они не смогут сделать этого, если код будет непонятным. Таким образом, разрабатывая любой код, думайте о тех, кто будет его читать.
стр. 93
Тесты являются неотъемлемой частью методики TDD. Тесты TDD могут быть запущены в любое время работы над программой, а также после того, как программа будет завершена. Однако не стоит путать их с другими важными типами тестирования:
* тестирование производительности;
* стрессовым тестированием;
* тестированием практичности.
Тем не менее, если вероятность дефектов в коде, разработанном с использованием TDD, невелика, роль профессионального тестирования меняется. Если обычно профессиональное тестирование используется для постоянного надзора за работой программистов, то при использовании TDD профессиональное тестирование больше напоминает вспомогательный инструмент, облегчающий коммуникацию между теми, кто знает, как должна работать система, и теми, кто создает систему.
Как можно оценить качество разработанных нами тестов? Вот два широко распространенных метода:
* Покрытие операторов кода (statement coverage). Для оценки качества тестов этой характеристики недостаточно, однако ее можно использовать как отправную точку. Если программист ревностно следует всем требованиям TDD, покрытие функционального кода тестами должно составлять 100%.
...
* Намеренное добавление дефекта (defect insertion).
стр. 95
В главе 32 приводится пример задачи, для решения которой я написал 6 тестов, а человек, профессионально занимающийся тестированием, - 65 тестов.
стр. 95
Существуют три важных навыка, которые необходимо освоить тем, кто впервые изучает TDD:
* три основных подхода, которые используются для того, чтобы заставить тест срабатывать: подделка реализации (Fake It), триангуляция (Triangualation) и очевидная реализация (Obvious Implementation);
* удаление дублирования между функциональным кодом и тестами - важный способ формирования дизайна;
* способность контролировать расстояние между тестами: когда дорога становится скользкой, необходимо двигаться маленькими шажками; когда дальнейший путь ясен, можно увеличить скорость.
стр. 127
Что происходит, когда уровень стресса возрастает?
Чем больший стресс вы ощущаете, тем меньше вы тестируете разрабатываемый код. Чем меньше вы тестируете разрабатываемый код, тем больше ошибок вы допускаете. Чем больше ошибок вы допускаете, тем выше уровень стресса, который вы ощущаете. Получается замкнутый круг с позитивной обратной связью: рост стресса приводит к росту стресса.
стр. 129
Что необходимо тестировать? Прежде чем начать, запишите на листке бумаги список всех тестов, которые вам потребуются. Чтобы успешно справляться с программистским стрессом, вы должны постоянно соблюдать важное правило: никогда не делайте шага вперед до тех пор, пока не узнаете, в каком месте ваша нога должна коснуться земли. Приступая к сеансу программирования, определите, какие задачи вы намерены решить в ходе этого сеанса.
В рамках весьма распространенной стратегии предлагается держать все в голове. Я пробовал использовать этот подход в течение нескольких лет, однако постоянно сталкивался с одной и той же проблемой. По мере того как я работаю, передо мной возникают все новые и новые задачи, которые необходимо решить. Чем больше задач предстоит решить, тем меньше внимания я уделяю тому, над чем я работаю. Чем меньше внимания я уделяю тому, над чем я работаю, тем меньше задач мне удается решить. Чем меньше задач мне удается решить, тем больше вещей, о которых мне приходится помнить в процессе работы. Замкнутый круг.
...
Я выработал привычку записывать на листик бумаги все задачи, которые я планирую решить в течение нескольких следующих часов. Этот листик постоянно лежит рядом с моим компьютером. Похожий список задач, которые я планирую решить в течение ближайшей недели или ближайшего месяца, приколот к стене над моим компьютером. Если я записал все эти задачи на бумагу, я уверен в том, что я ничего не забуду. Если передо мной возникает новая задача, я быстро и осознанно решаю, к какому списку ("сейчас" или "позднее") она принадлежит и нужно ли вообще ей заниматься.
стр. 131
Консервативные скалолазы придерживаются одного важного правила. У человека есть две руки и две ноги, всего четыре конечности, которыми он может цепляться за скалу. В любой момент времени по крайней мере три конечности должны быть надежно сцеплены со скалой. Динамические перемещения, когда скалолаз перемещает с места на место одновременно две конечности, считаются чрезвычайно опасными. Методика TDD в чистом виде подразумевает использование похожего принципа: в любой момент времени вы должны быть не дальше одного изменения от зеленой полосы.
стр. 134
Альтернативой паттерна Test Data (Тестовые данные) является паттерн Realistic Data (Реалистичные данные), в рамках которого для тестирования используются данные из реального мира. Реалистичные данные удобно применять в следующих ситуациях:
* вы занимаетесь тестированием системы реального времени, используя цепочки внешних событий, которые возникают в реальных условиях эксплуатации этой системы;
* вы сравниваете вывод текущей системы с выводом предыдущей системы (параллельное тестирование);
* вы выполняете рефакторинг кода, имитирующего некоторый реальный процесс, и ожидаете, что после выполнения рефакторинга результирующие данные будут в точности такими же, как до рефакторинга, в особенности, если речь идет о точности операций с плавающей точкой.
стр. 135
Паттерн Evident Data (Понятные данные) выглядит, как исключение из правила о том, что в коде не должно быть "магических" чисел. Дело в том, что в рамках одного метода легко понять предназначение того или иного числа. Однако если в программе уже имеются объявленные символьные константы, я предпочитаю использовать их вместо конкретных численных значений.
стр. 140
Джим Ньюкирк рассказал мне о проекте, в котором разработка тестов для обучения выполнялась на регулярной основе. Как только от сторонних разработчиков поступала новая версия пакета, в отношении этого пакета немедленно запускались имеющиеся тесты. В случае необходимости в тесты вносились исправления. Если тесты не срабатывали, не было никакого смысла запускать приложение, так как оно определенно не заработает. Если же все тесты срабатывают, значит и приложение заработает.
стр. 143
Иногда в случае, если перед вами стоит сложная проблема, вам требуется, наоборот, поднажать, поднапрячься и потратить дополнительное время и усилия для того, чтобы решить ее. Однако большинство программистов инфицировано духом саморазрушения: "Я угроблю свое здоровье, отрекусь от своей семьи и даже выпрыгну из окна, лишь бы этот код заработал". Поэтому я не буду давать здесь каких-либо советов. Если вы чувствуете, что у вас развивается болезненное пристрастие к кофе, наверное, вам не стоит делать слишком частых перерывов. В крайнем случае, просто пройдитесь.
стр. 146
http://www.mockobjects.com/
стр. 146
Паттерн Fake It (Подделка) напоминает страховочную веревку, которая соединяет вас с верхней точкой маршрута, когда вы карабкаетесь по скале. Пока что вы еще не забрались на самый верх (тест на месте и работает, но тестируемый код некорректен). Однако в любой точке маршрута вы держитесь за веревку и знаете, что когда достигнете самого верха, то будете в безопасности (тест срабатывает в ходе рефакторинга, а также после того, как вы получили окончательный результирующий код).
Паттерн Fake It (Подделка) многим может показаться совершенно бесполезным. Зачем писать код, который абсолютно точно придется заменять другим? Дело в том, что иметь хоть какой-то работающий код - это лучше, чем вообще не иметь работающего кода, в особенности если у вас есть тесты, которые могут доказать работоспособность кода.
...
При использовании паттерна Fake It (Подделка) возникает как минимум два положительных эффекта:
* Психологический. Если перед вами зеленая полоса, вы чувствуете себя совершенно иначе, чем если перед вами красная полоса. Когда полоса зеленая, вы знаете, на чем стоите. Вы можете смело и уверенно приступать к рефакторингу.
* Контроль надо объемом работы. Программисты привыкли пытаться предвидеть возникновение в будущем самых разнообразных проблем. Если вы начинаете с конкретного примера и затем осуществляете обобщение кода, это помогает вам избавиться от лишних опасений. Вы можете сконцентрироваться на решении конкретной проблемы и поэтому выполнить работу лучше. При переходе к следующему тесту вы опять же концентрируетесь на нем, так как знаете, что предыдущий тест гарантированно работает.
стр. 165
McConnell, Steve. 1993. Code Complete, Seattle, Washington: Microsoft Press
Caine, S. H., Gordon, E. K. 1975. PDL: A Tool for Software Design, AFIPS Proceedings of the 1975 National Computer Conference
стр. 176
Подробнее об этом паттерне рассказывается в книге
Beck, K. 1997. The Smalltalk Best Practice Patterns, Englewood-Cliffs, NJ: Prentice-Hall
стр. 184
Fowler, Martin. 1999. Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley
Файлер. М. Рефакторинг: улучшение существующего кода. СПб.: Символ-Плюс, 2003.
стр. 199
Это отчасти напоминает игру "Угадай мелодию" ("Я могу закодировать задачу за четыре теста!" - "А я - за три!" - "О'кей попробуйте"). Для решения задачи я написал шесть тестов, а Боб Биндер (Bob Binder) в своей книге Testing Object-Oriented Systems (Тестирование объектно-ориентированных систем) для этой же самой задачи написал 65 тестов. Сколько на самом деле нужно тестов? Вы должны решить это сами, исходя из собственного опыта и рассуждений.
Имеет ли смысл писать тот или иной тест? Это зависит от того, насколько аккуратно вы оцените MTBF. Если обстоятельства требуют, чтобы вы увеличили MTBF от 10 лет до 100 лет, значит, имеет смысл уделить время для разработки самых маловероятных и чрезвычайно редко возникающих ситуаций (если, конечно, вы не можете каким-либо иным образом доказать, что подобные ситуации никогда не могут возникнуть).
Взгляд на тестирование в рамках TDD прагматичен. В TDD тесты являются средством достижения цели. Целью является код, в корректности которого мы в достаточной степени уверены. Если знание особенностей реализации без какого-либо теста дает нам уверенность в том, что код работает правильно, мы не будем писать тест. Тестирование черного ящика (когда мы намеренно игнорируем реализацию) обладает рядом преимуществ. Если мы игнорируем код, мы наблюдаем другую систему ценностей: тесты сами по себе представляют для нас ценность. В некоторых ситуациях это вполне оправданный подход, однако он отличается от TDD.
Binder, Bob. 1999. Testing Object-Oriented Systems: Models, Patterns, and Tools. Boston: Addison-Wesley. Это действительно исчерпывающее руководство по тестированию.
стр. 206
Mars Lander - американский космический аппарат, был запущен в сторону Марса 3 января 1999 г. 3 декабря 1999 г. аппарат должен был осуществить посадку на Марс, однако в этот день связь с ним была потеряна, предположительно из-за ошибки в программном обеспечении. Стоимость миссии составила приблизительно 120 млн. долларов, не считая стоимости ракеты-носителя и некоторого дополнительного оборудования. - Примеч. перев.
стр. 213
Weinberg, Gerald. 1992. Systems Thinking. Quality Software Management. New York: Dorset House
стр. 215
Когда время начинает поджимать, вы снижаете интенсивность тестирования, что приводит к увеличению количества ошибок, что, в свою очередь, приводит к еще большему недостатку времени. Со временем на сцене появляется некоторое внешнее действие (например, недостаток денег), которое заставляет вас завершить работу над проектом, несмотря ни на что.
Если вы имеете дело с системой, которая ведет себя не так, как вам того хотелось бы, у вас есть несколько вариантов исправить ситуацию:
* Сформируйте цикл позитивной обратной связи в обратном направлении. Если у вас цикл между тестами и уверенностью, и тесты не срабатывают, снижая тем самым уверенность, тогда вы можете сделать больше срабатывающих тестов, повысив тем самым уверенность в вашей способности увеличить количество срабатывающих тестов.
* Сформируйте цикл негативной обратной связи, который позволит вам контролировать действие, интенсивность которого стала слишком большой.
* Создайте или разорвите соединения для того, чтобы устранить циклы, не являющиеся полезными.
Кент Бек
Экстремальное программирование: разработка через тестирование
СПб.: Питер, 2003, 224 стр.
Серия "Библиотека программиста".
Перевёл с англ. П. Анджан
Kent Beck. Test-driven development by example, Addison-Wesley
Содержание
10 ..... Предисловие
11 ..... Храбрость
15 ..... Благодарности
16 ..... От издательства
17 ..... Введение
21 ..... Часть I. На примере денег
22 ..... 1. Мультивалютные деньги
29 ..... 2. Вырождающиеся объекты
32 ..... 3. Равенство для всех
36 ..... 4. Данные должны быть закрытыми
39 ..... 5. Поговорим о франках
42 ..... 6. Равенство для всех, вторая серия
47 ..... 7. Яблоки и апельсины
49 ..... 8. Создание объектов
53 ..... 9. Потребность в валюте
58 ..... 10. Избавление от двух разных версий times()
63 ..... 11. Корень всего зла
66 ..... 12. Сложение, наконец-то
71 ..... 13. Делаем реализацию реальной
76 ..... 14. Обмен валюты
81 ..... 15. Смешение валют
85 ..... 16. Абстракция, наконец-то!
89 ..... 17. Ретроспектива денежного примера
89 ..... Что дальше?
90 ..... Метафора
91 ..... Использование JUnit
92 ..... Метрики кода
92 ..... Процесс
93 ..... Качество тестов
95 ..... Последний взгляд назад
97 ..... Часть II. На примере xUnit
98 ..... 18. Первые шаги на пути к xUnit
104 .... 19. Сервируем стол (метод setUp)
108 .... 20. Убираем со стола (метод tearDown)
112 .... 21. Учет и контроль
115 .... 22. Обработка несработавшего теста
118 .... 23. Оформляем тесты в набор
123 .... 24. Ретроспектива xUnit
125 .... Часть III. Паттерны для разработки через тестирование
126 .... 25. Паттерны разработки, основанной на тестах
126 .... Тест
128 .... Изолированный тест (Isolated Test)
129 .... Список тестов (Test List)
131 .... Вначале тест (Test First)
132 .... Вначале оператор assert (Assert First)
134 .... Тестовые данные (Test Data)
135 .... Понятные данные (Evident Data)
136 .... 26. Паттерны красной полосы
136 .... One Step Test (Тест одного шага)
137 .... Starter Test (Начальный тест)
139 .... Explanation Test (Объясняющий тест)
139 .... Learning Test (Тест для изучения)
140 .... Another Test (Еще один тест)
141 .... Regression Test (Регрессионный тест)
141 .... Break (Перерыв)
143 .... Do over (Начать сначала)
144 .... Cheap Desk, Nice Chair (Дешевый стол, хорошие кресла)
145 .... 27. Паттерны тестирования
145 .... Дочерний тест (Child Test)
146 .... Mock Object (Поддельный объект)
147 .... Self Shunt (Самошунтирование)
149 .... Log String (Строка-журнал)
149 .... Crush Test Dummy (Тестирование обработки ошибок)
151 .... Broken Test (Сломанный тест)
151 .... Clean Check-in (Чистый выпускаемый код)
153 .... 28. Паттерны зеленой полосы
153 .... Fake It (Подделка)
155 .... Triangulate (Триангуляция)
156 .... Obvious Implementation (Очевидная реализация)
157 .... One to Many (От одного ко многим)
159 .... 29. Паттерны xUnit
159 .... Assertion
161 .... Fixture (Фикстура)
163 .... External Fixture (Внешняя фикстура)
164 .... Test Method (Тестовый метод)
166 .... Exception Test (Тест исключения)
166 .... All Tests (Все тесты)
168 .... 30. Паттерны проектирования
170 .... Command (Команда)
170 .... Value Object (Объект-значение)
172 .... Null Object (Нуль-объект)
173 .... Template Method (Шаблонный метод)
175 .... Pluggable Object (Встраиваемый объект)
175 .... Pluggable Selector (Встраиваемый переключатель)
178 .... Factory Method (Фабричный метод)
179 .... Imposter (Самозванец)
180 .... Composite (Компоновщик)
182 .... Collecting Parameter (Накопление в параметре)
183 .... Singleton (Одиночка)
184 .... 31. Рефакторинг
184 .... Reconcile Differences (Согласование различий)
184 .... Isolate Change (Изоляция изменений)
186 .... Migrate Data (Миграция данных)
188 .... Extract Method (Выделение метода)
189 .... Inline Method (Встраивание метода)
190 .... Extract Interface (Выделение интерфейса)
191 .... Move Method (Перемещение метода)
192 .... Method Object (Метод в объект)
193 .... Add Parameter (Добавление параметра)
193 .... Method Parameter to Constructor Parameter (Параметр метода в параметр конструктора)
195 .... 32. Развитие навыков TDD
195 .... Насколько большими должны быть шаги?
196 .... Что не подлежит тестированию?
196 .... Как определить качество тестов?
197 .... Каким образом TDD ведет к созданию инфраструктур?
198 .... Сколько должно быть тестов?
200 .... Когда следует удалять тесты?
201 .... Каким образом язык программирования и среда разработки влияют на TDD?
201 .... Можно ли использовать TDD для разработки крупномасштабных систем?
202 .... Можно ли осуществлять разработку приложения исходя из тестов уровня приложения?
203 .... Как можно перейти к использованию TDD в середине работы над проектом?
204 .... Для кого предназначена методика TDD?
205 .... Зависит ли эффективность TDD от начальных условий?
205 .... Каким образом методика TDD связана с паттернами?
206 .... Почему TDD работает?
208 .... Что означает имя?
208 .... Как методика TDD связана с практиками экстремального программирования?
210 .... Нерешенные проблемы TDD
211 .... Послесловие. Мартин Фаулер (Martin Fowler)
213 .... Приложение I. Диаграммы взаимовлияния
214 .... Обратная связь
215 .... Контроль над системой
217 .... Приложение II. Фибоначчи
220 .... Алфавитный указатель
Цитаты:
стр. 17
стр. 23
стр. 31
стр. 76
стр. 85
стр. 93
стр. 95
стр. 127
стр. 129
стр. 131
стр. 134
стр. 135
стр. 140
стр. 143
стр. 146
стр. 165
стр. 176
стр. 184
стр. 199
стр. 206
стр. 213
стр. 215
стр. 17
Подробнее о подсистеме отчетов рассказано на c2.com/doc/oopsla91.html
стр. 23
Код с душком (code that smells) - распространенная в XP метафора, означающая плохой код (содержащий дублирование).
стр. 31
Мне известны три способа для быстрого получения зеленого индикатора. Вот первые два из них:
* подделать реализацию, иначе говоря, создать заглушку (Fake it) - возвращать константу и постепенно заменять константы переменными до тех пор, пока не получим настоящий код;
* использовать очевидную реализацию (Obvious Implementation) - просто написать сразу настоящую реализацию.
...
Есть еще одна, третья методика, "Триангуляция" (Triangulation), которую мы рассмотрим в главе 3.
стр. 76
Используя игру слов (английское change означает как "изменение", так и "обмен"), автор намекает на свою знаменитую книгу-бестселлер Extreme Programming Explained: Embrace Change. Русский перевод: Бек К. Экстремальное программирование. СПб.: Питер, 2002, 224 с. - Примеч. ред.
стр. 85
Ведь мы пишем эти тесты не только для того, чтобы получить удовольствие от программирования, но также для того, чтобы будущие поколения программистов могли оценить нашу гениальность. Однако они не смогут сделать этого, если код будет непонятным. Таким образом, разрабатывая любой код, думайте о тех, кто будет его читать.
стр. 93
Тесты являются неотъемлемой частью методики TDD. Тесты TDD могут быть запущены в любое время работы над программой, а также после того, как программа будет завершена. Однако не стоит путать их с другими важными типами тестирования:
* тестирование производительности;
* стрессовым тестированием;
* тестированием практичности.
Тем не менее, если вероятность дефектов в коде, разработанном с использованием TDD, невелика, роль профессионального тестирования меняется. Если обычно профессиональное тестирование используется для постоянного надзора за работой программистов, то при использовании TDD профессиональное тестирование больше напоминает вспомогательный инструмент, облегчающий коммуникацию между теми, кто знает, как должна работать система, и теми, кто создает систему.
Как можно оценить качество разработанных нами тестов? Вот два широко распространенных метода:
* Покрытие операторов кода (statement coverage). Для оценки качества тестов этой характеристики недостаточно, однако ее можно использовать как отправную точку. Если программист ревностно следует всем требованиям TDD, покрытие функционального кода тестами должно составлять 100%.
...
* Намеренное добавление дефекта (defect insertion).
стр. 95
В главе 32 приводится пример задачи, для решения которой я написал 6 тестов, а человек, профессионально занимающийся тестированием, - 65 тестов.
стр. 95
Существуют три важных навыка, которые необходимо освоить тем, кто впервые изучает TDD:
* три основных подхода, которые используются для того, чтобы заставить тест срабатывать: подделка реализации (Fake It), триангуляция (Triangualation) и очевидная реализация (Obvious Implementation);
* удаление дублирования между функциональным кодом и тестами - важный способ формирования дизайна;
* способность контролировать расстояние между тестами: когда дорога становится скользкой, необходимо двигаться маленькими шажками; когда дальнейший путь ясен, можно увеличить скорость.
стр. 127
Что происходит, когда уровень стресса возрастает?
Чем больший стресс вы ощущаете, тем меньше вы тестируете разрабатываемый код. Чем меньше вы тестируете разрабатываемый код, тем больше ошибок вы допускаете. Чем больше ошибок вы допускаете, тем выше уровень стресса, который вы ощущаете. Получается замкнутый круг с позитивной обратной связью: рост стресса приводит к росту стресса.
стр. 129
Что необходимо тестировать? Прежде чем начать, запишите на листке бумаги список всех тестов, которые вам потребуются. Чтобы успешно справляться с программистским стрессом, вы должны постоянно соблюдать важное правило: никогда не делайте шага вперед до тех пор, пока не узнаете, в каком месте ваша нога должна коснуться земли. Приступая к сеансу программирования, определите, какие задачи вы намерены решить в ходе этого сеанса.
В рамках весьма распространенной стратегии предлагается держать все в голове. Я пробовал использовать этот подход в течение нескольких лет, однако постоянно сталкивался с одной и той же проблемой. По мере того как я работаю, передо мной возникают все новые и новые задачи, которые необходимо решить. Чем больше задач предстоит решить, тем меньше внимания я уделяю тому, над чем я работаю. Чем меньше внимания я уделяю тому, над чем я работаю, тем меньше задач мне удается решить. Чем меньше задач мне удается решить, тем больше вещей, о которых мне приходится помнить в процессе работы. Замкнутый круг.
...
Я выработал привычку записывать на листик бумаги все задачи, которые я планирую решить в течение нескольких следующих часов. Этот листик постоянно лежит рядом с моим компьютером. Похожий список задач, которые я планирую решить в течение ближайшей недели или ближайшего месяца, приколот к стене над моим компьютером. Если я записал все эти задачи на бумагу, я уверен в том, что я ничего не забуду. Если передо мной возникает новая задача, я быстро и осознанно решаю, к какому списку ("сейчас" или "позднее") она принадлежит и нужно ли вообще ей заниматься.
стр. 131
Консервативные скалолазы придерживаются одного важного правила. У человека есть две руки и две ноги, всего четыре конечности, которыми он может цепляться за скалу. В любой момент времени по крайней мере три конечности должны быть надежно сцеплены со скалой. Динамические перемещения, когда скалолаз перемещает с места на место одновременно две конечности, считаются чрезвычайно опасными. Методика TDD в чистом виде подразумевает использование похожего принципа: в любой момент времени вы должны быть не дальше одного изменения от зеленой полосы.
стр. 134
Альтернативой паттерна Test Data (Тестовые данные) является паттерн Realistic Data (Реалистичные данные), в рамках которого для тестирования используются данные из реального мира. Реалистичные данные удобно применять в следующих ситуациях:
* вы занимаетесь тестированием системы реального времени, используя цепочки внешних событий, которые возникают в реальных условиях эксплуатации этой системы;
* вы сравниваете вывод текущей системы с выводом предыдущей системы (параллельное тестирование);
* вы выполняете рефакторинг кода, имитирующего некоторый реальный процесс, и ожидаете, что после выполнения рефакторинга результирующие данные будут в точности такими же, как до рефакторинга, в особенности, если речь идет о точности операций с плавающей точкой.
стр. 135
Паттерн Evident Data (Понятные данные) выглядит, как исключение из правила о том, что в коде не должно быть "магических" чисел. Дело в том, что в рамках одного метода легко понять предназначение того или иного числа. Однако если в программе уже имеются объявленные символьные константы, я предпочитаю использовать их вместо конкретных численных значений.
стр. 140
Джим Ньюкирк рассказал мне о проекте, в котором разработка тестов для обучения выполнялась на регулярной основе. Как только от сторонних разработчиков поступала новая версия пакета, в отношении этого пакета немедленно запускались имеющиеся тесты. В случае необходимости в тесты вносились исправления. Если тесты не срабатывали, не было никакого смысла запускать приложение, так как оно определенно не заработает. Если же все тесты срабатывают, значит и приложение заработает.
стр. 143
Иногда в случае, если перед вами стоит сложная проблема, вам требуется, наоборот, поднажать, поднапрячься и потратить дополнительное время и усилия для того, чтобы решить ее. Однако большинство программистов инфицировано духом саморазрушения: "Я угроблю свое здоровье, отрекусь от своей семьи и даже выпрыгну из окна, лишь бы этот код заработал". Поэтому я не буду давать здесь каких-либо советов. Если вы чувствуете, что у вас развивается болезненное пристрастие к кофе, наверное, вам не стоит делать слишком частых перерывов. В крайнем случае, просто пройдитесь.
стр. 146
http://www.mockobjects.com/
стр. 146
Паттерн Fake It (Подделка) напоминает страховочную веревку, которая соединяет вас с верхней точкой маршрута, когда вы карабкаетесь по скале. Пока что вы еще не забрались на самый верх (тест на месте и работает, но тестируемый код некорректен). Однако в любой точке маршрута вы держитесь за веревку и знаете, что когда достигнете самого верха, то будете в безопасности (тест срабатывает в ходе рефакторинга, а также после того, как вы получили окончательный результирующий код).
Паттерн Fake It (Подделка) многим может показаться совершенно бесполезным. Зачем писать код, который абсолютно точно придется заменять другим? Дело в том, что иметь хоть какой-то работающий код - это лучше, чем вообще не иметь работающего кода, в особенности если у вас есть тесты, которые могут доказать работоспособность кода.
...
При использовании паттерна Fake It (Подделка) возникает как минимум два положительных эффекта:
* Психологический. Если перед вами зеленая полоса, вы чувствуете себя совершенно иначе, чем если перед вами красная полоса. Когда полоса зеленая, вы знаете, на чем стоите. Вы можете смело и уверенно приступать к рефакторингу.
* Контроль надо объемом работы. Программисты привыкли пытаться предвидеть возникновение в будущем самых разнообразных проблем. Если вы начинаете с конкретного примера и затем осуществляете обобщение кода, это помогает вам избавиться от лишних опасений. Вы можете сконцентрироваться на решении конкретной проблемы и поэтому выполнить работу лучше. При переходе к следующему тесту вы опять же концентрируетесь на нем, так как знаете, что предыдущий тест гарантированно работает.
стр. 165
McConnell, Steve. 1993. Code Complete, Seattle, Washington: Microsoft Press
Caine, S. H., Gordon, E. K. 1975. PDL: A Tool for Software Design, AFIPS Proceedings of the 1975 National Computer Conference
стр. 176
Подробнее об этом паттерне рассказывается в книге
Beck, K. 1997. The Smalltalk Best Practice Patterns, Englewood-Cliffs, NJ: Prentice-Hall
стр. 184
Fowler, Martin. 1999. Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley
Файлер. М. Рефакторинг: улучшение существующего кода. СПб.: Символ-Плюс, 2003.
стр. 199
Это отчасти напоминает игру "Угадай мелодию" ("Я могу закодировать задачу за четыре теста!" - "А я - за три!" - "О'кей попробуйте"). Для решения задачи я написал шесть тестов, а Боб Биндер (Bob Binder) в своей книге Testing Object-Oriented Systems (Тестирование объектно-ориентированных систем) для этой же самой задачи написал 65 тестов. Сколько на самом деле нужно тестов? Вы должны решить это сами, исходя из собственного опыта и рассуждений.
Имеет ли смысл писать тот или иной тест? Это зависит от того, насколько аккуратно вы оцените MTBF. Если обстоятельства требуют, чтобы вы увеличили MTBF от 10 лет до 100 лет, значит, имеет смысл уделить время для разработки самых маловероятных и чрезвычайно редко возникающих ситуаций (если, конечно, вы не можете каким-либо иным образом доказать, что подобные ситуации никогда не могут возникнуть).
Взгляд на тестирование в рамках TDD прагматичен. В TDD тесты являются средством достижения цели. Целью является код, в корректности которого мы в достаточной степени уверены. Если знание особенностей реализации без какого-либо теста дает нам уверенность в том, что код работает правильно, мы не будем писать тест. Тестирование черного ящика (когда мы намеренно игнорируем реализацию) обладает рядом преимуществ. Если мы игнорируем код, мы наблюдаем другую систему ценностей: тесты сами по себе представляют для нас ценность. В некоторых ситуациях это вполне оправданный подход, однако он отличается от TDD.
Binder, Bob. 1999. Testing Object-Oriented Systems: Models, Patterns, and Tools. Boston: Addison-Wesley. Это действительно исчерпывающее руководство по тестированию.
стр. 206
Mars Lander - американский космический аппарат, был запущен в сторону Марса 3 января 1999 г. 3 декабря 1999 г. аппарат должен был осуществить посадку на Марс, однако в этот день связь с ним была потеряна, предположительно из-за ошибки в программном обеспечении. Стоимость миссии составила приблизительно 120 млн. долларов, не считая стоимости ракеты-носителя и некоторого дополнительного оборудования. - Примеч. перев.
стр. 213
Weinberg, Gerald. 1992. Systems Thinking. Quality Software Management. New York: Dorset House
стр. 215
Когда время начинает поджимать, вы снижаете интенсивность тестирования, что приводит к увеличению количества ошибок, что, в свою очередь, приводит к еще большему недостатку времени. Со временем на сцене появляется некоторое внешнее действие (например, недостаток денег), которое заставляет вас завершить работу над проектом, несмотря ни на что.
Если вы имеете дело с системой, которая ведет себя не так, как вам того хотелось бы, у вас есть несколько вариантов исправить ситуацию:
* Сформируйте цикл позитивной обратной связи в обратном направлении. Если у вас цикл между тестами и уверенностью, и тесты не срабатывают, снижая тем самым уверенность, тогда вы можете сделать больше срабатывающих тестов, повысив тем самым уверенность в вашей способности увеличить количество срабатывающих тестов.
* Сформируйте цикл негативной обратной связи, который позволит вам контролировать действие, интенсивность которого стала слишком большой.
* Создайте или разорвите соединения для того, чтобы устранить циклы, не являющиеся полезными.