Здравствуйте, netch80, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
G>>>>Именно, но ведь не любой код одинаково подвержен изменениям? Или ты вообще не можешь сказать насколько подвержена изменениям тот или иной модуль?
N>>>Заранее — нет. Требования постоянно уточняются и изменяются. Предсказать необходимое даже на год может быть достаточно тяжело, на большее время — практически невозможно. С каждой новой установкой мы получаем какие-то новые требования, под которые надо адаптироваться.
G>>Так не бывает. В такой ситуации просто невозможно что-то спланировать. Если же рассмотреть рельный случай. Делается 3d игра, для нее пишется движок, она станет 2d? Нет. Алгоритм пересечения луча с плоскостью изменится? Тоже нет.
N>Алгоритм — нет. А вот оптимальная реализация — да, может сильно измениться в зависимости от специфики запросов и обстановки.
Точно, поэтому и нужны unit-тесты чтобы проверить что новый и старый алгоритм эквивалентны
N>Насчёт "невозможно что-то спланировать" ты сильно неправ. Возможно. Но планировать надо иначе — умея уточнять обстановку и адаптироваться под неё на ходу. Такое себе agile, только на следующем вверх уровне. И таки да, быть готовым морально и практически к тому, что что-то придётся отменять ещё не доделанное, с сожалением, и переходить к другому.
А ты не в кусре что agile не работает\плохо работает на fixed cost? тебя много не fixed cost проектов было?
N>В быстро развивающемся софте, как у нас, может устаревать 20-30% кода в год. И это не самый суровый темп.
Точно и остается 70%-80% кода в год, часть из которого не меняется на протяжении многих лет. Вернее меняется код, не меняются контракты.
Ты только что показал существование такого, который редко меняется в плане контрактов и для которого имеет смысл писать тесты.
N>>>Ошибка в слове "доказать". Никакими тестами ты не можешь это _доказать_, можешь лишь обещать какую-то вероятность или меру корректности. Она может быть и 99.999%, но не 100%.
G>>Почему это? Если покрываются все варианты использования, то чем это не доказательство?
N>Что ты называешь вариантами использования?
Это значит все возможные наборы параметров для которых имеются разные пути исполнения.
G>>Whitebox тестирование может покрыть все варианты использования.
N>Сунул строку "whitebox тестирование" в яндекс. Получил рассказ о том, как наши космические корабли бороздят просторы Большого театра инструменты вроде PEX берут функцию и находят характерные входные данные для проверки. Ты это имел в виду? Или таки вариант проверить все возможные значения множества входных данных? В последнем случае, сколько триллионов лет потребуется тебе для завершения тестирования, например, функции подсчёта длины utf-8 строки, в кодовых пунктах?
Не надо проверять все параметры. надо написать по одному тесту для каждого варианта использования. Их всегда конечное количество так как путей исполнения кода конечное количество. Как будешь вычислять эти самые варианты — твое дело, хоть автоматически с помощью pex, хоть анализируя код — без разницы. Вообще идеальный вариант — заранее продумывать как будет работать тот или иной метод класса и писать тесты. В любом случае вариантов использование будет очень ограниченное количество.
После того как написаны тесты с использованием whitebox методики можно к ним относиться как к backbox. То есть мы "забываем" что тесты проверяют какие-то варианты и нам главное чтобы они выполнялись. Потом мы можем изменять реализацию. оптимизировать как нам вздумается.
N>>>Тем не менее тесты нужны, потому что практически они действуют достаточно хорошо.
G>>Конкретизируй понятие "хорошо" что ли.
N>Я не пытаюсь совершить невозможное.
Во фразе выше есть слово "хорошо", что ты под ним понимаешь?
G>>>>Я привел доводы когда можно использовать unit-тесты. Доводы соответствуют опыту. Не согласны — никто же не заставляет вас использовать unit-тест.
G>>>>Своих же доводов вы не приводите. Это отчасти и подталкивает к мысли что вы не видите ценности тестов.
N>>>Повторюсь, что я их постоянно привожу. Только особенности Вашего восприятия не позволяют это увидеть.
G>>Ага, вроде "тесты это хорошо".
N>И что в этом неправильного? Да, это общее руководство. Да, я мог бы сказать, что для наших условий юнит-тест для нетривиальной функции экономит усилия в 10-20-100 раз (в зависимости от местности) по сравнению с выявлением проблемы уже на функциональном тесте приложения и поиском точки проблемы доступными средствами (только логами, поскольку никакой отладчик наши задачи не вытянет), а комплект функциональных тестов хотя бы на базовые сценарии работы приложения экономит ну просто дофига хотя бы на том, что установленная клиенту система в основном работает, а не падает. Но какое другим дело до нашей весьма тяжёлой специфики? У них своя есть, не менее странная.
Ну вот, уже конкретика пошла, это уже лучше чем просто "хорошо".
Вообще я заметил склонность многих программистов считать свои проекты\задачи пипец какими уникальными, а по сути сколько не смотрел проекты похожи один на другой даже из разных областей. И ошибки в них одинаковые.
