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

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

Ты всерьёз думаешь, что это мои _проблемы_? Я так не думаю, он мне нафиг не нужен кроме как для этой дискуссии:)

G> pex работает только для .NET,

Значит, в морг.

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

Значит, ответа не будет. Ясно.

G>>>На gated checkins тесты запускается и код не коммитится если они надают.
N>>"О наблюдении за наблюдающими за наблюдателями" ((c)): кто гарантирует, что набор тестов адекватен?
G>Ты гарантируешь, когда пишешь тест. Иначе никак.

Quod erat demonstrandum.

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

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

Это из википедии. Если ты пользуешься другим источником определений — пожалуйста, но определи его заранее, чтобы не было разногласий только из-за этого.
G>Это черезмерное упрощение, примерно как ООП — данные+методы (см соседнюю тему).

Видимо, есть какое-то тайное знание, которое мне знать не положено — рылом не вышел. OK.