Здравствуйте, Aikin, Вы писали:

AVK>>Когда сильно ковыряешь, unit-тесты очень плохи, так как висят свинцовой гирей и мешают проводить глубокий рефакторинг.
A>Тесты -- это код. Любой код висит свинцовой гирей, когда "сильно ковыряешь".

Большое количество тестов "всего лишь" увеличивает его количество.

AVK>> А толку от них никакого, так как они пачками становятся просто неактуальными на новом дизайне.
A>Мы все еще про юнит-тесты говорим? Тогда о каких пачках идет речь?

Об обычных. Глубокий рефакторинг ломает конктракты — ломаются все связанные с этим тесты.

A> (отвечать не нужно

Сам с собою?

A>: Когда тестов много, они все равно разбиты на 2-3 группы внутри которых тесты похожи как близнецы -- менять их не сложно)

Может и не сложно, но это таки лишняя работа.

A>Юнит-тесты -- тесты на один класс. В основном.

Я в курсе.

A>Если требования влекут изменения интерфейса "центрального класса", то обычно достаточно подправить тесты в соответствии с новым интерфейсом. И все опять "зазелененло".

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

A> В особо сложных случаях интерфейс и тесты меняются итеративно (в конце каждой итерации все должно "зеленеть").

Во во.

A>Еще одна мысль к размышлению:
A>Тесты -- это требования к классу.

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

Pzz>>>А иначе придется еще и тесты ковырять, не только класс.
A>Pzz, вас же не смущает, что при изменении класса код соседних так же обычно приходится ковырять? Воспринимайте тесты как код. Полезный код. И все будет ОК.

Т.е. надо просто мантру прочесть и поверить?

Здравствуйте, netch80, Вы писали:

AVK>>Когда сильно ковыряешь, unit-тесты очень плохи, так как висят свинцовой гирей и мешают проводить глубокий рефакторинг. А толку от них никакого, так как они пачками становятся просто неактуальными на новом дизайне.

N>И что с того?

Дополнительная работа.

N> Естественно, что рефакторинг что-то меняет. И если связи между компонентами (неважно, какого уровня) меняются, то и тесты на специфическую реализацию этих связей ломаются и требуют исправления. Но если по этому поводу плакать, то получается, что вообще ничего кроме самого внешнего функционала не надо тестировать, потому что всё остальное может меняться. Так, что ли?

Нет, не так. Доводение до абсурда доказывает лишь то, что все можно довести до абсурда.

Pzz>>>А иначе придется еще и тесты ковырять, не только класс.
AVK>>Вот именно.
N>И ничего в этом плохого нет. Если тест сломался, значит, его зацепило.

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

Здравствуйте, AndrewVK, Вы писали:

AVK>А потом оказалось, что надо еще подрихтовать. И опять тесты правим. А потом еще.
AVK>В результате либо мы делаем кучу обезьянней работы, либо пишем тесты в конце рефакторинга, что как бы не комильфо.
Вот прочитаешь такую фразу и думаешь, а ведь все верно. Но только для того кто действительно пишущего тесты становитсья понятно, что работы там совсем не куча, а максимум перегруппировать параметры методов, добавить новые, подправить инициализацию класса (тем более, что крупные изменения будут разбиты на шаги, многие из которых автоматизированы Решарпером).
Работы не много, а результатом ее будет гарантия что ты своим новым интерфейсом ничего не поломал.

80% нашей работы -- обезьянья. И чо теперь? Не работать?

A>>Еще одна мысль к размышлению:
A>>Тесты -- это требования к классу.

AVK>Функциональные тесты — да, требования. А юнит — всего лишь контроль контракта. Тоже вроде как требования, только актуальные в рамках конкретного готового дизайна, а не входных задач. Дизайн меняется (даже без изменения входных требований) — конкретные спецификации становятся неактуальны.
Именно про требования "в рамках конкретного готового дизайна" я и говорю. Что не так?


AVK>>> А толку от них никакого, так как они пачками становятся просто неактуальными на новом дизайне.
A>>Мы все еще про юнит-тесты говорим? Тогда о каких пачках идет речь?
AVK>Об обычных. Глубокий рефакторинг ломает конктракты — ломаются все связанные с этим тесты.
Любой рефакторинг идет итеративно, небольшими шажками. Тесты отваливаются постепенно. В конце каждой итерации зеленыее тесты поддтверждат корректность текущего шага.
Я вообще не представляю как можно делать рефакторинг в стиле "все похерим, а потом разберемся".
При "очень глубоком рефакторинге" классы вместе с тестами проще выкинуть, чем изменять.

И вообще, как часто системе необходим "глубоком рефакторинг" (и что это за зверь-то?)

A>>: Когда тестов много, они все равно разбиты на 2-3 группы внутри которых тесты похожи как близнецы -- менять их не сложно)
AVK>Может и не сложно, но это таки лишняя работа.
Кому лишняя -- пусть не меняет тесты. Пусть вообще их не пишет. Для меня польза от этой "лишней работы" существенно превышает затраты.

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:

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

Не распарсил

A>Работы не много, а результатом ее будет гарантия что ты своим новым интерфейсом ничего не поломал.

Т.е. главное — убедить себя, что работы немного. Понятно.

A>80% нашей работы -- обезьянья.

Говори за себя.

A> И чо теперь? Не работать?

Нет, учится уменьшать ее количество.

AVK>>Функциональные тесты — да, требования. А юнит — всего лишь контроль контракта. Тоже вроде как требования, только актуальные в рамках конкретного готового дизайна, а не входных задач. Дизайн меняется (даже без изменения входных требований) — конкретные спецификации становятся неактуальны.
A>Именно про требования "в рамках конкретного готового дизайна" я и говорю. Что не так?

Не так — когда сам дизайн меняется. Юнит-тесты при этом большими кусками перестают выполнять свою работу. Всего лишь. Это, в свою очередь, удорожает рефакторинг. А дальше ты сам должен думать — стоит ли оно того. И нет, не путем уговаривания себя, что таки стоит, а путем вдумчивого взвешивания всех плюсов и минусов.

AVK>>Об обычных. Глубокий рефакторинг ломает конктракты — ломаются все связанные с этим тесты.
A>Любой рефакторинг идет итеративно, небольшими шажками.

Не любой.

A>При "очень глубоком рефакторинге" классы вместе с тестами проще выкинуть, чем изменять.

Классы — нет, не проще. Тесты — да, проще. О чем и речь.

A>И вообще, как часто системе необходим "глубоком рефакторинг" (и что это за зверь-то?)

Нормативов нет, если ты об этом. Все зависит от потребностей.

AVK>>Может и не сложно, но это таки лишняя работа.
A>Кому лишняя -- пусть не меняет тесты. Пусть вообще их не пишет. Для меня польза от этой "лишней работы" существенно превышает затраты.

Ага, главное — верить.

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Когда сильно ковыряешь, unit-тесты очень плохи, так как висят свинцовой гирей и мешают проводить глубокий рефакторинг. А толку от них никакого, так как они пачками становятся просто неактуальными на новом дизайне.

N>>И что с того?
AVK>Дополнительная работа.
А дебагинг очень нетривиального бага внесенного рефакторингом без тестов это не доп. работа? А работа QA который нашел этот баг? А время и головную заказчика, который не смог сделать то что ему нужно или еще хуже сделал то, что ему не нужно ты учитываешь?


Pzz>>>>А иначе придется еще и тесты ковырять, не только класс.
AVK>>>Вот именно.
N>>И ничего в этом плохого нет. Если тест сломался, значит, его зацепило.

AVK>Вопрос лишь в адекватности этого зацепления. В большинстве случаев, при сильном рефакторинге, я и так в курсе, какие тесты и почему сломаются до их запуска. Т.е. их срабатывание не приносит никакой пользы, и никто их не чинит, их либо основательно переписывать надо сразу, до запуска, либо вообще выкидывать, если тестируемый ими контракт изменился до неузнаваемости.
Ценность тестов при рефакторинге не только в том, чтобы указать что именно ты сломал, но и в том, чтобы в конце ты все "вернул на место". Т.е. оставил логику в том же состоянии что и до рефакторинга. Это раз.
Второй момент заключается в том, что хоть ты и предполагаешь какие именно тесты упадут (не будем говорить про изменение контрактов, когда компилятор может указать на ошибки), не не можешь быть 100% уверен, что не упадет что-то еще или что некоторые тесты изменения не затронут.
Опять же мы не рассматриваем очевидные случаи. Для них тестов (юнит) не будет.

Здравствуйте, Aikin, Вы писали:

A>Ценность тестов при рефакторинге не только в том, чтобы указать что именно ты сломал, но и в том, чтобы в конце ты все "вернул на место". Т.е. оставил логику в том же состоянии что и до рефакторинга. Это раз.

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

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Функциональные тесты — да, требования. А юнит — всего лишь контроль контракта. Тоже вроде как требования, только актуальные в рамках конкретного готового дизайна, а не входных задач. Дизайн меняется (даже без изменения входных требований) — конкретные спецификации становятся неактуальны.
A>>Именно про требования "в рамках конкретного готового дизайна" я и говорю. Что не так?

AVK>Не так — когда сам дизайн меняется. Юнит-тесты при этом большими кусками перестают выполнять свою работу. Всего лишь. Это, в свою очередь, удорожает рефакторинг.
Вывод не верный. Хоть и похоже на правду. Давай я свою "правду" озвучу:
Когда сам дизайн менятся, функциональность существующих классов переноситься в другие классы. Чем большее количество логики меняет свое местоположение тем проще ошибиться и сложнее убедиться в том, что мы ничего не сломали рефакторингом. Чтобы убедиться в правильности рефакторинга нужно делать его ооочень внимательно и осторожно. А после окончания нужно обязательно прогнать систему по основным сценариям. Выявятся баги (куда же без них). Чтобы локализовать баг и исправить причину приходится дебажить, иногда очень долго. Это, в свою очередь, удорожает рефакторинг.

AVK>А дальше ты сам должен думать — стоит ли оно того. И нет, не путем уговаривания себя, что таки стоит, а путем вдумчивого взвешивания всех плюсов и минусов.
Спасибо за совет К.О.

AVK>>>Об обычных. Глубокий рефакторинг ломает конктракты — ломаются все связанные с этим тесты.
A>>Любой рефакторинг идет итеративно, небольшими шажками.
AVK>Не любой.
Тогда удачи тебе в глубоких рефакторингах одним махом.

A>>При "очень глубоком рефакторинге" классы вместе с тестами проще выкинуть, чем изменять.
AVK>Классы — нет, не проще. Тесты — да, проще. О чем и речь.
Юнит-тесты всегда значительно проще чем логика класса. Иначе в них практического смысла нет.
Если же тест сложнее класса, то (на это должна быть причина) класс этот отвечает за критическую функциональность.

AVK>>>Может и не сложно, но это таки лишняя работа.
A>>Кому лишняя -- пусть не меняет тесты. Пусть вообще их не пишет. Для меня польза от этой "лишней работы" существенно превышает затраты.
AVK>Ага, главное — верить.
Ага, главное -- не верить. Ведь ты мне не поверишь, если я скажу, что переодически обнаруживаю ошибки в коде после восстановления тестов.

Здравствуйте, AndrewVK, Вы писали:

A>>Ценность тестов при рефакторинге не только в том, чтобы указать что именно ты сломал, но и в том, чтобы в конце ты все "вернул на место". Т.е. оставил логику в том же состоянии что и до рефакторинга. Это раз.
AVK>Пошел по кругу. Это работает для юнит-тестов только если не меняются контракты. Т.е. при неглубоком рефакторинге, на уровне внутренней реализации одного класса. Речь же шла не об этом.
Когда контракты не меняются тесты вообще не трогаются. О чем речь?


С остальным ты согласен?

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, gandjustas, Вы писали:

G>>>>2)Unit-тесты абсолютно нет смысла писать после кода
G>>>>Если вы создавая приложение выделяете некоторую стабильную часть кода, которую редко затрагивают при изменении требований, и которая используется другими частями приложения, то её нужно покрывать unit-тестами.
AVK>>>Проблема только в том, что стабильность участков кода обычно определяется уже после их написания, что несколько противоречит твоему п.2.
G>>Тут именно и вопрос в том что стабильная часть кода должна быть определена заранее. Как некоторый framework, на основе которого будет строиться приложение.

N>Здесь AndrewVK более прав: определение стабильной части кода заранее на практике скорее невозможно, а там, где возможно, она уже стабилизировалась давно (и обычно выглядит в виде библиотеки) и требует наличия тестов уже до текущей работы.
Практика как раз подтверждает обратное. Ведь существуют кучи фреймворков, может не все удачные, но они есть.

N>Твои примеры с бухгалтерией, физическим или графическим движком мне кажутся неадекватными. В них есть много тонкостей, которые могут на второй уже версии сильно меняться. Например, следующий DirectX, или требование пересчёта баланса впараллель на нескольких ядрах вместо текущего одного ядра могут переломать всю архитектуру слоя поддержки.
И? Одна тонкость не ставит под сомнение существование самих движков. И уж точно не говорит о том что их нельзя покрывать тестами.

N>Поэтому разумно просто отвести ресурсы на написание тестов, не конкретизируя, какие именно они должны быть. Где-то это юнит-тесты до каждой строчки кода, где-то — функциональный на группу классов. Осталось, чтобы руководитель согласился с критериями разумности.
Если рассматривать тесты только как пожиратель ресурсов, то их вообще писать не стоит. Я например прекрасно вижу преимущества unit-тестов в виде формально проверяемых спецификаций, а также как регрессионное тестирование. Если вы не видите, то вам они не нужны.

G>>>>Если же код вашего модуля относительно простой, и\или часто подвержен изменениям из-за изменяющихся требований, и\или опирается на некоторый внешний функционал, то лучше не делать unit-тесты, а integration-тесты.
AVK>>>Интеграционные тесты не делаются для отдельного модуля. По определению.
G>>Да, они делаются для модуля и некоторого подмножества связанных с ним. Обычно для самого модуля+вызываемых модулей из низлежащих слоев.
N>Для меня это будет называться, скорее всего, функциональными тестами (а интеграционными будут проверки суммарной функциональности нескольких крупных блоков, не подчинённых друг другу, а работающими совместно).

Без разницы совершенно как оно будет называться.

Функциональные тесты — это тесты которые тестируют функционал, они бывают unit-тестами, которые тестируют один модуль в изоляции от других и интеграционными тестами, которые тестируют несколько модулей в связке.

Я обычно такой терминологией пользуюсь, но если вам удобно используйте любую другую.

Здравствуйте, gandjustas, Вы писали:

G>>>>>2)Unit-тесты абсолютно нет смысла писать после кода
G>>>>>Если вы создавая приложение выделяете некоторую стабильную часть кода, которую редко затрагивают при изменении требований, и которая используется другими частями приложения, то её нужно покрывать unit-тестами.
AVK>>>>Проблема только в том, что стабильность участков кода обычно определяется уже после их написания, что несколько противоречит твоему п.2.
G>>>Тут именно и вопрос в том что стабильная часть кода должна быть определена заранее. Как некоторый framework, на основе которого будет строиться приложение.

N>>Здесь AndrewVK более прав: определение стабильной части кода заранее на практике скорее невозможно, а там, где возможно, она уже стабилизировалась давно (и обычно выглядит в виде библиотеки) и требует наличия тестов уже до текущей работы.
G>Практика как раз подтверждает обратное. Ведь существуют кучи фреймворков, может не все удачные, но они есть.

Если ты пользуешься готовым фреймворком, то он отделён и развивается отдельно.
Если ты его создаёшь в процессе развития своего кода выделением из него, он вначале нестабилен.

N>>Твои примеры с бухгалтерией, физическим или графическим движком мне кажутся неадекватными. В них есть много тонкостей, которые могут на второй уже версии сильно меняться. Например, следующий DirectX, или требование пересчёта баланса впараллель на нескольких ядрах вместо текущего одного ядра могут переломать всю архитектуру слоя поддержки.
G>И? Одна тонкость не ставит под сомнение существование самих движков.

Она подтверждает AVK: "стабильность участков кода обычно определяется уже после их написания".

G> И уж точно не говорит о том что их нельзя покрывать тестами.

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

N>>Поэтому разумно просто отвести ресурсы на написание тестов, не конкретизируя, какие именно они должны быть. Где-то это юнит-тесты до каждой строчки кода, где-то — функциональный на группу классов. Осталось, чтобы руководитель согласился с критериями разумности.
G>Если рассматривать тесты только как пожиратель ресурсов, то их вообще писать не стоит.

Вывод про "только" высосан из пальца.

G> Я например прекрасно вижу преимущества unit-тестов в виде формально проверяемых спецификаций, а также как регрессионное тестирование.

Регрессионное — да. Формально проверяемая спецификация — нет. Для этого нужна верификация, а не тестирование.
(В самом выдающемся случае можно уже из спецификаций породить тесты по методу quickcheck или PropEr — на случайных данных — и с какой-то вероятностью через некоторое слабопредсказуемое время найти контрпример.)

G> Если вы не видите, то вам они не нужны.

Грубый и бессмысленный наезд. Правильно было бы сказать, что они местами нужны больше, местами — меньше.

Здравствуйте, netch80, Вы писали:


N>>>Твои примеры с бухгалтерией, физическим или графическим движком мне кажутся неадекватными. В них есть много тонкостей, которые могут на второй уже версии сильно меняться. Например, следующий DirectX, или требование пересчёта баланса впараллель на нескольких ядрах вместо текущего одного ядра могут переломать всю архитектуру слоя поддержки.
G>>И? Одна тонкость не ставит под сомнение существование самих движков.

N>Она подтверждает AVK: "стабильность участков кода обычно определяется уже после их написания".
Что ты понимаешь под стабильностью? Я говорил про части кода, на которые не влияют или мало влияют изменения требований для приложения. Граф. движок очень хорошо подходит.

G>> И уж точно не говорит о том что их нельзя покрывать тестами.
N>Этого я и не говорю. Но уровень затрат ресурсов на покрытие тестами может и часто должен меняться в зависимости от того, насколько стабилизировались
внешние условия и представления об основах реализации. Нет смысла плотно покрывать тестами то, что может завтра быть вынесено к лешим.
Именно, но ведь не любой код одинаково подвержен изменениям? Или ты вообще не можешь сказать насколько подвержена изменениям тот или иной модуль?

N>>>Поэтому разумно просто отвести ресурсы на написание тестов, не конкретизируя, какие именно они должны быть. Где-то это юнит-тесты до каждой строчки кода, где-то — функциональный на группу классов. Осталось, чтобы руководитель согласился с критериями разумности.
G>>Если рассматривать тесты только как пожиратель ресурсов, то их вообще писать не стоит.
N>Вывод про "только" высосан из пальца.
Ты про другое не пишешь.

G>> Я например прекрасно вижу преимущества unit-тестов в виде формально проверяемых спецификаций, а также как регрессионное тестирование.
N>Регрессионное — да. Формально проверяемая спецификация — нет. Для этого нужна верификация, а не тестирование.
Если язык позволяет статически верифицировать то да, а иначе только тестами. Других способов доказать что код соотвествует спецификации просто нет.

G>> Если вы не видите, то вам они не нужны.
N>Грубый и бессмысленный наезд. Правильно было бы сказать, что они местами нужны больше, местами — меньше.
Это уже вам решать.

Я привел доводы когда можно использовать unit-тесты. Доводы соответствуют опыту. Не согласны — никто же не заставляет вас использовать unit-тест.
Своих же доводов вы не приводите. Это отчасти и подталкивает к мысли что вы не видите ценности тестов.

Здравствуйте, DorfDepp, Вы писали:

DD>...если они на практике ничего не ловят. Каждый метод будет прекрасно работать в изоляции, а упадет обязательно на нестыковке компонент, из-за старого формата данных в базе и т.п. Ради чего надо писать 10 минут метод и потом час-два к нему тесты, если пользы ровно ноль?
Про то что не ловят довольно спорно. Если код нормально покрыт юнит-тестами, то они вполне ловят "изменения логики для фикса моего бага": например, человеку написали баг, он нашел что в каком-то условии можно что-то убрать и убирает (не особо вникая в суть этого метода), баг перестает воспроизводится, но что-то может поломаться. Юнит-тесты заставляют еще раз задуматься об изменениях, помогают принимать более осознанные решения.
Кроме того юнит-тесты отвечают не на вопрос:
Что сломалось?
а больше на вопрос:
Где сломалось?

Самый большой плюс:
Помогают писать более чистый код!
На метод из 100500 строк с кучей условий, юнит-тесты (особенно на моках) написать (покрыть на 100%) довольно сложно.

Здравствуйте, gandjustas, Вы писали:

N>>>>Твои примеры с бухгалтерией, физическим или графическим движком мне кажутся неадекватными. В них есть много тонкостей, которые могут на второй уже версии сильно меняться. Например, следующий DirectX, или требование пересчёта баланса впараллель на нескольких ядрах вместо текущего одного ядра могут переломать всю архитектуру слоя поддержки.
G>>>И? Одна тонкость не ставит под сомнение существование самих движков.
N>>Она подтверждает AVK: "стабильность участков кода обычно определяется уже после их написания".
G>Что ты понимаешь под стабильностью? Я говорил про части кода, на которые не влияют или мало влияют изменения требований для приложения. Граф. движок очень хорошо подходит.

А я объяснил, как на самом деле они могут повлиять принципиально, хотя кажется, что не могут.:)

G>>> И уж точно не говорит о том что их нельзя покрывать тестами.
N>>Этого я и не говорю. Но уровень затрат ресурсов на покрытие тестами может и часто должен меняться в зависимости от того, насколько стабилизировались внешние условия и представления об основах реализации. Нет смысла плотно покрывать тестами то, что может завтра быть вынесено к лешим.
G>Именно, но ведь не любой код одинаково подвержен изменениям? Или ты вообще не можешь сказать насколько подвержена изменениям тот или иной модуль?

Заранее — нет. Требования постоянно уточняются и изменяются. Предсказать необходимое даже на год может быть достаточно тяжело, на большее время — практически невозможно. С каждой новой установкой мы получаем какие-то новые требования, под которые надо адаптироваться.

N>>>>Поэтому разумно просто отвести ресурсы на написание тестов, не конкретизируя, какие именно они должны быть. Где-то это юнит-тесты до каждой строчки кода, где-то — функциональный на группу классов. Осталось, чтобы руководитель согласился с критериями разумности.
G>>>Если рассматривать тесты только как пожиратель ресурсов, то их вообще писать не стоит.
N>>Вывод про "только" высосан из пальца.
G>Ты про другое не пишешь.

Это как и чем, извините, надо читать, чтобы сделать такой вывод? Я постоянно прямым текстом говорю обратное.

G>>> Я например прекрасно вижу преимущества unit-тестов в виде формально проверяемых спецификаций, а также как регрессионное тестирование.
N>>Регрессионное — да. Формально проверяемая спецификация — нет. Для этого нужна верификация, а не тестирование.
G>Если язык позволяет статически верифицировать то да, а иначе только тестами. Других способов доказать что код соотвествует спецификации просто нет.

Ошибка в слове "доказать". Никакими тестами ты не можешь это _доказать_, можешь лишь обещать какую-то вероятность или меру корректности. Она может быть и 99.999%, но не 100%. Доказательство даёт только верификация (в пределах применённой модели, которая сама может быть некорректной).
Тем не менее тесты нужны, потому что практически они действуют достаточно хорошо.

G>Я привел доводы когда можно использовать unit-тесты. Доводы соответствуют опыту. Не согласны — никто же не заставляет вас использовать unit-тест.
G>Своих же доводов вы не приводите. Это отчасти и подталкивает к мысли что вы не видите ценности тестов.

Повторюсь, что я их постоянно привожу. Только особенности Вашего восприятия не позволяют это увидеть.
А "доводы, когда можно использовать unit-test" мне не нужны. Я их и сам напишу толпами.
Мне были бы полезны доводы, когда их реально _нужно_ использовать. Пока что с этим плохо, в основном есть две позиции — "они нахер не нужны" и "покрывайте тестами всё".

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, gandjustas, Вы писали:

G>>>> И уж точно не говорит о том что их нельзя покрывать тестами.
N>>>Этого я и не говорю. Но уровень затрат ресурсов на покрытие тестами может и часто должен меняться в зависимости от того, насколько стабилизировались внешние условия и представления об основах реализации. Нет смысла плотно покрывать тестами то, что может завтра быть вынесено к лешим.
G>>Именно, но ведь не любой код одинаково подвержен изменениям? Или ты вообще не можешь сказать насколько подвержена изменениям тот или иной модуль?

N>Заранее — нет. Требования постоянно уточняются и изменяются. Предсказать необходимое даже на год может быть достаточно тяжело, на большее время — практически невозможно. С каждой новой установкой мы получаем какие-то новые требования, под которые надо адаптироваться.

Так не бывает. В такой ситуации просто невозможно что-то спланировать. Если же рассмотреть рельный случай. Делается 3d игра, для нее пишется движок, она станет 2d? Нет. Алгоритм пересечения луча с плоскостью изменится? Тоже нет.

G>>>> Я например прекрасно вижу преимущества unit-тестов в виде формально проверяемых спецификаций, а также как регрессионное тестирование.
N>>>Регрессионное — да. Формально проверяемая спецификация — нет. Для этого нужна верификация, а не тестирование.
G>>Если язык позволяет статически верифицировать то да, а иначе только тестами. Других способов доказать что код соотвествует спецификации просто нет.

N>Ошибка в слове "доказать". Никакими тестами ты не можешь это _доказать_, можешь лишь обещать какую-то вероятность или меру корректности. Она может быть и 99.999%, но не 100%.
Почему это? Если покрываются все варианты использования, то чем это не доказательство?
Whitebox тестирование может покрыть все варианты использования.

Или ты не писал никогда таких тестов?


N>Тем не менее тесты нужны, потому что практически они действуют достаточно хорошо.
Конкретизируй понятие "хорошо" что ли.

G>>Я привел доводы когда можно использовать unit-тесты. Доводы соответствуют опыту. Не согласны — никто же не заставляет вас использовать unit-тест.
G>>Своих же доводов вы не приводите. Это отчасти и подталкивает к мысли что вы не видите ценности тестов.

N>Повторюсь, что я их постоянно привожу. Только особенности Вашего восприятия не позволяют это увидеть.
Ага, вроде "тесты это хорошо".

N>А "доводы, когда можно использовать unit-test" мне не нужны. Я их и сам напишу толпами.
N>Мне были бы полезны доводы, когда их реально _нужно_ использовать. Пока что с этим плохо, в основном есть две позиции — "они нахер не нужны" и "покрывайте тестами всё".

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

Здравствуйте, gandjustas, Вы писали:

G>>>Именно, но ведь не любой код одинаково подвержен изменениям? Или ты вообще не можешь сказать насколько подвержена изменениям тот или иной модуль?
N>>Заранее — нет. Требования постоянно уточняются и изменяются. Предсказать необходимое даже на год может быть достаточно тяжело, на большее время — практически невозможно. С каждой новой установкой мы получаем какие-то новые требования, под которые надо адаптироваться.
G>Так не бывает. В такой ситуации просто невозможно что-то спланировать. Если же рассмотреть рельный случай. Делается 3d игра, для нее пишется движок, она станет 2d? Нет. Алгоритм пересечения луча с плоскостью изменится? Тоже нет.

Алгоритм — нет. А вот оптимальная реализация — да, может сильно измениться в зависимости от специфики запросов и обстановки.
Насчёт "невозможно что-то спланировать" ты сильно неправ. Возможно. Но планировать надо иначе — умея уточнять обстановку и адаптироваться под неё на ходу. Такое себе agile, только на следующем вверх уровне. И таки да, быть готовым морально и практически к тому, что что-то придётся отменять ещё не доделанное, с сожалением, и переходить к другому.
В быстро развивающемся софте, как у нас, может устаревать 20-30% кода в год. И это не самый суровый темп.

N>>Ошибка в слове "доказать". Никакими тестами ты не можешь это _доказать_, можешь лишь обещать какую-то вероятность или меру корректности. Она может быть и 99.999%, но не 100%.
G>Почему это? Если покрываются все варианты использования, то чем это не доказательство?

Что ты называешь вариантами использования?

G>Whitebox тестирование может покрыть все варианты использования.

Сунул строку "whitebox тестирование" в яндекс. Получил рассказ о том, как наши космические корабли бороздят просторы Большого театра инструменты вроде PEX берут функцию и находят характерные входные данные для проверки. Ты это имел в виду? Или таки вариант проверить все возможные значения множества входных данных? В последнем случае, сколько триллионов лет потребуется тебе для завершения тестирования, например, функции подсчёта длины utf-8 строки, в кодовых пунктах?
А то же самое, но в символах?

G>Или ты не писал никогда таких тестов?

Каких "таких"? Whitebox? Писал. По крайней мере то, что я знаю под этим термином. Но не думаю, что это само по себе позволит накормить 5 хлебами 5K человек всунуть работу до конца Вселенной в сроки в сутках.

N>>Тем не менее тесты нужны, потому что практически они действуют достаточно хорошо.
G>Конкретизируй понятие "хорошо" что ли.

Я не пытаюсь совершить невозможное.

G>>>Я привел доводы когда можно использовать unit-тесты. Доводы соответствуют опыту. Не согласны — никто же не заставляет вас использовать unit-тест.
G>>>Своих же доводов вы не приводите. Это отчасти и подталкивает к мысли что вы не видите ценности тестов.
N>>Повторюсь, что я их постоянно привожу. Только особенности Вашего восприятия не позволяют это увидеть.
G>Ага, вроде "тесты это хорошо".

И что в этом неправильного? Да, это общее руководство. Да, я мог бы сказать, что для наших условий юнит-тест для нетривиальной функции экономит усилия в 10-20-100 раз (в зависимости от местности) по сравнению с выявлением проблемы уже на функциональном тесте приложения и поиском точки проблемы доступными средствами (только логами, поскольку никакой отладчик наши задачи не вытянет), а комплект функциональных тестов хотя бы на базовые сценарии работы приложения экономит ну просто дофига хотя бы на том, что установленная клиенту система в основном работает, а не падает. Но какое другим дело до нашей весьма тяжёлой специфики? У них своя есть, не менее странная.

N>>А "доводы, когда можно использовать unit-test" мне не нужны. Я их и сам напишу толпами.
N>>Мне были бы полезны доводы, когда их реально _нужно_ использовать. Пока что с этим плохо, в основном есть две позиции — "они нахер не нужны" и "покрывайте тестами всё".

G>Любая программа может быть написана без тестов, поэтому необходимости в них нет. Есть примеры когда разные типы тестов дают положительный эффект. Я их привожу, а ты с чем-то споришь.

То есть ты даже не понял, с чем именно я спорю? Тогда, может, следовало начать с более тщательного анализа моих сообщений, прежде чем возражать на них? ;)

Здравствуйте, AndrewVK, Вы писали:

чуть переставлю секции.

AVK>>>Википедия — достаточно массово?
N>>Нет.
AVK>:)))

Ничего смешного. Во-первых, она одна. Во-вторых, в ней тоже есть противоречия. Например, в русской "тестирование белого ящика" в основной статье по тестированию предполагает возможность доступа к коду, но не требует какой-то определённой методики, а отдельная статья по тому же методу — предполагает автоматизированное построение теста по коду с покрытием рассмотренных там условий. Это уже заметно разные подходы. (См. ниже про ещё противоречия.)

У нас же вообще используется ещё одно понимание такого деления — когда blackbox это использование только документированных интерфейсов, а whitebox — с выставления доступа ко всем внутренностям (как если бы все функции экспортировались, а все члены классов были бы public); в частности, такой whitebox нужен для проверки внутренних, но сложных функций, и именно такое деление мне кажется наиболее полезным, и оно формально не совпадает ни с одним из википедийных.

AVK>>>Так что TDD все таки функциональные тесты предполагает в обязательном порядке. А unit уже по желанию.
N>>Это с чего такой вывод? Во-первых, там нет ни слова про functional, integration или что-то подобное, там только test case.
AVK>С того, что "test case that defines a desired improvement or new function" это функциональный тест. По определению:
AVK>

AVK>Functional testing refers to activities that verify a specific action or function of the code. These are usually found in the code requirements documentation, although some development methodologies work from use cases or user stories. Functional tests tend to answer the question of "can the user do this" or "does this particular feature work."

Такое твоё понимание бессмысленно, потому что по нему любой тест, который не является анализом кода без его запуска, является функциональным. Запустили — значит, функциональный тест. Но тогда в чём отличие от других тестов? Я точно так же мог бы сказать не "функциональный тест", а "хрень", потому что функциональный тест — частный случай хрени.

А ответ тут в том, что ты в своём художественном квотинге по тексту этой статьи "упустил" то, что там функциональное тестирование противопоставляется тестированию других характеристик, таких, как нагрузочная способность или защищённость. А в этом случае нет никакого противоречия между functional и unit testing: второе всего лишь частный случай первого, сведённый до одного кусочка кода. Из той же статьи:

Unit testing refers to tests that verify the functionality of a specific section of code, usually at the function level.

Английским по фоновому — "verify the functionality", значит, это функциональный тест.

Возвращаясь к TDD, его особенность — тестирование каждого нового куска методом предварительного построения теста, доказывающего неработу пустого места;) при этом никак не ограничивается размер этого куска. Специально взял ту же википедию:

first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards.

"New function" является вполне допустимым объёмом добавления. И в чём противоречие с unit testing? Идём ниже, в той же странице:

Test-driven development requires developers to create automated unit tests that define code requirements (immediately) before writing the code itself.

Тут уже чётко написано про "unit" tests. А не "functional".

В общем, пожелание: если уж ссылаешься на источник, постарайся хоть ему не противоречить:) иначе нелепо выглядишь. И брать для этого источники, которые хотя бы внутренне согласованы, а не как википедия.

AVK>Тестирование на живых процессах, когда запускается приложение целиком, это интеграционное тестирование.

Это для тебя есть понятие "приложение целиком". У меня application (приложение) — это всего лишь компонента рабочей среды исполнения, характерная тем, что имеет логические действия запуска и останова (а также, впадая в детали, у неё может быть failover и takeover между местами исполнения, причём на разных средствах, и с передачей состояния или без передачи). А интеграционное тестирование — это уже для комплекса из нескольких приложений.

AVK> Функциональное точно так же тестирует в основном отдельные модули. Разница с unit в том, что последнее тестирует все аспекты контракта, а функциональное проверяет работоспособность модуля на предполагаемых юзкейсах. Т.е. unit-тестирование проверяет соответствие контракта спецификации, а функциональное — соответствие функционала входному ТЗ.

В вашей фирме так понимают эти термины? Охотно верю.

N>>Функциональные тесты являются основным проверяемым фактором для QA — наш QA про юнит-тесты ничего не знает, это дело программистов и меня как начальника группы программистов.

AVK>Это вопрос организационный, к разделению на юнит и функциональное это никакого отношения не имеет. Функциональные тесты очень часто пишутся именно программистами.

Пишутся — да. А проверяются — уже по-разному. QA у нас юнит-тестирование не запускает.

N>>Некорректный логический переход. ТЗ на функцию, да, описывает её функционал, но понятие функциональных тестов подразумевает проверку логически завершённого модуля
AVK>Ничего подобного оно не подразумевает. См. определение.

Которое из противоречащих? ;)

N>>Википедия, BTW, далеко не единственный источник.
AVK>О да, знакомо. Если что то не стыкуется — виновата википедия.
AVK>Не, она, конечно, далеко не единственный и даже не самый авторитетный источник, но если выбирать между ней и твоими голословными заявлениями, то я предпочту первое.

У тебя результат не менее голословный получился — на самопротиворечивом источнике.

N>> В описании этих методик я больше опирался на статьи с хабра
AVK>О! Зашибись источник. Все с вами ясно.
N>>, чем на википедию, и считаю это в данном случае более разумным.
AVK>Считай.

Спасибо за разрешение, но я в нём не нуждался.

Здравствуйте, netch80, Вы писали:

N>Например, в русской

Я русскую почти никогда и не читаю. И цитаты приводил из английской. Но вообще, переход спора на обсуждение качества википедии уже о многом говорит.

AVK>>С того, что "test case that defines a desired improvement or new function" это функциональный тест. По определению:
AVK>>

AVK>>Functional testing refers to activities that verify a specific action or function of the code. These are usually found in the code requirements documentation, although some development methodologies work from use cases or user stories. Functional tests tend to answer the question of "can the user do this" or "does this particular feature work."

N>Такое твоё понимание бессмысленно

Это не мое понимание, это цитата из википедии. Ну да я помню, она у тебя рожей не вышла.

N>А ответ тут в том, что ты в своём художественном квотинге по тексту этой статьи "упустил" то, что там функциональное тестирование противопоставляется тестированию других характеристик, таких, как нагрузочная способность или защищённость. А в этом случае нет никакого противоречия между functional и unit testing

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

N>Возвращаясь к TDD, его особенность — тестирование каждого нового куска методом предварительного построения теста

Его особенность — это не тестирование куска, пусть и предварительное. Его особенность — предварительная формализация ТЗ путем написания тестов. И дальнейшее описание дизайна — тоже при помощи тестов. Да, прижелании TDD можно использовать вплоть до уровня классов, и тогда функциональные тесты на этом уровне вполне прокатят и за юнит (хотя будут, по меркам юнит-тестирования, сильно неполными). Ну так и что?

AVK>>Тестирование на живых процессах, когда запускается приложение целиком, это интеграционное тестирование.
N>Это для тебя есть понятие "приложение целиком". У меня application (приложение) — это всего лишь компонента рабочей среды исполнения, характерная тем, что имеет логические действия запуска и останова (а также, впадая в детали, у неё может быть failover и takeover между местами исполнения, причём на разных средствах, и с передачей состояния или без передачи). А интеграционное тестирование — это уже для комплекса из нескольких приложений.

Куча слов, а мысли я уловить не смог.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, netch80, Вы писали:
N>>Например, в русской
AVK>Я русскую почти никогда и не читаю. И цитаты приводил из английской. Но вообще, переход спора на обсуждение качества википедии уже о многом говорит.

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

AVK>>>С того, что "test case that defines a desired improvement or new function" это функциональный тест. По определению:
AVK>>>

AVK>>>Functional testing refers to activities that verify a specific action or function of the code. These are usually found in the code requirements documentation, although some development methodologies work from use cases or user stories. Functional tests tend to answer the question of "can the user do this" or "does this particular feature work."

N>>Такое твоё понимание бессмысленно
AVK>Это не мое понимание, это цитата из википедии. Ну да я помню, она у тебя рожей не вышла.

Не статья "рожей не вышла", а твоя её "интерпретация" с устранением принципиальной мысли данного раздела статьи и подменой тезиса. Сразу за процитированным тобой абзацем идёт текст:

Non-functional testing refers to aspects of the software that may not be related to a specific function or user action, such as scalability or other performance, behavior under certain constraints, or security. Non-functional requirements tend to be those that reflect the quality of the product, particularly in the context of the suitability perspective of its users.

Отсюда чётко ясно, что в процитированном тобой нет никакого противопоставления одних видов функционального тестирования другим, но есть противопоставление другим видам, как нагрузочное.
А так как unit testing, согласно тому же источнику, проверяет, то ли делает функция, то это тоже функциональное.

N>>А ответ тут в том, что ты в своём художественном квотинге по тексту этой статьи "упустил" то, что там функциональное тестирование противопоставляется тестированию других характеристик, таких, как нагрузочная способность или защищённость. А в этом случае нет никакого противоречия между functional
и unit testing

AVK>А кто говорил про противоречия? Да, часть функциональных тестов вполне может прокатить и под юнит. Разница в подходе. При функциональном тестировании мы, фактически, формализуем юзкейсы в виде набора тестов. А при юнит — фиксируем спецификации конкретных модулей в конкретном дизайне.

Тогда покажи мне, как по википедии (ты ведь этот источник мне показываешь в качестве своей основной опоры?) в юнит-тестах ты _фиксируешь_ _спецификации_. И как пример кода из статьи Unit testing со строками вида

assert(adder.add(2, 2) == 4);

может "фиксировать спецификацию". Покажи, а я посмотрю:)

Нельзя подходить к источникам по типу "здесь читаю, а здесь рыбу заворачиваю". Если ты мне предъявляешь википедию как надёжный источник — соглашайся с ней во всём, а не выборочно. Или признай, что она тоже не более чем подсказка, но тогда я получу полное право использовать и другие источники, и часто как более авторитетные.

N>>Возвращаясь к TDD, его особенность — тестирование каждого нового куска методом предварительного построения теста
AVK>Его особенность — это не тестирование куска, пусть и предварительное. Его особенность — предварительная формализация ТЗ путем написания тестов.

В том и дело, что это однобокое рассмотрение TDD. Можно формализовать ТЗ и больше ничего не делать (тесты не пускать, а код пусть живёт своей жизнью). Кроме собственно формализации ТЗ, TDD выполняет ещё две роли: проверку соответствия этому ТЗ для автора кода и проверку того же для его начальства. Если тесты пишутся вслед, крайне велик соблазн их просто не делать или сделать когда будет время после гонки за функционалом (а этого времени таки не будет). Предварительное написание тестов является жёстким методом гарантировать проверку хотя бы этих тестов соответствия ТЗ. Да, для этого необходимым условием является предварительная формализация ТЗ, о чём ты собственно и пишешь. Но по сути этот метод — не технический, а административный: он даёт какую-то гарантию менеджменту, что код реально есть, потому что не протестированный код — его как бы и нет. И первый недостаток его — опять же в административной плоскости: нет реального критерия, что именно проверять.

AVK>>>Тестирование на живых процессах, когда запускается приложение целиком, это интеграционное тестирование.
N>>Это для тебя есть понятие "приложение целиком". У меня application (приложение) — это всего лишь компонента рабочей среды исполнения, характерная тем, что имеет логические действия запуска и останова (а также, впадая в детали, у неё может быть failover и takeover между местами исполнения, причём на разных средствах, и с передачей состояния или без передачи). А интеграционное тестирование — это уже для комплекса из нескольких приложений.

AVK>Куча слов, а мысли я уловить не смог.

Тогда начни с одной простой фразы: приложение — это не то, что тебе кажется. :)

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, gandjustas, Вы писали:

G>>>>Именно, но ведь не любой код одинаково подвержен изменениям? Или ты вообще не можешь сказать насколько подвержена изменениям тот или иной модуль?
N>>>Заранее — нет. Требования постоянно уточняются и изменяются. Предсказать необходимое даже на год может быть достаточно тяжело, на большее время — практически невозможно. С каждой новой установкой мы получаем какие-то новые требования, под которые надо адаптироваться.
G>>Так не бывает. В такой ситуации просто невозможно что-то спланировать. Если же рассмотреть рельный случай. Делается 3d игра, для нее пишется движок, она станет 2d? Нет. Алгоритм пересечения луча с плоскостью изменится? Тоже нет.

N>Алгоритм — нет. А вот оптимальная реализация — да, может сильно измениться в зависимости от специфики запросов и обстановки.
Точно, поэтому и нужны unit-тесты чтобы проверить что новый и старый алгоритм эквивалентны

N>Насчёт "невозможно что-то спланировать" ты сильно неправ. Возможно. Но планировать надо иначе — умея уточнять обстановку и адаптироваться под неё на ходу. Такое себе agile, только на следующем вверх уровне. И таки да, быть готовым морально и практически к тому, что что-то придётся отменять ещё не доделанное, с сожалением, и переходить к другому.
А ты не в кусре что agile не работает\плохо работает на fixed cost? тебя много не fixed cost проектов было?

N>В быстро развивающемся софте, как у нас, может устаревать 20-30% кода в год. И это не самый суровый темп.
Точно и остается 70%-80% кода в год, часть из которого не меняется на протяжении многих лет. Вернее меняется код, не меняются контракты.

Ты только что показал существование такого, который редко меняется в плане контрактов и для которого имеет смысл писать тесты.

N>>>Ошибка в слове "доказать". Никакими тестами ты не можешь это _доказать_, можешь лишь обещать какую-то вероятность или меру корректности. Она может быть и 99.999%, но не 100%.
G>>Почему это? Если покрываются все варианты использования, то чем это не доказательство?
N>Что ты называешь вариантами использования?

Это значит все возможные наборы параметров для которых имеются разные пути исполнения.


G>>Whitebox тестирование может покрыть все варианты использования.

N>Сунул строку "whitebox тестирование" в яндекс. Получил рассказ о том, как наши космические корабли бороздят просторы Большого театра инструменты вроде PEX берут функцию и находят характерные входные данные для проверки. Ты это имел в виду? Или таки вариант проверить все возможные значения множества входных данных? В последнем случае, сколько триллионов лет потребуется тебе для завершения тестирования, например, функции подсчёта длины utf-8 строки, в кодовых пунктах?
Не надо проверять все параметры. надо написать по одному тесту для каждого варианта использования. Их всегда конечное количество так как путей исполнения кода конечное количество. Как будешь вычислять эти самые варианты — твое дело, хоть автоматически с помощью pex, хоть анализируя код — без разницы. Вообще идеальный вариант — заранее продумывать как будет работать тот или иной метод класса и писать тесты. В любом случае вариантов использование будет очень ограниченное количество.

После того как написаны тесты с использованием whitebox методики можно к ним относиться как к backbox. То есть мы "забываем" что тесты проверяют какие-то варианты и нам главное чтобы они выполнялись. Потом мы можем изменять реализацию. оптимизировать как нам вздумается.



N>>>Тем не менее тесты нужны, потому что практически они действуют достаточно хорошо.
G>>Конкретизируй понятие "хорошо" что ли.
N>Я не пытаюсь совершить невозможное.
Во фразе выше есть слово "хорошо", что ты под ним понимаешь?

G>>>>Я привел доводы когда можно использовать unit-тесты. Доводы соответствуют опыту. Не согласны — никто же не заставляет вас использовать unit-тест.
G>>>>Своих же доводов вы не приводите. Это отчасти и подталкивает к мысли что вы не видите ценности тестов.
N>>>Повторюсь, что я их постоянно привожу. Только особенности Вашего восприятия не позволяют это увидеть.
G>>Ага, вроде "тесты это хорошо".

N>И что в этом неправильного? Да, это общее руководство. Да, я мог бы сказать, что для наших условий юнит-тест для нетривиальной функции экономит усилия в 10-20-100 раз (в зависимости от местности) по сравнению с выявлением проблемы уже на функциональном тесте приложения и поиском точки проблемы доступными средствами (только логами, поскольку никакой отладчик наши задачи не вытянет), а комплект функциональных тестов хотя бы на базовые сценарии работы приложения экономит ну просто дофига хотя бы на том, что установленная клиенту система в основном работает, а не падает. Но какое другим дело до нашей весьма тяжёлой специфики? У них своя есть, не менее странная.
Ну вот, уже конкретика пошла, это уже лучше чем просто "хорошо".
Вообще я заметил склонность многих программистов считать свои проекты\задачи пипец какими уникальными, а по сути сколько не смотрел проекты похожи один на другой даже из разных областей. И ошибки в них одинаковые.

Здравствуйте, Aikin, Вы писали:

AVK>>>> А толку от них никакого, так как они пачками становятся просто неактуальными на новом дизайне.
A>>>Мы все еще про юнит-тесты говорим? Тогда о каких пачках идет речь?
AVK>>Об обычных. Глубокий рефакторинг ломает конктракты — ломаются все связанные с этим тесты.
A>Любой рефакторинг идет итеративно, небольшими шажками. Тесты отваливаются постепенно. В конце каждой итерации зеленыее тесты поддтверждат корректность текущего шага.
A>Я вообще не представляю как можно делать рефакторинг в стиле "все похерим, а потом разберемся".
A>При "очень глубоком рефакторинге" классы вместе с тестами проще выкинуть, чем изменять.

A>И вообще, как часто системе необходим "глубоком рефакторинг" (и что это за зверь-то?)

В сильно запущеном коде рефакторить нужно вообще постоянно, по 50 файлов например изменить что бы кнопку перенести с одной формы на другую