Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Бек К. -> "Экстремальное программирование: разработка через тестирование " -> 69

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

Бек К. Экстремальное программирование: разработка через тестирование — СПб.: Питер, 2003. — 224 c.
ISBN 5-8046-0051-6
Скачать (прямая ссылка): bek-k..pdf
Предыдущая << 1 .. 63 64 65 66 67 68 < 69 > 70 71 72 73 74 75 .. 81 >> Следующая


Добавление параметра также может быть вызвано необходимостью миграции от одного представления данных к другому. Вначале вы добавляете параметр, затем вы удаляете из кода все ссылки на старый параметр, затем вы удаляете сам старый параметр.

Method Parameter to Constructor Parameter (Параметр метода в параметр конструктора)

Каким образом переместить параметр из метода или методов в конструктор?

7 Змс.297

Как

1. Добавьте параметр в конструктор.

2. Добавьте в класс экземплярную переменную с тем же именем, что и параметр.

3. Установите значение переменной в конструкторе.

4. Одну за другой преобразуйте ссылки parameter в ссылки this.parameter.

5. Когда в коде не останется ни одной ссылки на параметр, удалите параметр из метода.

6. После этого удалите ненужный теперь префикс this.

7. Присвойте переменной подходящее имя.

Зачем

Если вы передаете один и тот же параметр нескольким разным методам одного и того же объекта, вы можете упростить API, передав параметр только один раз (удалив дублирование). Напротив, если вы обнаружили, что некоторая экземп-лярная переменная используется только в одном методе объекта, вы можете выполнить обратный рефакторинг.

Развитие навыков TDD

В данной главе я намерен сформулировать несколько вопросов, над которыми полезно подумать, если вы намерены интегрировать TDD в используемый вами процесс разработки. Некоторые из вопросов просты, другие требуют тщательного обдумывания. Ответы на некоторые из этих вопросов вы найдете здесь же, однако иногда, чтобы ответить на некоторый вопрос, вам придется провести собственные исследования.

Насколько большими должны быть шаги?

В этом вопросе на самом деле скрыто два вопроса:

• Какой объем функциональности должен покрывать каждый тест?

• Как много промежуточных стадий должно быть преодолено в процессе каждого рефакторинга?

Вы можете писать тесты таким образом, что каждый из них будет требовать добавления в функциональный код единственной строки и выполнения небольшого рефакторинга. Вы также можете писать тесты таким образом, что каждый из них будет требовать добавления в функциональный код сотен строк, при этом у вас будут уходить часы на рефакторинг. Какой из этих путей лучше?

Часть ответа состоит в том, что вы должны уметь работать и так и этак. Общая тенденция TDD очевидна — чем меньше шаги, тем лучше. В данной книге мы занимались разработкой маленьких тестов на уровне отдельных фрагментов программы. Однако некоторые программисты экспериментируют в области разработки программ, исходя из тестов на уровне всего приложения.

Если вы только приступаете к освоению рефакторинга, вы должны двигаться маленькими шажками. Процесс ручного рефакторинга чреват ошибками. Чем больше ошибок вы наделаете, тем меньшим будет ваше желание выполнять рефакторинг в дальнейшем. После того как вы 20 раз проделаете рефакторинг малюсенькими шажками, можете приступать к экспериментам по удлинению этих шажков.

Автоматизация существенно ускоряет процессы, связанные с рефакторингом. То, что раньше требовало от вас выполнения 20 маленьких шагов вручную, теперь становится единственным пунктом в меню. Количество выполняемых вами рефакторингов увеличивается на порядок, и это неизменно сказывается на качестве. Когда вы знаете, что в вашем распоряжении великолепный инструмент, вы становитесь более агрессивным при выполнении рефакторинга. Вы пытаетесь ставить больше экспериментов, и смотреть, какой способ структурирования кода лучше.

На момент написания данной книги браузер рефакторинга Refactoring Browser for Smalltalk по-прежнему является наилучшим инструментом из этой категории. В настоящее время многие среды разработки для Java начинают поддерживать рефакторинг. Кроме того, я уверен, что в скором будущем поддержка рефакторинга появится и в других языках и средах разработки.

Что не подлежит тестированию?

Флип (Phlip) предложил высказывание, которое может служить ответом на этот вопрос: «Пишите тесты до тех пор, пока страх не превратится в скуку». Высказывание подразумевает, что вы должны найти ответ сами. Однако вы читаете эту книгу для того, чтобы найти в ней ответы на вопросы, поэтому попробуйте воспользоваться следующим списком. Тестировать следует:

• условные операторы;

• циклы;

• операции;

• полиморфизм.

Однако только те из них, которые вы написали сами. Не тестируйте чужой код, если только у вас нет причин не доверять ему. В некоторых ситуациях недостатки (можно сказать жестче: «ошибки») во внешнем коде заставляют вас добавлять дополнительную логику в разрабатываемый вами код. Надо ли тестировать подобное поведение внешнего кода? Иногда я документирую непредсказуемое поведение (ошибку) внешнего кода при помощи теста, который перестанет срабатывать в случае, если в следующей версии внешнего кода ошибка будет исправлена

Как определить качество тестов?

Тесты — это канарейка, которую берут в угольную шахту для того, чтобы по ее поведению определить присутствие запаха плохого дизайна. Далее перечисляются некоторые атрибуты тестов, которые указывают на то, что дизайн тестируемого кода начинает плохо пахнуть:
Предыдущая << 1 .. 63 64 65 66 67 68 < 69 > 70 71 72 73 74 75 .. 81 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100