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

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

Против этого я и не возражал.:) Вопрос в том, насколько они unit.

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

Я в курсе. Но я предполагаю, что если заказчик меняет требования посреди реализации, то он должен за это заплатить.
На второй вопрос — я вообще не помню у себя fixed cost проектов за последние лет 15. Все — долгоживущие, рассчитанные на продолжение жизни софтины до тех пор, пока в ней есть хоть какой-то смысл, или прототипы, которые не вышли дальше этого этапа.
В случае жёсткого fixed cost я бы, конечно, любые предложения чего-то подправить сначала бы встречал правым нижним в бубен, а затем начинал бы слушать, что заказчик хочет. (Утрирую, конечно;))

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

Категорически согласен. Так вот, и продолжая эту мысль: у нас есть некоторый ресурсный фонд на поддержание своего продукта, а не только на новое (если на поддержание дают 0%, надо немедленно увольняться). В момент введения новой функциональности она протестирована едва-едва, только в самых ключевых точках и на уровне самой верхней целевой функциональности, но как только она выжила — часть этого фонда поддержания должна пойти на усиление тестами того, что уже выжило. Ещё выжило — ещё усилить. И так далее.

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

Для меня такое тестирование имеет очень мало смысла, только для отдельных специфических вариантов функций. Полный набор путей исполнения, мягко говоря, бесконечен. Можно было бы только в целях тестирования выделить отдельные логические подблоки типа "продвинуться на шаг алгоритма", выделяя их в функции, но часто это слишком неудобно.

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

Под такое ещё надо адаптировать код. Далеко не всегда возможно, хотя, надо заметить, может быть полезно. Для того же примера с подсчётом длины строки, например, разделить код на функцию сдвига на один пункт и код подсчёта пунктов может быть полезно для ловли, например, ситуации, если промежуточная длина хранится в 8 битах (злобный пример того, как можно не заметить фигню на коротких тестах). Но это уже придётся mock'и делать.

А без адаптации, по крайней мере для моей обстановки, никак не получается "очень ограниченное количество" ситуаций. Поэтому для меня whitebox testing имеет совсем другой смысл (см. предыдущие письма).

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

Ты путаешь совершенно разные вещи. Ошибки часто одинаковые, это да. Специфика не уникальна, но она колоссально разная. Я не могу найти сейчас человека здесь на форуме, который заметен и который занимается хотя бы примерно теми же задачами, что я. Если есть, то они не светятся. В то же время я знаю, что в мире ещё около 5 групп идёт схожими путями. Но они не здесь. Поэтому я действительно склонен считать, что в пределах RSDN мои задачи уникальны и специфика их — тоже. Возражать разрешаю только на собственных примерах;)