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

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

Гм. Кто-то тут преимущества статических языков вспоминал:) почему-то:)

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

У тебя есть PEX? Мне его поставить некуда, Win7 даже в кошмарах не снится. Напусти его, например, на библиотечный qsort(). mbslen(), если он сам реализован, а не через виндовый рантайм. Больше вариантов пока не вижу, потому что юниксовых функций у вас нет;) И тогда посмотрим, насколько он ценен:) Мне искренне интересно — если там что-то ценное, можно будет применить или хотя бы найти аналог.

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

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

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

"О наблюдении за наблюдающими за наблюдателями" ((c)): кто гарантирует, что набор тестов адекватен?

G>>> Если ты не пишешь заранее тесты, то рано или поздно у тебя получится забивание на тесты ради скорости написания, а потом тесты сделать, даже с мощными инструментами, очень сложно. Это ты кстати назвал "адаптацией".
N>>Всё это замечательно, но ещё проще и удобнее делать это же без жёсткого test-first :)
G>TDD не предполагает test-first всегда.

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

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