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

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

__>>а какие сложные? (если не брать во внимание многопроцессные проги)?

E>Расчёт обтекания крыла самолёта на адаптивных сетках...

и в чем сложность-то? взяли сетку 2x2, и прошлись, посмотрели

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

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

__>>ну как вы плюс вместо минуса тестом обнаружите в x_{n+1} = x_{n} — f(x_n)/f'(x_n) ?

E>Увидишь рсхождение, проанализируешь код и найдёшь ошибку...
E>А отладчик тут чем поможет?

можете привести пример анализа для случая с методом ньютона? ну, наподобие:
итак, я вижу, что он у меня дает ерунду, значит, нужно искать в коде <то-то и то-то>

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

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

__>>берете простой пример (наппример, одномерный) и вперед

E>Что такое "одномерная гидродинамика", например?

ламинарное течение по трубе

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

__>и в чем сложность-то? взяли сетку 2x2, и прошлись, посмотрели

Не получится.

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

__>можете привести пример анализа для случая с методом ньютона? ну, наподобие:
__>итак, я вижу, что он у меня дает ерунду, значит, нужно искать в коде <то-то и то-то>

Ну пишешь лог: i, x, f(x), f'(x), dx
смотришь, где что не так пошло (например на первом же шаге производная и f(x) верные, а dx не туда), смотришь в код, где dx вычисляют...

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

__>ламинарное течение по трубе

И чего там считать? Особенно на адаптивных сетках?

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

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

__>>можете привести пример анализа для случая с методом ньютона? ну, наподобие:
__>>итак, я вижу, что он у меня дает ерунду, значит, нужно искать в коде <то-то и то-то>

E>Ну пишешь лог: i, x, f(x), f'(x), dx
E>смотришь, где что не так пошло (например на первом же шаге производная и f(x) верные, а dx не туда), смотришь в код, где dx вычисляют...

вооот!!!! у вас повилось понятие "шаг" и "лог", а это есть ни что иное, как шаг дебагера и состояние процесса (watched variables)

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

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

__>>ламинарное течение по трубе

E>И чего там считать? Особенно на адаптивных сетках?

содержательно — нечего. но мы же проверяем ошибки проги.
можете потом на двумерном случае проверить (если ошибки кроются в многоммерности сетки) и т.д.

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

L>>По-твоему получается, что из статьи следует, что все, что я делал последние 10+ лет, сделать было невозможно? Забавно.

__>нет, это означает, что то, что вы делали за последние десять лет, на самом деле не "проверить, что поведение в принципе соответствует ожидаемому", а "establish that it[system function] does not function properly under specific conditions"

Testing cannot establish that a product functions properly under all conditions but can only establish that it does not function properly under specific conditions.

Иными словами, это означает, что в случае ЧЯ тестирования тот факт, что система правильно функционирует в условиях, в которых ее тестеры не поленились прогнать, вовсе не гарантирует, что система будет правильно функционировать вообще во всех условиях. С этим никто не спорит. Все возможные условия просто не проверить (комбинаторный взрыв, однако).

Но вот тут и приходит понимание того, в чем вся мощь юнит-тестирования.

При правильном подходе к организации кода и покрытию сценариев его использования прогаммист может протестировать все сценарии использования юнита. Абсолютно все. Обычно. Как правило. Чем опытнее TDD-программист, тем сильнее его "обычно" стремится к "всегда". Иногда это не так, иногда это и правда дорого (привет, Erop), иногда просто лень, иногда тупо непонятно, что нужно делать в случае определенных входных данных, которых никогда быть не должно.
Что это означает? Что система, состоящая из оттестированных юнитов, в тестировании не нуждается? You wish! Это означает нечто другое, а именно то, что система уже прошла раннюю верификацию. Тестерам не нужно искать сломанное сетевое устройство, чтобы проверить поведение системы в случае общения с устройством, которое портит сообщения, так как логика этого поведения уже проверена.
Им вообще остается проверять сборку на соответствие спецификациям, по большому счету.

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

L>>Хмм.. по мне так оно весьма конкретное. Означает — юнит тесты подают на вход тестируемого юнита некие данные и сравнивают отклик с ожидаемым.
__>а, ну вот теперь более конкретно.
L>>Погоди, что запустили? Вот вы начинаете работу над совершенно новым проектом. Твоя задача — реализовать.... ну драйвер сканера (courtesy of Erop). Вот ты пишешь первый класс, уж не знаю, какой. Что ты запускаешь? Ничего запускаемого еще нет и 10 месяцев не будет. Как ты проверишь?
__>да спокойно. возьму и отдельно повызываю его методы на прогонных значениях (ведь прогон же не считается юнит-тестом?)

Таак, уже теплее. Вот это "возьму отдельно и повызываю методы" ты как делаешь? Вот новый проект, ничего запускаемого еще нет. Какие действия?

__>>>не понял что нельзя написать assert(nullptr != data); ?

L>>Нет, во многих случаях писать его там бессмысленно.

Потому что это либо означает, что нужна полноценная проверка в рантайме, либо архитектура плохо продумана, либо ассерт просто воткнут туда "на всякий случай", потому что "так принято".

L>>>>Чтобы верифицировать поведение do_smth, код ассерта должен полностью реализовывать алгоритм, который он верифицирует.
__>>>ну, то есть, опять же, отличие в невозможности ассерта протестировать именно функциональность (работу функции при всевозможных различных аргументах)? так?
L>>Как минимум, для начала.

__>ок. спасибо.

Это, на самом деле, отличие, которое и отличает каменный век от века полетов в космос

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

L>>Мой 10+ опыт внедрения TDD там, где он был "экономически нецелесообразен" подсказывает мне, что если бы означенное предприятие использовало TDD, то вполне может быть, что у них уже летал бы C-5432 и стоил он бы в 10 раз дешевле.
E>Вроде и сейчас мировой лидер и по цене и по ТТХ...

В отсутствие конкурентов быть лидером — невелика хитрость

E>>>В целом я думаю, что уже добился того, чего хотел

L>>ты доказал, что привыкшие копать лопатой не умеют использовать экскаватор.
E>Экскаватор не всем подходит. Археологам, например...

Во многих случаях археологам не было бы работы, если бы до них там не поработал экскаватор.

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

L>>В моей книге "523 оправдания, почему мы не пишем автотесты" этот вывод вместе с преамбулой войдет в предисловие.
E>Что такое автотесты в данном случае?

Автоматически выполняемые при каждой сборке

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

E>Десятки миллионов инсталляций... Просто, с какого-то момента я ушёл на другой проект, а изделие по сию пору живо и развивается.

Не, ну десятками миллионов инсталляций я лично пока похвастаться не могу. Нет в нашей области такого количества клиентов. Все датацентры всяких там Амазонов и прочих Блумбергов окучили и клиенты кончились.

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

__>>>так в сложных случаях есть брейк-поинты, когда вместо того, чтобы анализировать весь поток управления, выделяют отдельные его фрагменты, подпадающие под подозрение (с помощью тех же ассертов)
L>>Это тоже крайне простые случаи.
__>а какие сложные? (если не брать во внимание многопроцессные проги)?

Многопоточные, наверное? Они, родимые.
Да даже и в однопоточной факт наблюдения чертовщины в отладчике вовсе не гарантирует, что она вызвана именно на этом месте в call stack.

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

L>>а оставлять отладочные ассерты в релизе — это уже :maniac
E>Почему?

примерно по всему

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

E>Не могут, так как хорошие алгоритмы движения барабана — один из аспектов "хорошести" машины...

Ты перепутал хорошесть машины и хорошесть маркетинга.

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

__>вооот!!!! у вас повилось понятие "шаг" и "лог", а это есть ни что иное, как шаг дебагера и состояние процесса (watched variables)

Логи удобнее.

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

L>В отсутствие конкурентов быть лидером — невелика хитрость
Это в каком смысле "в отсутствии конкурентов"?

L>Во многих случаях археологам не было бы работы, если бы до них там не поработал экскаватор.
Перешёл к доказательствам по аналогии?

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

L>Автоматически выполняемые при каждой сборке

Это я за, если выч. мощи хватает

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

L>>>а оставлять отладочные ассерты в релизе — это уже :maniac
E>>Почему?

L>примерно по всему

Конкретнее...