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

N>>>>Твои примеры с бухгалтерией, физическим или графическим движком мне кажутся неадекватными. В них есть много тонкостей, которые могут на второй уже версии сильно меняться. Например, следующий DirectX, или требование пересчёта баланса впараллель на нескольких ядрах вместо текущего одного ядра могут переломать всю архитектуру слоя поддержки.
G>>>И? Одна тонкость не ставит под сомнение существование самих движков.
N>>Она подтверждает AVK: "стабильность участков кода обычно определяется уже после их написания".
G>Что ты понимаешь под стабильностью? Я говорил про части кода, на которые не влияют или мало влияют изменения требований для приложения. Граф. движок очень хорошо подходит.

А я объяснил, как на самом деле они могут повлиять принципиально, хотя кажется, что не могут.:)

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

Заранее — нет. Требования постоянно уточняются и изменяются. Предсказать необходимое даже на год может быть достаточно тяжело, на большее время — практически невозможно. С каждой новой установкой мы получаем какие-то новые требования, под которые надо адаптироваться.

N>>>>Поэтому разумно просто отвести ресурсы на написание тестов, не конкретизируя, какие именно они должны быть. Где-то это юнит-тесты до каждой строчки кода, где-то — функциональный на группу классов. Осталось, чтобы руководитель согласился с критериями разумности.
G>>>Если рассматривать тесты только как пожиратель ресурсов, то их вообще писать не стоит.
N>>Вывод про "только" высосан из пальца.
G>Ты про другое не пишешь.

Это как и чем, извините, надо читать, чтобы сделать такой вывод? Я постоянно прямым текстом говорю обратное.

G>>> Я например прекрасно вижу преимущества unit-тестов в виде формально проверяемых спецификаций, а также как регрессионное тестирование.
N>>Регрессионное — да. Формально проверяемая спецификация — нет. Для этого нужна верификация, а не тестирование.
G>Если язык позволяет статически верифицировать то да, а иначе только тестами. Других способов доказать что код соотвествует спецификации просто нет.

Ошибка в слове "доказать". Никакими тестами ты не можешь это _доказать_, можешь лишь обещать какую-то вероятность или меру корректности. Она может быть и 99.999%, но не 100%. Доказательство даёт только верификация.
Тем не менее тесты нужны, потому что практически они действуют достаточно хорошо.

G>Я привел доводы когда можно использовать unit-тесты. Доводы соответствуют опыту. Не согласны — никто же не заставляет вас использовать unit-тест.
G>Своих же доводов вы не приводите. Это отчасти и подталкивает к мысли что вы не видите ценности тестов.

Повторюсь, что я их постоянно привожу. Только особенности Вашего восприятия не позволяют это увидеть.
А "доводы, когда можно использовать unit-test" мне не нужны. Я их и сам напишу толпами.
Мне были бы полезны доводы, когда их реально _нужно_ использовать. Пока что с этим плохо, в основном есть две позиции — "они нахер не нужны" и "покрывайте тестами всё".

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

N>>>>Твои примеры с бухгалтерией, физическим или графическим движком мне кажутся неадекватными. В них есть много тонкостей, которые могут на второй уже версии сильно меняться. Например, следующий DirectX, или требование пересчёта баланса впараллель на нескольких ядрах вместо текущего одного ядра могут переломать всю архитектуру слоя поддержки.
G>>>И? Одна тонкость не ставит под сомнение существование самих движков.
N>>Она подтверждает AVK: "стабильность участков кода обычно определяется уже после их написания".
G>Что ты понимаешь под стабильностью? Я говорил про части кода, на которые не влияют или мало влияют изменения требований для приложения. Граф. движок очень хорошо подходит.

А я объяснил, как на самом деле они могут повлиять принципиально, хотя кажется, что не могут.:)

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

Заранее — нет. Требования постоянно уточняются и изменяются. Предсказать необходимое даже на год может быть достаточно тяжело, на большее время — практически невозможно. С каждой новой установкой мы получаем какие-то новые требования, под которые надо адаптироваться.

N>>>>Поэтому разумно просто отвести ресурсы на написание тестов, не конкретизируя, какие именно они должны быть. Где-то это юнит-тесты до каждой строчки кода, где-то — функциональный на группу классов. Осталось, чтобы руководитель согласился с критериями разумности.
G>>>Если рассматривать тесты только как пожиратель ресурсов, то их вообще писать не стоит.
N>>Вывод про "только" высосан из пальца.
G>Ты про другое не пишешь.

Это как и чем, извините, надо читать, чтобы сделать такой вывод? Я постоянно прямым текстом говорю обратное.

G>>> Я например прекрасно вижу преимущества unit-тестов в виде формально проверяемых спецификаций, а также как регрессионное тестирование.
N>>Регрессионное — да. Формально проверяемая спецификация — нет. Для этого нужна верификация, а не тестирование.
G>Если язык позволяет статически верифицировать то да, а иначе только тестами. Других способов доказать что код соотвествует спецификации просто нет.

Ошибка в слове "доказать". Никакими тестами ты не можешь это _доказать_, можешь лишь обещать какую-то вероятность или меру корректности. Она может быть и 99.999%, но не 100%. Доказательство даёт только верификация (в пределах применённой модели, которая сама может быть некорректной).
Тем не менее тесты нужны, потому что практически они действуют достаточно хорошо.

G>Я привел доводы когда можно использовать unit-тесты. Доводы соответствуют опыту. Не согласны — никто же не заставляет вас использовать unit-тест.
G>Своих же доводов вы не приводите. Это отчасти и подталкивает к мысли что вы не видите ценности тестов.

Повторюсь, что я их постоянно привожу. Только особенности Вашего восприятия не позволяют это увидеть.
А "доводы, когда можно использовать unit-test" мне не нужны. Я их и сам напишу толпами.
Мне были бы полезны доводы, когда их реально _нужно_ использовать. Пока что с этим плохо, в основном есть две позиции — "они нахер не нужны" и "покрывайте тестами всё".