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

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

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

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

вы о чем?

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

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

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

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

При всем уважении, такое работает, только когда что-то очень и очень простое пишут.

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

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

Почему?

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

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

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

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

L>Начнем с главного — тесты прогоняют production код в контролируемых условиях. В принципе, на этом можно было бы и закончить.

очень общее высказывание. я не понял

L>Они верифицируют поведение кода на соответствие ожидаемому.

ударение на "поведение"? то есть, тесты могут еще и функциональные свойства проверять?

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

ассерты тоже — запустили сразу и они повылетали (я так всегда делаю )

L>Они позволяют протетстировать поведение кода в условиях, трудно достижимых или вообще недостижимых при тестировании системы (QA).

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

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

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

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


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

L>

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

L>Чтобы верифицировать поведение do_smth, код ассерта должен полностью реализовывать алгоритм, который он верифицирует.

ну, то есть, опять же, отличие в невозможности ассерта протестировать именно функциональность (работу функции при всевозможных различных аргументах)? так?

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

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

Ага, формализация ловца писем террористов уже требует "над которой работают тысячи людей и ученых и за решение которой людям платят очень и очень неплохие деньги"?
Так я утверждаю ТОЖЕ САМЕ! В этой задаче ТДД экономически не выгодна!

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

L>И почему ты не применил к ней глагол в совершенной форме?
Ты спрашиваешь, написал ли я её? Да, до какой-то степени покрытия всех существующих сканеров...

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

__>нет, не так. я НЕ ЗНАЛ, что скорость роста времени компиляции от роста проекта такая нелинейная, потому это и вызывало во мне соответствующие вопросы — в первую очередь, как же тогда большие проекты разрабатываются.

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

__>в моем понимании тоже. обратите внимание, вы НИГДЕ не указали, что программист должен знать особенности компиляции. всюду участвуют только особенности языка и исполнителя (машины). промежуточное звено, ака компилятор, вынесен вами за скобки.

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

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

Чем глубже вы понимаете то, как работает связка железо / ОС / компилятор / прикладной софт — тем проще вам будет понять, как сделать хорошую программу. Имея лишь поверхностные знания языка и боязнь сделать шаг в сторону вы ничего не добьётесь, кроме очередного топика на +100500 сообщений на форуме.

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

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

SaZ>>Например, в серьёзном геймдеве (да и не только) нечего ловить, если вы не знаете, что такое thiscall / fastcall / stdcall и т.п, если не понимаете, зачем нужен и когда нужен inline. Если не знаете, что такое кэш-мисс или конвеер команд в процессоре. Вроде бы это всё и не нужно, чтобы писать код на С++, но специалист тем и отличается от кодера-любителя, что понимает, как работает система.

__>это тоже все относится к языку и исполнителю алгоритма, но никак не к компилятору.

Относить можно куда угодно. Главное — результат. Программист — думает и программирует, кодер — кодит, фиксит баги и ноет, что "компилятор/язык говно".

	Хз откуда
	Пацаны, я тут короче сидел за монитором и попытался скомпилить какую-то шнягу из буста, не помню какую, но внезапно компилятор сказал мне "интернал еррор" много раз. И тут я вдруг задумался — какое же говно c++! [ апплодисменты в зале ] Представляете, пацаны, он дает мне stdio и iostream, и я должен выбирать. А как я выберу, это же так сложно, прямо глаза разбегаются! А вдруг я использую и первое, и второе? Совсем беспредел же получится, пацаны, видите какой говно-язык? [ зал продолжает рукоплескать ] А стандартная библиотека? Она же просто ужасна! Там даже строки кривые — не спрашивайте почему, я не знаю^W^W^Wэто же очевидно! И знаете, скажу вам по секрету, я открыл ее исходник... Да, исходник самой stl! Вот вы когда-то смотрели туда? Вижу по глазам, что не смотрели. А я вот посмотрел, и ничего там не понял!!! [ Бурное проявление недовольства в зале, апплодисменты, крики "Страуструпа на мыло!" ] Вот смотрите сюда, пацаны. Я нашел кусок кода, в котором используются макросы с шаблонами, конструкторы бросают исключения, написана куча велосипедных аллокаторов, память течет как из ведра. Я читал его и ужасался, на каком же говно-языке все вокруг пишут! [ Одинокий голос из зала "а может ты сам написал этот код?", раздается несколько ударов, несогласного выносят ] И инкапсуляция у них нарушается всегда!!! В только представьте, пацаны — они спят и видят, как бы ее нарушить! Просыпаются, и сразу же бегут ее нарушать; засыпают, мечтая о том, как пойдут нарушать ее завтра! [ Дамы в зале утираются платочками, всхлипывая; мужчины сидят с каменными лицами, сцепив зубы ] И вообще, самое страшное — этот подлый язык заставляет меня думать! Думать над освобождением памяти, думать над нормальной иерархией классов, думать над всем!!! Так дальше продолжаться не может — пора закопать его! За-ко-пать!!! Такое говно не должно оскорблять своим существованием наш священный мирок! Кто со мной?! [ Все, сидящие в зале, вскакивают, словно распрямившаяся пружина, и выбегают в дверь следом за лидером. Кажется, старому язычку пришел пиздец. Армия скрывается в тумане, некоторое время оттуда слышатся крики "Батт-хёрт! Батт-хёрт! Батт-хёрт!", под которые марширует этот карательный отряд, потом и они затихают вдали ] Из потайной дверцы в опустевший зал входит Александреску, вертя в руках блокнот. "2015 год, реактивное говно-нашествие школоты номер 9681", записывает он туда; выходит из зала, запирая дверь на ключ. На крыльце его поджидает Страуструп, они заходят в соседний паб, заказывают по кружке темного пива, и с улыбкой смотрят на экран на стене. На том экране виден гигантский небоскреб с двумя крестами на крыше, вокруг которого бегают мелкие на его фоне людишки, стуча кулаками в стены. Но стены почему-то не пробиваются; атакующие разбивают костяшки в кровь, и обиженно отходят, дуя на окровавленные пальцы. Вместо них к стенам пробиваются новые фанатики, но их становится все меньше; волна постепенно угасает. "больше двадцати лет прошло, и все повторяется", — со вздохом говорит Бьёрн, потягивая пиво. К небоскребу достраивают еще один этаж, новый подземный паркинг. Отбитые пальцы горе-разрушителей почти зажили. "Пацаны...", — начинает свою проповедь очередной мессия

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

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

Мы пошли на второй круг. Есть задачи, где юнит-тесты покрывают только процентов 10 разработки.

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

Ну, обычно, есть способы запускать код в контролируемых условиях, но это вовсе и не обязательно юнит-тесты...

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

L>>Если нежелание бесплатно решать сложную задачу, над которой работают тысячи людей и ученых и за решение которой людям платят очень и очень неплохие деньги теперь принято называть "слился", то да, слился.
E>Ага, формализация ловца писем террористов уже требует "над которой работают тысячи людей и ученых и за решение которой людям платят очень и очень неплохие деньги"?
E>Так я утверждаю ТОЖЕ САМЕ! В этой задаче ТДД экономически не выгодна!

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

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

L>>И почему ты не применил к ней глагол в совершенной форме?
E>Ты спрашиваешь, написал ли я её? Да, до какой-то степени покрытия всех существующих сканеров...

До внедрения.

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

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

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

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

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

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

проверитьь, что "поведение в принципе соответствует ожидаемому" никак нельзя:

/wiki/Software_testing#Hierarchy_of_testing_difficulty
A primary purpose of testing is to detect software failures so that defects may be discovered and corrected. Testing cannot establish that a product functions properly under all conditions but can only establish that it does not function properly under specific conditions

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

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

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

L>При всем уважении, такое работает, только когда что-то очень и очень простое пишут.

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

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

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

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

ну просто вы это очень завуалированного делаете

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

L>>Начнем с главного — тесты прогоняют production код в контролируемых условиях. В принципе, на этом можно было бы и закончить.
__>очень общее высказывание. я не понял

Хмм.. по мне так оно весьма конкретное. Означает — юнит тесты подают на вход тестируемого юнита некие данные и сравнивают отклик с ожидаемым.

L>>Они верифицируют поведение кода на соответствие ожидаемому.

__>ударение на "поведение"? то есть, тесты могут еще и функциональные свойства проверять?

Они их в первую очередь и проверяют.

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

__>ассерты тоже — запустили сразу и они повылетали (я так всегда делаю )

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

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

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

L>>Чтобы верифицировать поведение do_smth, код ассерта должен полностью реализовывать алгоритм, который он верифицирует.

__>ну, то есть, опять же, отличие в невозможности ассерта протестировать именно функциональность (работу функции при всевозможных различных аргументах)? так?

Как минимум, для начала.

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

L>>Например, что если пользователь просил латте, то они получает латте, а не флэт вайт, и что латте — это именно латте, а не каппучино?
__>проверитьь, что "поведение в принципе соответствует ожидаемому" никак нельзя:

Это относится только к black-box тестированию. Юнит-тесты — это white-box тестирование.

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

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

Это тоже крайне простые случаи.

Но использование отладчика делает их сложными само по себе.

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

L>Да, не страшно. Всего лишь — "изделие" тю-тю вместе с половиной тестового полигона. Ведь симулятор делать ДОРАХА!
Изделие одноразовое в любом случае. Есть такое понятие, как огневой стенд. Он не тю-тю даже при взрыве и нештатной работе.
Это такой "железный" юнит-тест

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

L>

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

Если проц меняют, то ясно, что тайминги надо перенастроить. Например прогнать по телеметрии от старой ракеты, но на новом проце.
Потом на наивной модели, потом на стенде...

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

Какой, нафиг, RTC на тех процах?

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

L>Ээ, а проверка противодействию "мер противника", прости, где?
В мишени.
Тестовый Фреймворк, на самом деле есть, тока он "железный"

L>Поэтому лучше вообще ничего не делать?
Поэтому, после предварительных прогонов лучше шмальнуть

L>Ага. И она говорит, что все было зашибись, зашибись, зашибись, ой все.
Ну это у тех, кто прогать не умеет
По факту С-?00 таки летают же

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

L>Если их не поленились сделать.
Это дорого, долго, и не понятно зачем нужно. Ты смотришь на задачу слишком узко просто.
L>Я не понимаю, чего ты хочешь добиться?
В смысле?
Я привёл тебе несколько разных задач, где юнит-тесты, в частности, и ТДД, в целом, экономически не целесообразны.
Ты не про одну так и не показал, что целесообразны...

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

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

__>вы о чем?
Мы о сохранении инвариантов...
Проверяется assert's или юнит-тестами...

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

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

А как узнать, "как должно быть"?
На коленке сосчитать?
А если задача многомерная?

ай, SaZ, вы в своем репертуаре приписали мне то, что я не говорил, за это обвинили в дилетантсве, и с чувством выполненного долга шли