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

L>Из таких мастхевов почти любой программный продукт обычно состоит чуть менее, чем полностью.

Ну вот про это я тебе и говорю, что есть задачи, которые на 99% сводятся к качеству запчастей и узлов, и там ТДД рулит. А есть задачи со сложным, плохо формализуемым поведением, и там ТДД можно тока к Фреймворку применить, а основная разработка так не взлетит...

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

L>Фотошоп управляет одним унифицированным драйвером. Извини, младенцев обижать врослым людям не пристало.

Да вот и не фига. Почти все драйверы детектят фотошоп и учитывают его *особенности*.
Но если ты не фотошоп, а другая программа, то тебе как быть?

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

E>>Так скока типов датчиков? Сканеров тысяч 5 есть, если не больше...

L>Фотошоп управляет одним унифицированным драйвером. Извини, младенцев обижать врослым людям не пристало.

И ты скромно умолчал о числе типов датчиков... Больше 100?

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

E>>>Про пред/пост-условия что-то слышал?
L>>Мы, кажется, на разных языках говорим. Юнит-тесты делают намного больше, нежели ты можешь добиться от самых хитрых ассертов.

__>landerhigh,а можно в двух словах объяснить, чем все-таки тесты принципиально отличаются от "навороченных ассертов"? (не беря во внимание TDD, ибо это уже совсем из другой оперы)

Начнем с главного — тесты прогоняют production код в контролируемых условиях. В принципе, на этом можно было бы и закончить.
Они верифицируют поведение кода на соответствие ожидаемому.
Они позволяют верифицировать код сразу после его написания, не откладывая это на месяцы, когда система, частью которой они являются, начнет хотя бы запускаться.
Они позволяют протетстировать поведение кода в условиях, трудно достижимых или вообще недостижимых при тестировании системы (QA).

Хрестоматийный же

void do_smth(some_ptr* data)
{
    assert(data);
    ///
}

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

или же с пост-условием

some_type do_smth(const some_data& data)
{
    // a lot of calculations
    assert(result != 0)
    assert(result < some_arbitrary_value)
}

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

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

L>Да. Даже если этот симулятор на 100% наивен и не отражает и 5% реального положения дел, он полностью себя оправладет, когда поможет выяснить, что скорости реакции алгоритма на данные от датчиков не хватает. Или показать, что в некоторых условиях алгоритм выдает слишком грубые команды, что приведет к дестабилизации и разрушению. Или что интервал ожидания фидбека слишком короткий. Дофига всяких забавностей можно выяснить на основе наивных симуляторов. И это всегда дешевле, нежели потом ковыряться ножичком в обугленных останках изделия.

Это ранний этап отладки и настройки. Обычно он уже в целом на прошлой модификации сделан
А вся разработка крутится над внедрением мер противодействия тем или иным фокусам, которые внедрил противник...

L>К примеру, промышленный симулятор Боинга не умеет симулировать поведение самолета в случае отказа всех двигателей. Но почему-то пилотов не перестают на нем тренировать.

И таки симулятор стоил денег... Не факт, что отстрел нужного числа изделий дороже...

E>>Вопрос цены/точности эмуляции...
L>Найти ошибку с помощью самого наколенного симулятора всегда дешевле.

Часто просто невозможно. И концепция "найти ошибку" слишком примитивная. Чаще стоит задача "найти, как улучшить"...
Конечно прикидочные прогоны можно на эмуляторе, но тонкие настройки не сойдутся...

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

L>>Фотошоп управляет одним унифицированным драйвером. Извини, младенцев обижать врослым людям не пристало.
E>И ты скромно умолчал о числе типов датчиков... Больше 100?

Прежде чем я отвечу на твой вопрос, сначала скажи мне, драйвера для какого количества сканеров ты лично написал?

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

L>А пока такое невозможно, извини. Сегодня юзеру нравится свиной хрящик, а завтра он вообще другую религию принял.

Ok, убедил, iMac, iPhone и прочие макинтоши не были разработаны, так как это невозможно...

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

E>>Давай возьмём задачу сделать прототип ловца писем терроритстов на лазаньи на глубоких нейросетях?

L>Давай. Приводи инвестора.

Я верно понимаю, что ты слился?

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

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

Проверка интегралов движения...

А дебагер как поможет?

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

L>Прежде чем я отвечу на твой вопрос, сначала скажи мне, драйвера для какого количества сканеров ты лично написал?

Я лично как-то писал такую сканирующую программу...

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

E>Это ранний этап отладки и настройки. Обычно он уже в целом на прошлой модификации сделан

А в этой модификации поменяли процессор с таймингами и изделие взорвалось еще до запуска.

E>А вся разработка крутится над внедрением мер противодействия тем или иным фокусам, которые внедрил противник...

Делаем симулятор для этих "мер".

L>>К примеру, промышленный симулятор Боинга не умеет симулировать поведение самолета в случае отказа всех двигателей. Но почему-то пилотов не перестают на нем тренировать.
E>И таки симулятор стоил денег... Не факт, что отстрел нужного числа изделий дороже...

Факт. Проверка поведения в контролируемых условиях всегда дешевле и эффективнее просеивания пепла через сито в надежде выяснить, что же в этот "отстрел" пошло "не так". Не говоря уже о том, что на симуляторе можно "отстрелять" в таких условиях, которые в реале никто не даст повторять.

L>>Найти ошибку с помощью самого наколенного симулятора всегда дешевле.

E>Часто просто невозможно.

Выгоняем тех, кому "невозможно", нанимаем тех, кому "возможно".

E>И концепция "найти ошибку" слишком примитивная. Чаще стоит задача "найти, как улучшить"...

И тут как раз симуляции и эмулаторы незаменимы.

E>Конечно прикидочные прогоны можно на эмуляторе, но тонкие настройки не сойдутся...

Если задача состоит в эмуляци тонких настроек, то можно найти способ именно их и эмулировать. Конечно, не на 100%, но приемлимого приближения добиться вполне можно.

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

L>>А пока такое невозможно, извини. Сегодня юзеру нравится свиной хрящик, а завтра он вообще другую религию принял.
E>Ok, убедил, iMac, iPhone и прочие макинтоши не были разработаны, так как это невозможно...

Это эпично!

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

L>>Давай. Приводи инвестора.
E>Я верно понимаю, что ты слился?

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

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

L>>Прежде чем я отвечу на твой вопрос, сначала скажи мне, драйвера для какого количества сканеров ты лично написал?
E>Я лично как-то писал такую сканирующую программу...

И почему ты не применил к ней глагол в совершенной форме?

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

L>А в этой модификации поменяли процессор с таймингами и изделие взорвалось еще до запуска.
Это
1) не страшно
2) И без тестирования понятно

L>Делаем симулятор для этих "мер".
Точный сделать дорого. Как там точно в тех или иных режимах железо отрабатывает тоже же не известно. Допиливают и ПО и железку же, в комплексе.
Так что отстрел на стендах и по мишеням адекватнее...
То, что можно эмулировать, например прогон по логу телеметрии, конечно эмулируют, но точная эмуляция — очень сложная задача сама по себе.

L>Факт. Проверка поведения в контролируемых условиях всегда дешевле и эффективнее просеивания пепла через сито в надежде выяснить, что же в этот "отстрел" пошло "не так". Не говоря уже о том, что на симуляторе можно "отстрелять" в таких условиях, которые в реале никто не даст повторять.

Обычно телеметрия таки есть...

L>Выгоняем тех, кому "невозможно", нанимаем тех, кому "возможно".
Ну, значит ты разгонишь "Алмаз-Антей" и наберёшь тех, кто сделают С-600 с нуля

L>И тут как раз симуляции и эмулаторы незаменимы.
Если доступны...
E>>Конечно прикидочные прогоны можно на эмуляторе, но тонкие настройки не сойдутся...

L>Если задача состоит в эмуляци тонких настроек, то можно найти способ именно их и эмулировать. Конечно, не на 100%, но приемлимого приближения добиться вполне можно.

Зуб даёшь или чем докажешь?

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

E>>>Ты правда не можешь понять, что надо написать, пока не написал тесты?
L>>Нет, я обоснованно считаю написание кода без тестов напрасной работой.
E>1) Понятие "тесты" оч. широкое. Мы всё ещё о юнит-тестах или о любом способе запустить разрабатываемый код?

Не очень важно. Главное, чтобы тест мог верифицировать поведение отдельных юнитов в контроллируемых условиях. Из-за комбинаторного взрыва такое по сути под силу только юнит-тестам.

L>>Мы, кажется, на разных языках говорим. Юнит-тесты делают намного больше, нежели ты можешь добиться от самых хитрых ассертов.
E>Тем не менее, примерно ту же задачу — фиксацию пред/пост условий и контроль стабильности, они таки решают...

И попутно решают еще кое-какую задачу, которую ты скромно (или стыдливо?) "забыл" упомянуть, которую ассертами решить невозможно.

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

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

L>>А пока такое невозможно, извини. Сегодня юзеру нравится свиной хрящик, а завтра он вообще другую религию принял.

E>Ok, убедил, iMac, iPhone и прочие макинтоши не были разработаны, так как это невозможно...

по-моему, у вас тут спор на пустом месте. красивость тоже можно формализовать (есть же гайдлайны по gui) теми же параметрами эргономичности. но какое отношение это имеет к юнит-тестированию? больше похоже на спор об общем понятии тестирования системы (которое намного обширнее, чем юнит-тестирование):

Testing levels

There are generally four recognized levels of tests: unit testing, integration testing, component interface testing, and system testing.

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

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

__>>>>кстати, "дебаггинг" не только работа под дебагером, но и просто поиск ошибок в коде.
L>>>Если же вести "просто поиск", то зачем тогда ждать компиляции?

__>>потому что их надо исправить и проверить, что после исправления все заработало, как надо

L>И как же это "проверить" осуществляется?

перестало выводить свойства системы за рамки, допускаемые пользователем

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

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

L>>А в этой модификации поменяли процессор с таймингами и изделие взорвалось еще до запуска.
E>Это
E>1) не страшно

Да, не страшно. Всего лишь — "изделие" тю-тю вместе с половиной тестового полигона. Ведь симулятор делать ДОРАХА!

E>2) И без тестирования понятно

Обычно он уже в целом на прошлой модификации сделан

Да щас. Никто и не знал, что для таймингов в критичном к времени алгоритме, который верифицировали "на прошлой модификации", использовались тики процессора, а не RTC, как это должно было быть.

L>>Делаем симулятор для этих "мер".
E>Точный сделать дорого. Как там точно в тех или иных режимах железо отрабатывает тоже же не известно. Допиливают и ПО и железку же, в комплексе.

Тогда можно вообще ничего не делать, раз дорого.

E>Так что отстрел на стендах и по мишеням адекватнее...

Ээ, а проверка противодействию "мер противника", прости, где?

E>То, что можно эмулировать, например прогон по логу телеметрии, конечно эмулируют, но точная эмуляция — очень сложная задача сама по себе.

Поэтому лучше вообще ничего не делать?

L>>Факт. Проверка поведения в контролируемых условиях всегда дешевле и эффективнее просеивания пепла через сито в надежде выяснить, что же в этот "отстрел" пошло "не так". Не говоря уже о том, что на симуляторе можно "отстрелять" в таких условиях, которые в реале никто не даст повторять.
E>Обычно телеметрия таки есть...

Ага. И она говорит, что все было зашибись, зашибись, зашибись, ой все.

L>>Выгоняем тех, кому "невозможно", нанимаем тех, кому "возможно".
E>Ну, значит ты разгонишь "Алмаз-Антей" и наберёшь тех, кто сделают С-600 с нуля

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

L>>И тут как раз симуляции и эмулаторы незаменимы.
E>Если доступны...

Если их не поленились сделать.

L>>Если задача состоит в эмуляци тонких настроек, то можно найти способ именно их и эмулировать. Конечно, не на 100%, но приемлимого приближения добиться вполне можно.

E>Зуб даёшь или чем докажешь?

Я не понимаю, чего ты хочешь добиться?

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

__>>>потому что их надо исправить и проверить, что после исправления все заработало, как надо
L>>И как же это "проверить" осуществляется?
__>перестало выводить свойства системы за рамки, допускаемые пользователем

А как насчет того, чтобы проверить, что поведение в принципе соответствует ожидаемому?
Например, что если пользователь просил латте, то они получает латте, а не флэт вайт, и что латте — это именно латте, а не каппучино?