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

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

N>>>>>Против этого я и не возражал. Вопрос в том, насколько они unit.
G>>>>А что им мешает быть unit-тестами?
N>>>Зависит от глубины переделки. Может оказаться, что неизменна и покрыто неизменившимися тестами только самая внешняя функциональность, которая не может быть сведена к простому "выстрелил вызовом функции — получил ответ — проверил", а требует долгой подготовки среды. Для меня это всё-таки не unit тест. Unit — это когда максимум подготовки среды это расстановка заглушек вместо рабочего кода. Да, это деление не академично, но мне оно полезнее.

G>>Вполне правильное деление. Вот только непонятно зачем переделка? Если не писались unit-тесты для кода, то скорее всего не будут написаны, а если будут то от этого будет много затрат без наблюдаемого эффекта.

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

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

Проще переписать кусок, предварительно написав для него тесты.


N>>>>>>>Что ты называешь вариантами использования?
G>>>>>>Это значит все возможные наборы параметров для которых имеются разные пути исполнения.
N>>>>>Для меня такое тестирование имеет очень мало смысла, только для отдельных специфических вариантов функций. Полный набор путей исполнения, мягко говоря, бесконечен. Можно было бы только в целях тестирования выделить отдельные логические подблоки типа "продвинуться на шаг алгоритма", выделяя их в функции, но часто это слишком неудобно.
G>>>>Вообще-то конечен.
N>>>Ну числа типа 2**2**32 всё равно за пределами представления даже в BER, поэтому я позволил себе "округлить" их до бесконечности.
G>>По факту их гораздо меньше.

N>Уверен? Только на своих примерах?
На любых. Есть хорошая утилита pex, которая как раз показывает такие пути. Запускал её давно на коде, который писался без тестов. Метод на 200 строк (метрика, исходников почти 1000 строк) — около 15 путей. То есть для полного покрытия надо не более 15 тестов.
Даже если взять 30 тестов на 1000 строк исходников, то это не дофига. А если применять TDD, то будет еще меньше.

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

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

Связь сама прямая. Рефакторинг — изменение (улучшение) кода, без изменения наблюдаемого поведения. Как гарантировать неизменность наблюдаемого поведения?

N>>>Я периодически использовал этот подход — тесты до кода — как стимулятор собственной работы против собственной же лени, то есть проблема была чисто организационная. Но я никогда не предполагал его как средство собственно дизайна. На это годится тестируемость в принципе, а не test-first.
G>>Когда напишешь тест то на него уже не получается просто забить, особенно когда gated checkins включено.

N>У нас нет никаких gated checkins. Но даже если бы были, это означало бы опять же, что введено административное требование соблюдать какие-то оформительские требования, не более того, и цена ему, как любому подобному административному требованию — высокая, если оно разумно обусловлено ситуацией, и ломаный грош в противном случае.
На gated checkins тесты запускается и код не коммитится если они надают.

G>> Если ты не пишешь заранее тесты, то рано или поздно у тебя получится забивание на тесты ради скорости написания, а потом тесты сделать, даже с мощными инструментами, очень сложно. Это ты кстати назвал "адаптацией".

N>Всё это замечательно, но ещё проще и удобнее делать это же без жёсткого test-first
TDD не предполагает test-first всегда.