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

не для больших объемов данных, а для сбора той же самой статистики.

ну пох =) просто имхо для данного случая результат будет принципиально разнИца при первом тесте, в остальных будет уже среднее значение. ну кароч кто как хочет, тот так и тестит

Ага, после "окончания программирования" оптимизировать как правило уже поздно, ибо код к тому моменту представляет собой мусорник без крышки.

Неправда Оптимизированный код читать куда сложнее чем неоптимизированный.

Обычный процесс разработки: программирование как удобно, написание тестов и их прогон, рефакторинг, прогон тестов. И так до полного удовлетворения. Затем работа с профайлером, выяснение узких мест и их оптимизация. И вот после этого код уже вполне может стать не таким красивым и элегантным. (До этого код прост и понятен, в результате рефакторинга, главное рефакторить почаще)

З.Ы.
В общем, присоединюсь к Ra$cal, читайте Фаулера.

З.З.Ы.
Ну вообще тесты рекомендуют писать до написания кода, но у меня на практике так ни разу не получалось.

__________________
Я отдал бы немало за пару крыльев,
Я отдал бы немало за третий глаз
За руку на которой четырнадцать пальцев
Мне нужен для дыхания другой газ..

Мой блог:http://qwazar.ru/.

Кстати да. Забыл сказать, что я за первый вариант для веба.
Больше пары десятков итераций на практике не встречается.

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

PS
И кстати на возможное снижение производительности при замене переменной на вызов метода - пишет сам же Фаулер в той же книжке.

Algol, дык рефакторинг для того и придуман, чтобы избавляться от грязного кода. А оптимизация (не считая алгоритмической), часто бывает избыточной, и отнимает слишком много времени, для этого и не следует оптимизировать пока не пробежишься по коду профайлером. Это делается после получения работоспособной версии. А задача тестов, не в том чтобы выявлять слабые места программы, а в том, чтобы гарантировать неизменность её работоспособности при последующих изменениях, в том числе при рефакторинге и оптимизации. (Ну или, если полностью следовать TDD, ещё показывает процент готовности приложения)

Безусловно. Мало того, рефакторинг зачастую замедляет работу программы. Но при этом хорошо структурированный код проще будет оптимизировать.

__________________
Я отдал бы немало за пару крыльев,
Я отдал бы немало за третий глаз
За руку на которой четырнадцать пальцев
Мне нужен для дыхания другой газ..

Мой блог:http://qwazar.ru/.

он пишет о других типах методов. которые выполняют вычисления. гетеры и сетеры к этим типам методов не относятся.