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

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


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


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

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.

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

Это черезмерное упрощение, примерно как ООП — данные+методы (см соседнюю тему).