Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, _hum_, Вы писали:
L>>>Например, что если пользователь просил латте, то они получает латте, а не флэт вайт, и что латте — это именно латте, а не каппучино? __>>проверитьь, что "поведение в принципе соответствует ожидаемому" никак нельзя:
L>Это относится только к black-box тестированию. Юнит-тесты — это white-box тестирование.
нет, это относится ко всему тестированию — см. статью по ссылке
Re[36]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
E>Я привёл тебе несколько разных задач, где юнит-тесты, в частности, и ТДД, в целом, экономически не целесообразны. E>Ты не про одну так и не показал, что целесообразны...
Видишь ли, чтобы хоть что-то "показать", нужно поставить рядом два проекта — один с TDD, второй без. И сравнить.
Иначе это все разговоры в пользу бедных.
Мой 10+ опыт внедрения TDD там, где он был "экономически нецелесообразен" подсказывает мне, что если бы означенное предприятие использовало TDD, то вполне может быть, что у них уже летал бы C-5432 и стоил он бы в 10 раз дешевле.
E>В целом я думаю, что уже добился того, чего хотел
ты доказал, что привыкшие копать лопатой не умеют использовать экскаватор.
Re[37]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>В моей книге "523 оправдания, почему мы не пишем автотесты" этот вывод вместе с преамбулой войдет в предисловие.
Что такое автотесты в данном случае?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[31]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, _hum_, Вы писали:
L>>>Начнем с главного — тесты прогоняют production код в контролируемых условиях. В принципе, на этом можно было бы и закончить. __>>очень общее высказывание. я не понял
L>Хмм.. по мне так оно весьма конкретное. Означает — юнит тесты подают на вход тестируемого юнита некие данные и сравнивают отклик с ожидаемым.
а, ну вот теперь более конкретно.
L>Погоди, что запустили? Вот вы начинаете работу над совершенно новым проектом. Твоя задача — реализовать.... ну драйвер сканера (courtesy of Erop). Вот ты пишешь первый класс, уж не знаю, какой. Что ты запускаешь? Ничего запускаемого еще нет и 10 месяцев не будет. Как ты проверишь?
да спокойно. возьму и отдельно повызываю его методы на прогонных значениях (ведь прогон же не считается юнит-тестом?)
__>>не понял что нельзя написать assert(nullptr != data); ?
L>Нет, во многих случаях писать его там бессмысленно.
L>>>Чтобы верифицировать поведение do_smth, код ассерта должен полностью реализовывать алгоритм, который он верифицирует.
__>>ну, то есть, опять же, отличие в невозможности ассерта протестировать именно функциональность (работу функции при всевозможных различных аргументах)? так?
L>Как минимум, для начала.
ок. спасибо.
Re[33]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, _hum_, Вы писали:
L>>>При всем уважении, такое работает, только когда что-то очень и очень простое пишут. __>>так в сложных случаях есть брейк-поинты, когда вместо того, чтобы анализировать весь поток управления, выделяют отдельные его фрагменты, подпадающие под подозрение (с помощью тех же ассертов)
L>Это тоже крайне простые случаи.
а какие сложные? (если не брать во внимание многопроцессные проги)?
L>Но использование отладчика делает их сложными само по себе.
почему?
Re[39]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>До внедрения.
Десятки миллионов инсталляций... Просто, с какого-то момента я ушёл на другой проект, а изделие по сию пору живо и развивается.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[36]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, _hum_, Вы писали:
L>>Это относится только к black-box тестированию. Юнит-тесты — это white-box тестирование. __>нет, это относится ко всему тестированию — см. статью по ссылке
По-твоему получается, что из статьи следует, что все, что я делал последние 10+ лет, сделать было невозможно? Забавно.
Re[32]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, _hum_, Вы писали:
__>так в сложных случаях есть брейк-поинты, когда вместо того, чтобы анализировать весь поток управления, выделяют отдельные его фрагменты, подпадающие под подозрение (с помощью тех же ассертов)
Таки если мы ещё про вычматы, и если откуда-то известно "как надо", то момент расхождения с "как надо" лучше искать заточенным под это тестом, а не отладчиком...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[39]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, _hum_, Вы писали:
E>>Я про то и говорю, что не все задачи хорошо покрываются юнит-тестами и ТДД...
__>ну просто вы это очень завуалированного делаете
Несколько раз писал прямым текстом...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[31]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, _hum_, Вы писали:
__>>вы о чем? E>Мы о сохранении инвариантов... E>Проверяется assert's или юнит-тестами...
они только покажут, что есть проблема. а в чем именно она — нет, если ошибка несодержательная (как неправильны знак в приращении аргумента поиска) .
E>>>А дебагер как поможет?
__>>как обычно — пошагово проходите по потоку управления, сравнивая состояния "как должно быть" с "как есть". в том месте, где происходит расхождение — ошибка.
E>А как узнать, "как должно быть"? E>На коленке сосчитать? E>А если задача многомерная?
берете простой пример (наппример, одномерный) и вперед
с тестами будет то же самое — все размерности и комбинации не обсчитать
Re[40]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, _hum_, Вы писали:
E>>>Я про то и говорю, что не все задачи хорошо покрываются юнит-тестами и ТДД...
__>>ну просто вы это очень завуалированного делаете
E>Несколько раз писал прямым текстом...
да, н без аргументов наподробие "даже если в системе все элементы в отдельности протестированы, это не означает, что система будет работать как надо"
Re[31]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>Хмм.. по мне так оно весьма конкретное. Означает — юнит тесты подают на вход тестируемого юнита некие данные и сравнивают отклик с ожидаемым.
Так любые тесты делают, не только юнит...
L>Они их в первую очередь и проверяют.
Бывает ещё и функциональное тестирование и регрессивное и т. д...
L>>>Они позволяют верифицировать код сразу после его написания, не откладывая это на месяцы, когда система, частью которой они являются, начнет хотя бы запускаться.
__>>ассерты тоже — запустили сразу и они повылетали (я так всегда делаю )
L>Погоди, что запустили? Вот вы начинаете работу над совершенно новым проектом. Твоя задача — реализовать.... ну драйвер сканера (courtesy of Erop). Вот ты пишешь первый класс, уж не знаю, какой. Что ты запускаешь? Ничего запускаемого еще нет и 10 месяцев не будет. Как ты проверишь?
Ну, например, часто пишут прототип, который можно запускать, а потом в нём реализуют подсистемы...
Ну и вообще, пусть мы UI пишем, например. Пишем, запускаем, смотрим...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[37]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, _hum_, Вы писали:
L>>>Это относится только к black-box тестированию. Юнит-тесты — это white-box тестирование. __>>нет, это относится ко всему тестированию — см. статью по ссылке
L>По-твоему получается, что из статьи следует, что все, что я делал последние 10+ лет, сделать было невозможно? Забавно.
нет, это означает, что то, что вы делали за последние десять лет, на самом деле не "проверить, что поведение в принципе соответствует ожидаемому", а "establish that it[system function] does not function properly under specific conditions"
Re[33]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, _hum_, Вы писали:
__>>так в сложных случаях есть брейк-поинты, когда вместо того, чтобы анализировать весь поток управления, выделяют отдельные его фрагменты, подпадающие под подозрение (с помощью тех же ассертов)
E>Таки если мы ещё про вычматы, и если откуда-то известно "как надо", то момент расхождения с "как надо" лучше искать заточенным под это тестом, а не отладчиком...
ну как вы плюс вместо минуса тестом обнаружите в x_{n+1} = x_{n} — f(x_n)/f'(x_n) ?
Re[37]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>Мой 10+ опыт внедрения TDD там, где он был "экономически нецелесообразен" подсказывает мне, что если бы означенное предприятие использовало TDD, то вполне может быть, что у них уже летал бы C-5432 и стоил он бы в 10 раз дешевле.
Вроде и сейчас мировой лидер и по цене и по ТТХ...
E>>В целом я думаю, что уже добился того, чего хотел
L>ты доказал, что привыкшие копать лопатой не умеют использовать экскаватор.
Экскаватор не всем подходит. Археологам, например...
Тем не менее, ты, со своим 10+ опытом внедрения дал оценку формализации требований к ловцу писем террористов в "тысячи учёных работающих за большие деньги" или как-то так примерно. Я с ней согласен.
А тестовые базы писем с разметкой, где террористы, а где нет, стоят НАМНОГО дешевле и работают ЛУЧШЕ...
Тока это совсем другой подход, чем ТДД, так как если ты по этим базам будешь ТДД делать, то переобучишься на них и всё...
А юнит-тесты "кирпичиков" полезны, конечно, но если это малая часть задачи, то они не критичны...
Регрессивные тесты по границам подсистем полезны тоже и т. д...
Задача тестирования сложного трудноформализуемого поведения сложна сама по себе, и тут важно выбрать верный компромисс...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[34]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, _hum_, Вы писали:
__>а какие сложные? (если не брать во внимание многопроцессные проги)?
Расчёт обтекания крыла самолёта на адаптивных сетках...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[32]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, _hum_, Вы писали:
__>берете простой пример (наппример, одномерный) и вперед
Что такое "одномерная гидродинамика", например?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[41]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, _hum_, Вы писали:
__>да, н без аргументов наподробие "даже если в системе все элементы в отдельности протестированы, это не означает, что система будет работать как надо"
Конечно не значит, особенно, если система data-driven...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[34]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, _hum_, Вы писали:
__>ну как вы плюс вместо минуса тестом обнаружите в x_{n+1} = x_{n} — f(x_n)/f'(x_n) ?
Увидишь рсхождение, проанализируешь код и найдёшь ошибку...
А отладчик тут чем поможет?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[42]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, _hum_, Вы писали:
__>>да, н без аргументов наподробие "даже если в системе все элементы в отдельности протестированы, это не означает, что система будет работать как надо"
E>Конечно не значит, особенно, если система data-driven...
токо не "конечно", ибо это не совсем тривиальный факт (даже отдельное название имеет — эмерджентность системы)
