Re[29]: Долгая компиляция на с++ - смерть для больших проект - C/C++

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

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

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

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

Так что именно будет понятно из теста-то? Что ничего не работает? Что дальше делать?

L>И, что характерно, написание такого теста (один раз, к слову сказать), займет меньше времени, чем просто запустить программу под отладчиком. Один раз. И, что будет оценено намного позже, этот тест будет там тогда, когда о нем уже забудут и какой-то джуниор в попытке "улучшить" алгоритм его сломает. И этот тест тут же даст ему по рукам.

Я совершенно не пытаюсь сказать, что тесты не нужны.

Здравствуйте, _hum_, Вы писали:
__>просто для меня тест — это просто предусловие и постусловие, позволяющее контролировать целостность кода при его изменениях.
__>как это может помочь автоматически избегать ошибок в процесс написания программы, ума не приложу.
я начинаю напоминать сам себе какого-то просветителя, который приехал на остров дикарей и стал знакомить их со Словом Божием.

дело это вообще неблагодарное

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

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

__>Разработчики языка вообще в эту сторону смотрят?

Смотрят, конечно, но модули в с++17 все-таки не попали.
Команды разработчиков иногда используют Incredibuild или distcc.

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

T>Не понимаю, как вообще можно сравнивать тесты и отладчик.

Я вот не понимаю, зачем при разработке новой функциональности вообще может потребоваться отладчик.

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

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

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

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

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

Вот хорошая иллюстрация использования TDD на практике: https://habrahabr.ru/post/231657/ , у меня перелом в понимании TDD (и в отношении к нему) случился после этой статьи.) Там просто на пальцах показано, как в стиле tdd пишется достаточно сложный код с нуля. Да, накидать все это без тестов получилось бы быстрее, но на отладку потом ушла бы куча времени, а здесь отладки нет совсем.)

Это стандартная ситуация с TDD: обычно проект пишется, скажем, за месяц, а потом он в состоянии "готов на 99%" отлаживается еще 3-4 месяца, с TDD — проект пишется 2 месяца вместо одного, тестов получается больше чем самого кода, многие их них кажутся бессмысленными, но вот этот период отладки отсутствует совсем.) Это надо просто попробовать самому на каком-то своем проекте, чтобы прочувствовать.)

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

T>>Еще, с чего бы стоило начать, посмотреть на что время тратиться при сборке.
__>а есть какие-нибудь бесплатные анализаторы? а то у меня в vs2013 не показывает, на что время тратится — просто comiling xxxxx.cpp и три минуты, потом следующий, а по каким она там модулям лазит и на чем стопорится — непонятно.
Tools\Options\Projects and Solutions\Buld and Run\MSBuild project build * verbocity выстави в нужное положение и анализируй.

Ну и плюс время компиляции хорошо снижается через precompiled headers(для Release можно отключить чтобы все по честному было), и Multi-processor compilation(включается в настройках проекта).

А, ну еще как вариант перейти на 2015 студию
https://blogs.msdn.microsoft.com/vcblog/2015/11/11/new-improved-and-faster-database-engine/
https://blogs.msdn.microsoft.com/vcblog/2015/10/16/debugfastlink-for-vs2015-update-1/
https://blogs.msdn.microsoft.com/visualstudio/2015/11/30/improving-your-build-times-with-incredibuild-and-visual-studio-2015/

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

__>У меня он пока средний — около 2 Mb в архиве, и уже сейчас время перекомпиляции — около 20 минут
Как правильно делать написали уже много, а я напишу как сделать быстро.
1) Создаем и добавлем в проект 2 файла

precompiled.h

#pragma once

#ifdef _WIN32
#pragma warning( push )
#pragma warning( disable: 4127 4616 4512 4251 )
#endif
#include <QtCore/QtCore>
#include <QtGui/QtGui>
#include <QtWidgets/QtWidgets>
#include <QtNetwork/QNetworkAccessManager>
#include <QtNetwork/QNetworkReply>
#include <QtNetwork/QNetworkProxy>
#ifdef _WIN32
#pragma warning( pop )
#endif

	precompiled.cpp
	`#pragma warning( push ) #pragma warning( disable: 4503 4244 4189 4100 4512 ) #include "precompiled.h" #pragma warning( pop )`

2) Открываем свойства precompiled.cpp идем в Configuration Properties\C/C++\Precompiled Headers\Precompiled Header выставляем Create
3) Открываем свойства проекта идем в Configuration Properties\C/C++\Precompiled Headers\Precompiled Header выставляем Use, Precompiled Header File прописываем $(ProjectDir)precompiled.h
4) Открываем свойства проекта идем в Configuration Properties\C/C++\Advanced\Force Include File прописываем $(ProjectDir)precompiled.h

Вроде всё, сделать так лучше только для Debug версии, а в релизе переодически проверять что не забыл включить нужные заголовки.
И выставь еще Configuration Properties\C/C++\General\Multi-processor Compilation Yes

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

W>Тут первичная проблема в header-only библиотеках. Если шаблонная магия находится не в заголовочном файле, который включается в пол-программы, а внутри соответствующего cpp, то ничего страшного не происходит.

Мой подход такой:
хедеры для header-only компонента А делятся на три категории:
1. a_fwd.h — Чистый forward declaration: только пространства имен, имена классов и функций в них. Подключаются там, где нужно просто имя типа/функции (например, переменная-указатель на тип).
2. a.h — "нормальный хедер": пространства имен, определения классов, но для тяжелых функций (тяжелых как в смысле кода, так и в смысле зависимостей) — только прототипы. Подключаются там, где нужно создавать объекты класса и вызывать легкие функции.
3. a_impl.h — определения тяжелых функций. Подключаются только там, где они вызываются.

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

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

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

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

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

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

Вот смотри. Сейчас ваш процесс выглядит примерно так.

Тимлид: Нужно [исправить баг А|реализовать стори B|быстро что-то подправить в модуле C]
Разраб: Yes, sir!

Разработчк изменяет пару строк кода где-то очень глубоко в кишках исходников. И говорит "готово!". А тимлид "А ты проверил?". И разработчик идет курить бамбук, пока все пересобирается, чтобы потом еще полчаса вручную докликивать программу в состояние, в котором он может косвенно проверить часть функциональности внесенного изменения. Обнаруживает баг в багфиксе и все по-новому. Два часа рабочего времени жестоко убито. Мотивация утопилась в унитазе, а профессиональная гордость хлещет водяру из горла.

А вот как выглядит процесс разработки здорового человека:
Разраб: так, что у нас тут в беклоге вниманием обделено? О! Поддержка формата времени протокола (страшная аббривеатура) в сетевом модуле.
Разраб: Ага, понятно, наконец-то мы будет показывать настоящее время, а не забивать его <unknown>. Так, где у нас спецификация...
(5 минут)
Разраб: Я хочу того же, что курили аффтфры спецификации протокола. Открывает Wireshark и выдергивает из сетевой сессии с прибором сообщения, содержащие оные типы. В случае отсутствия прибора или wireshark'a изобретает Hex-dump нужного PDU самостоятельно или заимствует его из спецификации, если аффтары озаботились примерами. В процессе придумывает забавные примеры невалидного элемента. Добавляет в протокола поддержку нового типа, а в проект юнит-тестов — проверку работы парсера, используюя награбленные или придуманные сырые данные. Не забывает тест, в котором на вход парсера подается мусор или специально инвалидированные данные. Щелкает "билд" на юнит-тест проекте. Оный собирает измененную либу парсера протокола, собирается сам и запускается. В консоли — 2 failed tests, которые разработчик нарочно зафейлил, чтобы проверить сам себя. Исправляет проваленные тесты, добавляет новые для граничных условий и обнаруженных серых пятен в спецификации, перезапускает билд. Через 5 минут — XXX tests passed.

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

Это звучит как утопия, и привычные к методам разработки каменного века в это не верят, пока сами не увидят. Но как бы то ни было — вы все еще пользуетесь отладчиком при разработке? Тогда мы идем к вам!

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

__>я немного про другое спрашивал — как с такими временами перекомпиляции можно выполнять разработку проекта (тот же дебагинг)?
Я говорил про полную перекомпиляцию. При отладке меняется один юнит и его перекомпиляция плю слинковка не занимают много времени.

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

__>Разработчики языка вообще в эту сторону смотрят?
Просто дроби на либы и компилируй по частям.

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

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

Необязательно. Достаточно просто аккуратно прописывать include-ы (и максимально использовать упомянутые fwd include-ы), чтобы не было такого, что все включается во все.
Тогда будет пересобираться только то, что необходимо.
Ну и параллельный make никто не отменял, только, опять же, он должен быть разумно написан.

Здравствуйте, _hum_, Вы писали:
__>я немного про другое спрашивал — как с такими временами перекомпиляции можно выполнять разработку проекта (тот же дебагинг)?
это одна из главных причин, по которой отладка вручную заменяется тестами

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

L>В итоге — полностью реализовананя новая функциональность, покрытая тестами и даже в некоторых случаях прошедшая regression — ранее написанные тесты покажут, если новая функциональность вносит breaking change. Причем, за время, которого не хватило бы на полную сборку проекта и хотя бы один ручной тестовый прогон. Причем, проект автоматически прогоняет даже такие условия, которые во время ручного теста проверить невозможно.

L>Это звучит как утопия, и привычные к методам разработки каменного века в это не верят, пока сами не увидят. Но как бы то ни было — вы все еще пользуетесь отладчиком при разработке? Тогда мы идем к вам!

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

L>>Это звучит как утопия, и привычные к методам разработки каменного века в это не верят, пока сами не увидят. Но как бы то ни было — вы все еще пользуетесь отладчиком при разработке? Тогда мы идем к вам!
SVZ>Звучит красиво. А на деле, млин, угрохается пара дней на несколько юнит тестов, и никакой гарантии, что покрыты все случаи. После чего на тесты кладется ооот-такой болт.
SVZ>Проходили.

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

Поэтому я и говорю — в подобных случаях помочь может только фанатичный адепт церкви святого gUnit и пророка его TDD. С полным арсеналом средств святой инквизиции и горящими глазами.

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

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

A>>Что-то ты белаешь неправильно. Это твой проект?

__>да

Тогда ты свободен в экспериментировании. Экспериментируй!

A>>Посмотри-подумай, как ты добился таких выдающихся результатов.

__>думаю, из-за шаблонов

Я тоже так думаю, но есть инструмент, а есть умение его применять.

__>несжатых у меня собственных файлов (не включая библиотек) — 9Мб

Это очень много. Как ты их вообще в голове держишь?
У меня текста на порядок меньше и без шаблонов. Тебе действительно столько надо?

A>>Если правка в одном файле — то я просто не успеваю морнуть.

__>смотря в каком. если в cpp, который к тому же слабо связан с другими, то конечно, будет быстро

Умение писать несвязаннае файлы — отдельное колдунство. От языка не зависит.

A>>Может быть не нужны тебе эти шаблоны?
A>>Чё зря страдать-то?

__>потому что, во-первых, они убирают дублирование кода,

По таким фразам видно очень молодого программиста, который пока очень мало книг прочитал.

Где они убирают дублирование кода? Не дублируй код. Ты что, сотню типов расплодил? Не плоди типы.
Вот статья "как два программиста пекли хлеб":
https://habrahabr.ru/post/153225/

__>а во-вторых, речь жла не об этом,а о том, что с++ идет по пути все большей шаблонизации, а тут такая засада

Разумеется. Но тут уж твоя свобода воли — хочешь ты за компанию удавиться или нет.

Давай ещё пару советов дам.

1) Ну вот например шаблоны. Зачем они тебе нужны?
Шаблоны пошли в С++ мир из STL. Ты используешь именно STL?
Вот я пишу на Qt. А там — своя библиотека контейнеров.
И почему-то эти шаблоны собираются за секунды.

2) Можно писать вот так:

// главный и единственный компилируемый файл
# include <stl_all>

# include <my_first_file.cpp>
# include <my_second_file.cpp>
...

В чём тут прикол — компилятор один раз проходит по ужасным файлам STL, а не много раз как в твоём проекте.
Но при этом cpp-шники должны быть написаны в особой манере, чтобы их можно было включать таким образом.
Но это же твой проект...

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

__>я начинаю напоминать сам себе какого-то просветителя, который приехал на остров дикарей и стал знакомить их со Словом Божием.

Story of my life.

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

Дело в том, что это не вина человека. Просто ему не повезло быть частью команды с правильно поставленным процессом. Неведомо ему, что это есть хорошо... ой... не, мы и правда иногда напоминаем церковь свидетелей ASSERT_EQ()

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

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

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

Совершенно верно.

__>- тесты настолько специфичные, что по срабатыванию сразу можно сказать, где кроется ошибка в юните

Совершенно верно.

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

С вопросами веры в другой форум. Код обязан быть простым вне зависимости от сложности системы. Сложный для понимания и тестирования код даже специальное название имеет. Говнокод.

Для того, чтобы можно было реализовать первые два предположения, необходимо, чтобы код был разбит на тестируемые юниты. Это можно и нужно делать вообще всегда, алгоритмическая же сложность системы тут ортогональна. Юнит-тесты в принципе помогают поддерживать хороший уровень декомпозиции кода.

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

А вот это уже пример так называемого вранья.

Есть такое правило — If it worth doing, it worth testing. If it not worth testing, why bother doing it in the first place?

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

Здравствуйте, _hum_, Вы писали:
__>>при этом, понимаете, Вася создал огромную ценность в виде минимальных некорректных примеров разных классов, а Петя просто проторчал в дебагере, выискивая какие-то опечатки, по всей видимости, еще и не все найденные. есть желание заниматься поиском его опечаток?
__>простите, так вася тестировщик или девелопер?

вообще, этот подход с тестами стал вырисовываться в начале 2000ых — пришло наверное даже их спортивного программирования, но адаптированного к реальному миру.
помню, году в 2005ом были предложения у нас по проекту так сделать, но непонятно было как наш говнокод переписывать. самые прошаренные именно тогда и стали переходить и даже тормозной микрософт, позже всех, 3 года назад перешел на эту схему.
почти все сильные программисты, с которыми я когда-то работал по разны причинах, в разные компании, свалили из России. и вот остались по всей видимости те, кто остает от общего мирового тренда в разработке, лет, уже получается, на 10. это меня, конечно, удивило очень сильно, прямо мега-открытие. когда люди в 2016ом году говорят про девелоперов и тестеров, размышляют о преимуществах дебагера или о невозможности написания тестов — это сильно!

это сильная заявка в мировые аутсайдеры разработки

Здравствуйте, _hum_, Вы писали:
__>ну, раз так (если тес ты — не для поиска ошибок, а для проверки соответствия функциональным требованиям), тогда зачем же вы тут дружно с __kot2 пытаетесь нас заставить отказаться от дебагера?

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

смотрите сериал "физрук"? там есть такой персонаж — Усач. ух, извращенец, меня аж всего передергивает когда он там начинает то с баяном, то еще с чем красоваться. но персонаж яркий! мне он нравится, крассный актер, офигенная находка. за людьми, которые сидят в дебагере, прикольно наблюдать, но работать с ними — нет, не сложно, а, если точнее, невыносимо

вспоминая еще одного персонажа — как говорил Гомер Симпсон — "это противоествественно. и должно быть противозаконно!"

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

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

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

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

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

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

E>Это +100500!
E>Тока начиная с некоторого уровня попытка это сделать без юнит-тестов означает проф. непригодность...

fixed.

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

E>>>А критерий "пользователь испытывает дикий восторг от красивого и удобного интерфейса" катит?..

L>>Катит. Если пользователя можно подключить электродами к компьютеру и залить в репозиторий.

E>Это не серьёзно...

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

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

L>>Равно как "произвольный шрифт" к "хорошему UI" тоже особо не относится.

BFE>Это ещё почему? Ровно наоборот: у людей разные вкусы, разные мониторы, разные предпочтения цветовой гаммы и разное зрение. Кто-то не может без clear type, а кто-то его ненавидит. Поэтому хороший UI должен быть подстраиваться под конкретного пользователя. А это, в числе прочего, предполагает и выбор подходящего шрифта.

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

Только в любом случае это задача дизайнера.

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

L>>>Равно как "произвольный шрифт" к "хорошему UI" тоже особо не относится.
BFE>>Это ещё почему? Ровно наоборот: у людей разные вкусы, разные мониторы, разные предпочтения цветовой гаммы и разное зрение. Кто-то не может без clear type, а кто-то его ненавидит. Поэтому хороший UI должен быть подстраиваться под конкретного пользователя. А это, в числе прочего, предполагает и выбор подходящего шрифта.
L>Вот на что я не занимаюсь UI, но прекрасно знаю, что для чтения с экрана подходит не то, что юзер в данный момент "предпочитает", а весьма ограниченный выбор типов шрифтов. Не говоря уже о цветовой гамме.
Это заблуждение. Я думаю, что мне даже понятна психологическая составляющая неприятия разнообразия UI. Это неприятие отражено, например в этой вашей фразе:

Даже industry standard протоколы существуют в нескольких вариантах, и при этом каждый производитель умудряется по-своему понять определенные пункты стандарта

Употребление слова "умудряется" свидетельствует о негативном отношении к разнообразию, что, несомненно, положительное качество для человека разрабатывающего системы производственного контроля. Но у него есть и оборотная сторона. В частности — отрицание того, что разным людям удобно работать с разными размерами шрифта. Люди с выраженной миопией предпочитают мелкий шрифт, а люди с дальнозоркостью — большой размер шрифта. У последних будет болеть голова, если они будут работать со шрифтами настроенными для человека с миопией.

L>Только в любом случае это задача дизайнера.
Дизайнеры будут программировать способы отрисовок и размеры кнопки? Или, может, дизайнеры понимают требования к шрифту для программистов?
Не знаю как сейчас, я давно не занимаюсь UI, но лет 10 назад дизайнеры даже близко не понимали проблем и задач связанных с хорошим интерфейсом пользователя.

Здравствуйте, _hum_, Вы писали:
__>но! для того, чтобы понять, в чем именно ошибка, придется, либо писать наиподбробнейшие тесты (вплоть до тестирования присваивания uint8_t a = b; assert(a == b); ), либо положиться на дебагер. думаю, в реальности резонно выбирать золотую середину. иными словами, "не вместо, а вместе" (с)

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

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

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

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

У нас полная перекомпиляция проекта на icore 5 занимает порядка 2 часов. Причем "светлые головы" заставили отказаться от предкомпилированных заголовков, т.к. Jenkins'у от них плохо становится.

__>Не совсем понимаю, как разрабатываются большие проекты на С++? У меня он пока средний — около 2 Mb в архиве, и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти) (а изначально так и вовсе доходило до 40, пока не сделал максимальную развязку). Ситуацию усугубляет повсеместно внедрение шаблонов, которые еще больше увеличивают это время. Все бы ничего, но невозможно же дебаггинг проводить — одно исправление — и опять длительное ожидание перекомпиляции.
Ну и железо вроде как не шибко быстрое. У меня ноут i5, 16 гигов оперативы, чисто субъективно, стало быстрее работать при увеличении с 8 до 16 гигов ОЗУ. Свопиться скорее всего меньше стал. Ну и 2-3 виртуалки на компе легче по этой же причини держит.

А можно метрики проекта? Сколько строк кода, какие библиототеки используете?

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

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

W>>Тут первичная проблема в header-only библиотеках. Если шаблонная магия находится не в заголовочном файле, который включается в пол-программы, а внутри соответствующего cpp, то ничего страшного не происходит.

J>Мой подход такой:
J>хедеры для header-only компонента А делятся на три категории:
J>1. a_fwd.h — Чистый forward declaration: только пространства имен, имена классов и функций в них. Подключаются там, где нужно просто имя типа/функции (например, переменная-указатель на тип).
J>2. a.h — "нормальный хедер": пространства имен, определения классов, но для тяжелых функций (тяжелых как в смысле кода, так и в смысле зависимостей) — только прототипы. Подключаются там, где нужно создавать объекты класса и вызывать легкие функции.
J>3. a_impl.h — определения тяжелых функций. Подключаются только там, где они вызываются.

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

спасибо, буду иметь в виду.
но мне не нравится, что я должен в угоду компилzтору, а не логике проекта, разносить код. а самое плохое — я должен вытаскивать из внутренностей своего класса подклассы, только чтобы иметь возможность их форвард-объявления

(

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

__>Здравствуйте, _hum_, Вы писали:
__>>я немного про другое спрашивал — как с такими временами перекомпиляции можно выполнять разработку проекта (тот же дебагинг)?
__>это одна из главных причин, по которой отладка вручную заменяется тестами

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

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

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

L>Во-первых, не "ничего не работает", а "не проходит тест А", что означает, что "алгоритм не выдает ожидаемый результат в определенных контролируемых условиях". К примеру, "ломается на граничных условиях". "Расходится при определенных валидных данных". "Падает на неправильных данных".
L>Как правило, этой информации достаточно для быстрой локализации и исправления ошибки.

По-моему — как повезёт. Может хватить, а может и нет

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

A>2) Можно писать вот так:
A>

A>// главный и единственный компилируемый файл
A># include <stl_all>

A># include <my_first_file.cpp>
A># include <my_second_file.cpp>
A>...
A>

Только если заранее к этому не готовиться, то такое может совсем не просто оказаться.

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

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

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

Если аккуратно прописывать зависимости, то проблем имхо быть не должно.

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

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

Монетку кину, как же еще?

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

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

Ну и что, что не было? добавить его дело 30 секунд. Вообще не стоит обсуждения.
А уж указывать, в каком месте тестируемого ошибка? А ключ от квартиры, где деньги лежат, не нужен? Голова прогаммисту для чего?

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

Покрывать все строки кода тестами бессмысленно. Но вот покрыть все сценарии использования, как правило, можно и нужно.

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

Мы все пользуемся стандартными написанными кем-то компиляторами. И да, я не пишу код, в котором без ~~пол-литры~~ отладчика не разобраться. Я пишу крайне простой код, делающий весьма сложные вещи.
Код же, в котором без отладчика не разобраться, не разобраться и с отладчиком. Но в нем и не следует разбираться. Его нужно выбрасывать. Это всегда говнокод. Без исключений.

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

__>кстати, а что с эксепшенами? вот вылетает у вас он в куске кода — как вы тестируете?

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

Здравствуйте, _hum_, Вы писали:
__>только вот, действительно, я не верю, чтобы в концептуально и алгоритмически сложной системе это было возможно. да и перерасход мысли программиста на создание тестов (а в примере с транспонированием матрицы ваши тесты во много раз по объему и затратам на придумывание превосходят саму реализацию транспонирования) не факт, что окупится.
вот у вас есть длинная спагетя, которая оценивает погоду в данной точке

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

когда к вам приходит багрепорт, вы не тыкаете с полчаса, его репродюся, а сразу пишете юнит-тест, который дает баг (например, числа сортируются в лексикографическом порядке вместо нормального, сразу пишете тест equal( order("2") < order("12"), true ), сразу запускаете, он сразу падает, сразу правите код сортировки, запускаете тесты, проверяете, что теперь все работает и ничего старого не поломалось, все, можно релизить

Здравствуйте, _hum_, Вы писали:
__>это если есть зависание, а если внутри цикла стоит брейк, то будем долго и упорно ревьювить, где ж у нас что не так работает.
на конкретном примере например, транспонирования матрицы такое "зависание" цикла не пройдет ни одного теста, кроме, разве что, пустой матрицы

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

__>Здравствуйте, _hum_, Вы писали:
__>>это если есть зависание, а если внутри цикла стоит брейк, то будем долго и упорно ревьювить, где ж у нас что не так работает.
__>на конкретном примере например, транспонирования матрицы такое "зависание" цикла не пройдет ни одного теста, кроме, разве что, пустой матрицы

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

но! для того, чтобы понять, в чем именно ошибка, придется, либо писать наиподбробнейшие тесты (вплоть до тестирования присваивания uint8_t a = b; assert(a == b); ), либо положиться на дебагер. думаю, в реальности резонно выбирать золотую середину. иными словами, "не вместо, а вместе" (с)

п.с. кстати, тема данной ветки — длительность компиляции, которой, хоть с тестами, хоть без тестов, не избежать (все равно за обнаружением ошибки следует правка и перекомпиляция)

Здравствуйте, _hum_
C>>Стандартная идиома:

C>>

C>>for (unsigned i = n; i --> 0 ;)
C>>    std::cout << i << std::endl;
C>>

__>это плохо, потому что все равно делается декремент беззнаковой переменной в нуле (хоть и после ее использования). кстати, как там по стандарту — это UB или нет?

По стандарту всё корректно: ни переполнения, ни UB. Для беззнаковых, после нуля следует максимальное для данного типа число.

Здравствуйте, Мёртвый Даун, Вы писали:

МД>У нас один модуль полная перекомпиляция — 13 часов. В проекте около 200 модулей. Полностью перекомпилить проект уже никто не рискует как лет 5. Можно не дождаться, на пенсию выйти.

Боже, что вы такое пишете?

В репозитории лежат собранные бинарники?

Вот приходит новый человек — он делает клон репозитория и... что?

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

__>почти все сильные программисты, с которыми я когда-то работал по разны причинах, в разные компании, свалили из России. и вот остались по всей видимости те, кто остает от общего мирового тренда в разработке, лет, уже получается, на 10. это меня, конечно, удивило очень сильно, прямо мега-открытие. когда люди в 2016ом году говорят про девелоперов и тестеров, размышляют о преимуществах дебагера или о невозможности написания тестов — это сильно!

это сильная заявка в мировые аутсайдеры разработки

Ух ты! Адепт использует приём "я модный и успешный". Оно, конечно, хорошо — быть д'Артаньяном, только вот Россию приплели не к месту. Я, например, давно уехал.

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

BFE>>>Ну как "прекрасно". Может оказаться, что для этого надо затратить труд превосходящий по времени написание приложения.
L>>Вот у нас, почему-то, не оказалось. Мы, наверное, что-то делаем неправильно.
BFE>Наверное у вас датчики только одного (стандартизованного) типа.

Как ты думаешь, сколько типов датчиков поддерживает одна наиболее используемых в мире SCADA систем в мире?

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

Конечно. Это системная проблема, пусть у ответственных за систему голова об этом болит для начала.

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

__>

__>Unit tests created in a test-driven development environment are typically created by the developer who is writing the code being tested. Therefore, the tests may share blind spots with the code: if, for example, a developer does not realize that certain input parameters must be checked, most likely neither the test nor the code will verify those parameters. Another example: if the developer misinterprets the requirements for the module he is developing, the code and the unit tests he writes will both be wrong in the same way. Therefore, the tests will pass, giving a false sense of correctness.

Иными словами, если девелопер не использует /dev/brain в ежедневной работе, то он может даже получить false sense of correctness. Только это не проблемы юнит-тестов, любой инструмент нужно уметь правильно использовать.

__>A high number of passing unit tests may bring a false sense of security, resulting in fewer additional software testing activities, such as integration testing and compliance testing.

or may not.
Нужно просто помнить, что юнит-тесты верифицируют поведение отдельных юнитов в контролируемых условиях. То, что шасси самолета были протестированы на посдочных нагрузках и двигатели на стенде выдают обещанные ньютоны тяги, вовсе не гарантируют, что самолет полетит. С другой стороны, никто не строит самолет из копмонентов, которые не были протестированы по отдельности.

__>Ну и, наконец, из Software_testing:

Юнит-тесты — не инструмент тестирования. Это инструмент разработки.
Впрочем, называть отладчик инструментом тестирования... можно, конечно....

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

__>ну так, это же "ужас-ужас-ужас" — превращать подготовку к компиляции в отдельную инженерную задачу. эдак со временем стоит ожидать появления "специалиста по предкомпиляционной подготовке с++ проекта".

Когда работал в Варгейминге (проект wot blitz), да и не только там, у нас в команде была позиция, которая так и называлась — build engineer. Собственно сейчас, средствами CMake, танчики собираются под всё (ios/win/android + все десктопы). У всех стоит IncrediBuild. 20 минут — полная пересборка проекта (без конвертации ресурсов).

Если у вас в одиночку получился столь большой проект, что вас парит время комипляции — то что-то тут не то. Или плохо накодили или не туда двигаетесь. Где-то тут, несколько лет назад, пробегал этюд товарища Nikov (правда для C#). Как обычным дженериком на 5 аргументов нагенерить 25 метров кода и ждать компиляции более 7 минут. Жаль не могу найти.

SD>>Настоящие неудобства большие/сложные проекты приносят, когда надо туда заливать большие изменения а не при компиляции =)
__>по-моему, эти проблемы ортогональны

Это у вас просто мало опыта коммерческой разработки на больших проектах.

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

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

Тут +100500

L>Юнит-тесты — не инструмент тестирования. Это инструмент разработки.
Тут вопрос в том, какая часть всей разработки может быть сделана в TDD стиле...

Есть задачи, где под 100%, а есть где и 10% может не набраться...

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

L>>Критерий "нравится дизайнеру" не катит, как ты понимаешь.
E>А критерий "пользователь испытывает дикий восторг от красивого и удобного интерфейса" катит?..

Катит. Если пользователя можно подключить электродами к компьютеру и залить в репозиторий.

L>>Юнит-тесты — не инструмент тестирования. Это инструмент разработки.
E>Тут вопрос в том, какая часть всей разработки может быть сделана в TDD стиле...

E>Есть задачи, где под 100%, а есть где и 10% может не набраться...

Скорее, где поленились остальные 90% хоть как-то формализовать

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

SaZ>>Когда работал в Варгейминге (проект wot blitz), да и не только там, у нас в команде была позиция, которая так и называлась — build engineer. Собственно сейчас, средствами CMake, танчики собираются под всё (ios/win/android + все десктопы). У всех стоит IncrediBuild. 20 минут — полная пересборка проекта (без конвертации ресурсов).

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

Конечно. Свою карьеру я начинал в Епаме. Там для нашего проекта была целая команда билд инженеров. А ещё devops-ы есть.
Для того, чтобы это не было проблемой нужно понимать примерный объём проекта и заранее думать о масштабируемой архитекруте. Конечно, такие вещи мидлам и джунам доверять не стоит. Потому что если делать по вот этой книге:

	Чик-чик и в продакшн

То через пару лет как раз и выплывут ваши вопросы. Хотя квалифицированные менеджеры / разработчики это всё прекрасно понимают.

В вашем же случае получается так: вы заранее знаете о том, что сложность проекта будет нелинейно расти в течение нескольких лет, но всё равно не хотите выделить должные ресурсы на проработку архитектуры. Хотите, чтобы всё получилось само собой и как можно дешевле. В реальности же так не бывает. У вас цена багфикса (деньги == время, в т.ч. время компиляции) заведомо будет стремиться к бесконечности.
Увы, если вы хотите нанять волшебника, который скажет, что это не так, то, скорее всего, вы получите сказочника.

SaZ>>Если у вас в одиночку получился столь большой проект, что вас парит время комипляции — то что-то тут не то. Или плохо накодили или не туда двигаетесь. Где-то тут, несколько лет назад, пробегал этюд товарища Nikov (правда для C#). Как обычным дженериком на 5 аргументов нагенерить 25 метров кода и ждать компиляции более 7 минут. Жаль не могу найти.

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

В вашем понимании программист — это кодер. Таких, конечно, не должны заботить проблемы компилятора. Такие обычно делают всякие несложные фронтэнды на пхп/асп на аутсорс.
В моём понимании программист — это инженер. Это человек, который способен спроектировать и реализовать систему, которая будет работать. А при наличии требований к масштабированию — спроектировать хорошую архитектуру.

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

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

L>>Скорее, где поленились остальные 90% хоть как-то формализовать

E>Что значит "поленились"? Дорого или вообще не понятно как...

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

E>Давай ты расскажешь как ловца писем террористов на 100% формализовать?

Извини, но теперь только за деньги. Мне мое время нынче слишком дорого, чтобы бесплатно заниматься тем, за что людям платят хорошие деньги.
Даже если задача на 100% не формализуется, это не повод не попытаться формализовать ее на достижимые 80(79, 65, 95)%.

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

E>Но мы же не про железо, а про рулящее им ПО?..

ПО никакого отношения к успешности стиральной машины не имеет. Конечно, плохим ПО можно испортить очень хорошую вещь, но в принципе хорошие стиральные машины до сих пор могут не иметь вообще никакого ПО.

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

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

E>>Про пред/пост-условия что-то слышал?

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

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

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

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

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

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

Здравствуйте, 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, код ассерта должен полностью реализовывать алгоритм, который он верифицирует.

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

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

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

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

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

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

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

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

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

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

L>>>Это относится только к black-box тестированию. Юнит-тесты — это white-box тестирование.
__>>нет, это относится ко всему тестированию — см. статью по ссылке

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

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

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

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

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

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

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

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

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

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

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

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

__>но это же неправда — даже для обычной foo(uint32_t x, uint32_t y) практически невозможно проверить абсолютно все комбинации аргументов/

А все и не нужно... Нужно протестить все границы и ветки, а не все комбинации...

L>>Им вообще остается проверять сборку на соответствие спецификациям, по большому счету.

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

IMHO всё ровно наоборот. Если есть оттестированные блоки, которые мы компонуем типа, то юнит-тест не много дадут, а вот если мы новые блоки пишем, то там юнит-тесты блоков зело полезны...

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

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

__>>но это же неправда — даже для обычной foo(uint32_t x, uint32_t y) практически невозможно проверить абсолютно все комбинации аргументов/

E>А все и не нужно... Нужно протестить все границы и ветки, а не все комбинации...

во-первых, что такое "границы" ? граничные точки области определения функции? и почему именно в них нужно, а в других точках — не нужно?

а во-вторых, таких граничных точек может быть тоже неподъемно много для обычных вычислений

L>>>Им вообще остается проверять сборку на соответствие спецификациям, по большому счету.

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

E>IMHO всё ровно наоборот. Если есть оттестированные блоки, которые мы компонуем типа, то юнит-тест не много дадут, а вот если мы новые блоки пишем, то там юнит-тесты блоков зело полезны...

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

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

E>IMHO всё ровно наоборот. Если есть оттестированные блоки, которые мы компонуем типа, то юнит-тест не много дадут, а вот если мы новые блоки пишем, то там юнит-тесты блоков зело полезны...

Это, давай лучше про ракеты

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

L>>Рапортовать не надо. У вас есть набор юнит-тестов, которые в некотором смысле являются документацией к функции.

__>меня смущает, что все как-то нестрого, на усмотрение разработчика

нет системы...

Хм, похоже вы ищете серебряную пулю. После того как начнете пользоваться юнит-тестами, почитайте про property-based testing: https://www.google.ru/search?q=quickcheck+c%2B%2B

Например, https://github.com/thejohnfreeman/autocheck/wiki/Tutorial

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

L>>Что значит "можно"? Нужно. Так и делают. И прогоняют всегда, при каждой сборке.
E>Особенно забавно про это читать в теме, посвящённой тому, что даже билд без тестов слишком долог...

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

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

BFE>>Кстати, можете предложить не инвазивный способ тестирования?
E>RAM-диск с драйвером, позволяющим эмулировать проблемы...

Да, это хороший вариант, недорогой.

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

L>>Юнит тесты должны проверять четко формализованные критерии.
E>Бинго! Есть КУЧА ПО, критерии на который плохо поддаются формализации

E>Например, "Хорошая игрушка", "удачная стиральная машина", "лучшая в мире система ПВО" и т. д...

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

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

L>Равно как "произвольный шрифт" к "хорошему UI" тоже особо не относится.

А язык, на который переведут программу когда-нибудь?..

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

L>>А я про моноширинность, да.
BFE>Ну и причём тут моношеринность? Вы используете моноширинный шрифт для текста в кнопках?

Я UI не занимаюсь.

BFE>>>Вот, кстати, пример от сегодняшнего числа. Легко, думаете, для такого unit test написать?
L>>Отлавливать такую чертовщину — не задача юнит-тестов
BFE>Ну вот. Как дошло до практики, так — незадача.

Совершенно верно. Прочитай уже определение юнит-теста, что ли.

L>>Дизайнеры должны были предусмотреть и такое. Или ограничить минимальное разрешение.
BFE>Вы знакомы хотя бы с одним таким дизайнером?

Я не занимаюсь UI, но когда придется этим заниматься, работать с профнепригодными дизайнерами не буду ни минуты.

Не совсем понимаю, как разрабатываются большие проекты на С++? У меня он пока средний — около 2 Mb в архиве, и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти) (а изначально так и вовсе доходило до 40, пока не сделал максимальную развязку). Ситуацию усугубляет повсеместно внедрение шаблонов, которые еще больше увеличивают это время. Все бы ничего, но невозможно же дебаггинг проводить — одно исправление — и опять длительное ожидание перекомпиляции.
Из тех мер, что предлагается, самая естественная — forward declaration, но, во-первых, она работает только с классами верхнего уровня (сделать что-то наподoбие class CFoo::CSubFoo; уже нельзя), а во-вторых, и там есть подводные камни: Google C++ Style Guide/Forward_Declarations.

Разработчики языка вообще в эту сторону смотрят?

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

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

QC>У нас полная перекомпиляция проекта на icore 5 занимает порядка 2 часов. Причем "светлые головы" заставили отказаться от предкомпилированных заголовков, т.к. Jenkins'у от них плохо становится.

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

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

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

__>>я немного про другое спрашивал — как с такими временами перекомпиляции можно выполнять разработку проекта (тот же дебагинг)?
QC>Я говорил про полную перекомпиляцию. При отладке меняется один юнит и его перекомпиляция плю слинковка не занимают много времени.

то есть, в больших проектах как правило происходит уменьшение связей между частями таким образом, чтобы эти части можно было оформить в виде независимых единиц компиляции?

__>Разработчики языка вообще в эту сторону смотрят?
Ээм, что ты такое строишь. У меня рабочий проект, чуть больше миллиона строк кода, строится на не самом быстром серваке часа полтора.Под строится — понимаю только фазу сборки бинарников. Можно распараллелить сборку всякими тулами и сделать за полчасика

, только времени на эту работу никто не дает, пока всех и так устраивает.

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

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

__>>Разработчики языка вообще в эту сторону смотрят?
K>Просто дроби на либы и компилируй по частям.

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

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

__>>Разработчики языка вообще в эту сторону смотрят?
T>Ээм, что ты такое строишь. У меня рабочий проект, чуть больше миллиона строк кода, строится на не самом быстром серваке часа полтора.Под строится — понимаю только фазу сборки бинарников. Можно распараллелить сборку всякими тулами и сделать за полчасика

, только времени на эту работу никто не дает, пока всех и так устраивает.

а как вы дебагинг делаете? ведь как правило несколько десятков исправлений приходится за день вносить при разработке.

__>>Разработчики языка вообще в эту сторону смотрят?
T>Ээм, что ты такое строишь. У меня рабочий проект, чуть больше миллиона строк кода, строится на не самом быстром серваке часа полтора.Под строится — понимаю только фазу сборки бинарников. Можно распараллелить сборку всякими тулами и сделать за полчасика

, только времени на эту работу никто не дает, пока всех и так устраивает.
Несколько лет назад оптимизировал рабочий билд сервер, там почти двухкратный прирост скорости дал просто перенос машины (это виртуалка на сервере), на другой сервак с быстрым диском (NAS), если закинуть все на SSD, было б ещё быстрее.

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

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

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

J>Необязательно. Достаточно просто аккуратно прописывать include-ы (и максимально использовать упомянутые fwd include-ы), чтобы не было такого, что все включается во все.
J>Тогда будет пересобираться только то, что необходимо.
J>Ну и параллельный make никто не отменял, только, опять же, он должен быть разумно написан.

если "необязательно", то тогда ж принципиально невозможно обойтись без перекомпиляции связанных частей (манипуляции с инклюдами и форвардами позволяют только технически развязать то, что ЛОГИЧЕСКИ развязано)

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

__>>>Разработчики языка вообще в эту сторону смотрят?
T>>Ээм, что ты такое строишь. У меня рабочий проект, чуть больше миллиона строк кода, строится на не самом быстром серваке часа полтора.Под строится — понимаю только фазу сборки бинарников. Можно распараллелить сборку всякими тулами и сделать за полчасика

, только времени на эту работу никто не дает, пока всех и так устраивает.
T>Несколько лет назад оптимизировал рабочий билд сервер, там почти двухкратный прирост скорости дал просто перенос машины (это виртуалка на сервере), на другой сервак с быстрым диском (NAS), если закинуть все на SSD, было б ещё быстрее.

нуу, то есть, за счет железа...
это понятно, но ведь производительность железа растет медленнее, чем объем кода

__>а как вы дебагинг делаете? ведь как правило несколько десятков исправлений приходится за день вносить при разработке.
Ну про несколько десятков ты загнул. Обычно меняешь 1-2, ну 3 модуля связанных друг с другом. Изменений конечно может быть и много.
Вся программа состоит из порядка 200+ бинарей, сам по себе отдельный бинарник строится макисмум минут 5 на разработческом железе (ноутбучные i5-ые процы). Мелкие модули быстрее.
Билд-сервер строит 2е версии бинарей, релизные и дебажные. Программу можно накатить инсталлятором в дебаг версии. Соотвественно, дальше разработчик меняет нужную ему библиотеку и отлаживает её в составе программы, которая уже собрана в дебаг версии и нормальна дебажится. К этому всему делу рядом ещё живет символ-сервер.

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

__>это понятно, но ведь производительность железа растет медленнее, чем объем кода
Никто ж не запрещает помимо более мощного железа использовать и другие способы ускорения.
Выше уже писали, модульность, вынести хидер-онли библиотеки.
Еще, с чего бы стоило начать, посмотреть на что время тратиться при сборке.

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

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

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

__>>>Разработчики языка вообще в эту сторону смотрят?
K>>Просто дроби на либы и компилируй по частям.

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

1. А что отвечает за работу закладки?
2. Сущность, которая реализует редактирование конкретной view модели, она в каждый момент Икс одна? Или их несколько? Т.е. если закладку сменили, то сущность отвечающая за редактирование предыдущей "закладки" она остается или нет?

Если сущность одна, то нужно копать куда-нить в сторону стратегий, и общего чисто виртуального базового класса, который отвечает за редактирование модели.

Тогда это как-то эдак будет.
1. Есть указатель на IModelerEditor — это абстрактный класс, который отвечает за редактирование какой-то стороны модели. И живет этот указатель на IModelerEditor где-то в районе GUI-логики, через которую гуй с редакторами и общается.

2. При выборе закладки создаем новый класс, наследник от абстрактного IModelerEditor, который уже отвечает за редактирование конкретной "стороны" модели именно под выбранной закладкой.

3. Старый указатель IModelerEditor удаляем, на его место кладем новый из пункта 2.

Тогда все сведется к некоторой фабрике, которая конструирует конкретный наследников от IModelerEditor в зависимости от выбранной закладки, и возвращает указатель. Который уже и юзает GUI.

И только методу-фабрике будут нужны все H-файлы для всех редакторов модели. Если этот метод-фабрику вынести в отдельный модуль, то и вовсе h-файлы всех редакторов в GUI не понадобятся. Т.к. GUI и конкретный класс-редактор модели будут общаться через указатель на базовый абстрактный файл IModelerEditor.

Как-то так. Нечто подобное делал, но обошелся без отдельного модуля для "фабрики", т.к. у меня подобных "конкретных редакторов конкретной стороны модели" всего было штуки 4-5.

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

__>если "необязательно", то тогда ж принципиально невозможно обойтись без перекомпиляции связанных частей (манипуляции с инклюдами и форвардами позволяют только технически развязать то, что ЛОГИЧЕСКИ развязано)

Есть, например, паттерн Dependency injection. Он, помимо всяких плюсов вроде облегчения unit-тестирования, вполне способен порезать и «логически связанные» части программы. Конечно, в include останется какая-то часть, отвечающая за общий интерфейс. Но в контексте этой темы это не так важно: объявление абстрактного базового класса не сильно замедляет компиляцию. Но зато реализация может уже собираться независимо от вызывающего кода. И перекомпилироваться будут всегда лишь какие-то малые части библиотек. Разумеется пока интерфейс не поменяется — но он как бы и не должен часто меняться.

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

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

T>>>Ээм, что ты такое строишь. У меня рабочий проект, чуть больше миллиона строк кода, строится на не самом быстром серваке часа полтора.Под строится — понимаю только фазу сборки бинарников. Можно распараллелить сборку всякими тулами и сделать за полчасика

, только времени на эту работу никто не дает, пока всех и так устраивает.

__>>а как вы дебагинг делаете? ведь как правило несколько десятков исправлений приходится за день вносить при разработке.

L>За использование отладчика в процессе разработки нужно сразу разжаловать в младшие черпальщики ассенизаторных обозов.

ничего не понял. дебаггинг уже устарел?

L>В процессе разработки должны писаться тесты, которые должны автоматически выполняться при сборке проекта.

а тесты пишутся без ошибок?

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

слова правильные, только как это реально следать

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

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

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

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

__>>>>Разработчики языка вообще в эту сторону смотрят?
K>>>Просто дроби на либы и компилируй по частям.

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

C>1. А что отвечает за работу закладки?
C>2. Сущность, которая реализует редактирование конкретной view модели, она в каждый момент Икс одна? Или их несколько? Т.е. если закладку сменили, то сущность отвечающая за редактирование предыдущей "закладки" она остается или нет?

C>Если сущность одна, то нужно копать куда-нить в сторону стратегий, и общего чисто виртуального базового класса, который отвечает за редактирование модели.

ну, то есть, менять архитектуру. понятно.

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

T>Ну и железо вроде как не шибко быстрое. У меня ноут i5, 16 гигов оперативы, чисто субъективно, стало быстрее работать при увеличении с 8 до 16 гигов ОЗУ. Свопиться скорее всего меньше стал. Ну и 2-3 виртуалки на компе легче по этой же причине держит.

+ SSD ещё очень хорошо ускоряет процесс.

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

T>Еще, с чего бы стоило начать, посмотреть на что время тратиться при сборке.

а есть какие-нибудь бесплатные анализаторы? а то у меня в vs2013 не показывает, на что время тратится — просто comiling xxxxx.cpp и три минуты, потом следующий, а по каким она там модулям лазит и на чем стопорится — непонятно.

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

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

L>>За использование отладчика в процессе разработки нужно сразу разжаловать в младшие черпальщики ассенизаторных обозов.
__>ничего не понял. дебаггинг уже устарел?

При разработке? Уже лет 20 как как устарел. Если не больше.

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

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

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

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

Очень часто именно практика написания тестов спасает от многих эпизодов боли пониже спины. То, что тесты помогают писать наименее связанный код, к делу пока не относится, но их наличие заставляет натурально организовывать проект в отдельные минимально связанные единицы.
Ну а потом можно применять тяжелую артиллерию — precompiled headers, системы распеределнной компиляции и прочее шаманство.

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

T>А можно метрики проекта? Сколько строк кода, какие библиототеки используете?

2Mb чистого текста в rar-формате
библиотеки — boost::signal2
qt — обычный гуи
cereal (вот после начала его использования, субъективно, все и начало тормозиться)

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

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

__>>если "необязательно", то тогда ж принципиально невозможно обойтись без перекомпиляции связанных частей (манипуляции с инклюдами и форвардами позволяют только технически развязать то, что ЛОГИЧЕСКИ развязано)

W>Есть, например, паттерн Dependency injection. Он, помимо всяких плюсов вроде облегчения unit-тестирования, вполне способен порезать и «логически связанные» части программы.

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

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

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

T>>Ну и железо вроде как не шибко быстрое. У меня ноут i5, 16 гигов оперативы, чисто субъективно, стало быстрее работать при увеличении с 8 до 16 гигов ОЗУ. Свопиться скорее всего меньше стал. Ну и 2-3 виртуалки на компе легче по этой же причине держит.

D>+ SSD ещё очень хорошо ускоряет процесс.

охотно верю. но это временное решение. надо с этой проблемой что-то системно делать (на c#, говорят, вообще не знают, что такое время компиляции)

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

D>+ SSD ещё очень хорошо ускоряет процесс.

Кстати, а зачем SSD если 32 гига оперативы?
Сам комп не выключать а засыпать, и я не видел загрузку винта более 1% уже после 30-40 минут после загрузки. Все летает. Особенно после того как поставил самую быструю память.

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

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

__>>Не совсем понимаю, как разрабатываются большие проекты на С++? У меня он пока средний — около 2 Mb в архиве, и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти) (а изначально так и вовсе доходило до 40, пока не сделал максимальную развязку). Ситуацию усугубляет повсеместно внедрение шаблонов, которые еще больше увеличивают это время. Все бы ничего, но невозможно же дебаггинг проводить — одно исправление — и опять длительное ожидание перекомпиляции.

Pzz>Гы. Я застал времена, когда программа выдавалась оператору ЭВМ на бумаге, там набивалась на перфокарты (нередко с ошибками), прогонялась через ЭВМ в порядке общей очереди, а результат можно было получить в виде распечатки на следующий день.

Pzz>Большое время прогонов заставляет нас больше думать, и меньше тыкать кнопки.

ой, если б так было. на само деле наукоемкого кода — процентов 10%, остальное — GUI, коды сериализации и прочая мудатень, которая жрет столько времени на разработку, а на деле — просто интерфейс доступа к основному коду

Здравствуйте, Andrew.W Worobow, Вы писали:

D>>+ SSD ещё очень хорошо ускоряет процесс.

AWW>Кстати, а зачем SSD если 32 гига оперативы?
32 прикольно. У меня 16, до конца не загружаются, вроде хватает.

AWW>Сам комп не выключать а засыпать, и я не видел загрузку винта более 1% уже после 30-40 минут после загрузки. Все летает. Особенно после того как поставил самую быструю память.

У меня сейчас порядка 2000 исходных файлов и чуть больше заголовочных файлов.
На каждый — прочитать, пропроцесс/компиляция, результат записать на диск бинарники.
Потом читать с диска бинарники, записать на диск исполняемый файл / библиотеку.

А, я вот подумал, если делать ramdrive, туда скидывать проект и оттуда компилировать, тогда будет ещё быстрее, да.

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

sciter-32/64 dll.

Размер src архива (zip) — 6.3 Mb.

Полная сборка win32/Release — 3 минуты. win32/Debug — 2 минуты.
MS VC 2010

Проект разбит на модули — static libs. Используются активно precompiled headers.

Полная сборка делается редко. В основном local change — build — run — test.
Редко когда эта последовательность занимет больше чем 30 секунд.

Рабочая машина — обычная, c SSD вместо HD.

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

D>А, я вот подумал, если делать ramdrive, туда скидывать проект и оттуда компилировать, тогда будет ещё быстрее, да.

Пробовал. Особого ускорения не отметил почему-то

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

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

Уменьшай связность по хедерам.
Пимплы, предобъявления классов, фабрики.

// main.h

#include "some_view.h" // плохо!
class SomeView; // хорошо!

class MainWindow {
  SomeView* child_;
  ...
};

///////////////////

// main.cpp

#include "main.h"
#include "some_view.h"

MainWindow::Create() {
  child_ = new SomeView(); // неплохо
  child_ = NewSomeView(); // лучше, потому что можно спрятать толстую реализацию за интерфейс и тонкую фабрику
};

__>и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти)

Для примера:
У меня Qt на C2D c 8Gb RAM с CL=/MP собирался где то часов 6.
Сейчас на i7 5960X с 64Gb RAM где то минут 25 от силы.

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

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

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

К>Уменьшай связность по хедерам.
К>Пимплы, предобъявления классов, фабрики.
К>

К>// main.h

К>#include "some_view.h" // плохо!
К>class SomeView; // хорошо!

К>class MainWindow {
К>  SomeView* child_;
К>  ...
К>};

К>///////////////////

К>// main.cpp

К>#include "main.h"
К>#include "some_view.h"

К>MainWindow::Create() {
К>  child_ = new SomeView(); // неплохо
К>  child_ = NewSomeView(); // лучше, потому что можно спрятать толстую реализацию за интерфейс и тонкую фабрику
К>};
К>

спасибо. а что делать с

1.h
class CFoo
{
public:
 struct TFoo{}
};


2.h

void foo(CSubFoo::TFoo& X);

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

__>>и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти)

N>Для примера:
N>У меня Qt на C2D c 8Gb RAM с CL=/MP собирался где то часов 6.
N>Сейчас на i7 5960X с 64Gb RAM где то минут 25 от силы.

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

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

L>>>Это звучит как утопия, и привычные к методам разработки каменного века в это не верят, пока сами не увидят. Но как бы то ни было — вы все еще пользуетесь отладчиком при разработке? Тогда мы идем к вам!
SVZ>>Звучит красиво. А на деле, млин, угрохается пара дней на несколько юнит тестов, и никакой гарантии, что покрыты все случаи. После чего на тесты кладется ооот-такой болт.
SVZ>>Проходили.

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

От проекта тоже зависит. Скажем, для какого-нибудь моделирования юнит-тесты вообще бесполезны. Можно только смотреть результаты моделирования и сравнивать с эталоном.

L>Поэтому я и говорю — в подобных случаях помочь может только фанатичный адепт церкви святого gUnit и пророка его TDD. С полным арсеналом средств святой инквизиции и горящими глазами.

В добавок надо время выделять отдельно на написание тестов (это ИМХО главная сложность). А времени, как обычно, катастрофически не хватает.

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

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

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

L>А вот как выглядит процесс разработки здорового человека:

	text
	L>Разраб: так, что у нас тут в беклоге вниманием обделено? О! Поддержка формата времени протокола (страшная аббривеатура) в сетевом модуле. L>Разраб: Ага, понятно, наконец-то мы будет показывать настоящее время, а не забивать его <unknown>. Так, где у нас спецификация... L>(5 минут) L>Разраб: Я хочу того же, что курили аффтфры спецификации протокола. Открывает Wireshark и выдергивает из сетевой сессии с прибором сообщения, содержащие оные типы. В случае отсутствия прибора или wireshark'a изобретает Hex-dump нужного PDU самостоятельно или заимствует его из спецификации, если аффтары озаботились примерами. В процессе придумывает забавные примеры невалидного элемента. Добавляет в протокола поддержку нового типа, а в проект юнит-тестов — проверку работы парсера, используюя награбленные или придуманные сырые данные. Не забывает тест, в котором на вход парсера подается мусор или специально инвалидированные данные. Щелкает "билд" на юнит-тест проекте. Оный собирает измененную либу парсера протокола, собирается сам и запускается. В консоли — 2 failed tests, которые разработчик нарочно зафейлил, чтобы проверить сам себя. Исправляет проваленные тесты, добавляет новые для граничных условий и обнаруженных серых пятен в спецификации, перезапускает билд. Через 5 минут — XXX tests passed. L>В итоге — полностью реализовананя новая функциональность, покрытая тестами и даже в некоторых случаях прошедшая regression — ранее написанные тесты покажут, если новая функциональность вносит breaking change. Причем, за время, которого не хватило бы на полную сборку проекта и хотя бы один ручной тестовый прогон. Причем, проект автоматически прогоняет даже такие условия, которые во время ручного теста проверить невозможно. L>Это звучит как утопия, и привычные к методам разработки каменного века в это не верят, пока сами не увидят. Но как бы то ни было — вы все еще пользуетесь отладчиком при разработке? Тогда мы идем к вам!

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

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

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

__>>Не совсем понимаю, как разрабатываются большие проекты на С++? У меня он пока средний — около 2 Mb в архиве, и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти) (а изначально так и вовсе доходило до 40, пока не сделал максимальную развязку). Ситуацию усугубляет повсеместно внедрение шаблонов, которые еще больше увеличивают это время. Все бы ничего, но невозможно же дебаггинг проводить — одно исправление — и опять длительное ожидание перекомпиляции.

A>Что-то ты белаешь неправильно. Это твой проект?

да

A>Посмотри-подумай, как ты добился таких выдающихся результатов.

думаю, из-за шаблонов

A>У меня проект — 1 МБ (несжатых).

несжатых у меня собственных файлов (не включая библиотек) — 9Мб

A>Полностью собирается за одну (!!!) секунду.
A>Если правка в одном файле — то я просто не успеваю морнуть.

смотря в каком. если в cpp, который к тому же слабо связан с другими, то конечно, будет быстро

A>Может быть не нужны тебе эти шаблоны?
A>Чё зря страдать-то?

потому что, во-первых, они убирают дублирование кода, а во-вторых, речь жла не об этом,а о том, что с++ идет по пути все большей шаблонизации, а тут такая засада

Здравствуйте, Stanislav V. Zudin, Вы писали:

L>>Все это проходили. Потому что приделывать юнит-тесты к проекту, который изначально писался без них... там не только мотивация, там к унитазу очередь выстроится топиться.
SVZ>От проекта тоже зависит. Скажем, для какого-нибудь моделирования юнит-тесты вообще бесполезны. Можно только смотреть результаты моделирования и сравнивать с эталоном.

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

L>>Поэтому я и говорю — в подобных случаях помочь может только фанатичный адепт церкви святого gUnit и пророка его TDD. С полным арсеналом средств святой инквизиции и горящими глазами.
SVZ>В добавок надо время выделять отдельно на написание тестов (это ИМХО главная сложность). А времени, как обычно, катастрофически не хватает.

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

    Matrix transpose(const Matrix& original);

Налил кофе и написал следующие три теста

    TEST(transposeMatrix, transposeNegative)
    {
        // this is more a border case test
        ASSERT_TRUE(transpose(emptyMatrix).empty());   // Also checks that we don't crash if matrix is empty
    }

    TEST(transposeMatrix, transposePositiveSymmetrical)
    {
        Matrix symmetricalMatrix = ...; // Initialize
        Matrix expected = ...; // Manually transposed matrix
        ASSERT_EQ(expected, transpose(symmetricalMatrix));
        ASSERT_EQ(symmetricalMatrix, transpose(transpose(symmetricalMatrix)));
    }

    TEST(transposeMatrix, transposePositiveAsymmetrical)
    {
        Matrix asymmetricalMatrix = ...; // Initialize
        Matrix expected = ...; // Manually transposed matrix
        ASSERT_EQ(expected, transpose(asymmetricalMatrix ));
        ASSERT_EQ(asymmetricalMatrix , transpose(transpose(asymmetricalMatrix )));
    }

Потом написал собственно код транспонирования.

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

Ты мне лучше скажи, зачем тут вообще отладчик может понадобиться?

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

T>Вот-вот, такое бодрое описание как всё зашибись, только в нём ничего нет про, собственно, разработку новой функциональности.

Ребята, вы меня пугаете:

Разраб: так, что у нас тут в беклоге вниманием обделено? О! Поддержка формата времени протокола (страшная аббривеатура) в сетевом модуле.

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

L>>Ребята, вы меня пугаете:

L>>

L>>
Разраб: так, что у нас тут в беклоге вниманием обделено? О! Поддержка формата времени протокола (страшная аббривеатура) в сетевом модуле.

T>Прекрасно, и что? Как будто написать парсер времени — это такой самоочевидный кусок кода из 1 строки.

Это парсер метки времени хитровыдуманного индустриального протокола, который несет в себе, кроме собственно метки времени, еще кучу всякой ~~ерунды~~ полезной информации вроде индикатора качества часов, источника синхронизации, индикатора аварии и т.п, причем ужато все это самым извращенным способом, до которого можно было додуматься только под веществами. Те, кто могут такое делать в одну строку, какают фиалками и ездят на единорогах

T>Я верю, что есть люди, которые на бумажке пишут алгоритмы любой сложности и отлаживают их исключительно по входным выходным данным. Но, честно говоря, не совсем понимаю, как им это удаётся.
T>Пусть программист сделал ошибку и его алгоритм расходится в заоблачные дали.

Если это программист, то он знает, какие условия нужно проверять. В том числе он также напишет тест, проверяющий, не расходится ли алгоритм в заоблачные дали. И так его и назовет. И если этот тест провалится, то даже никакого "пристального взгляда" не понадобится, все будет понятно сразу. И, что характерно, написание такого теста (один раз, к слову сказать), займет меньше времени, чем просто запустить программу под отладчиком. Один раз. И, что будет оценено намного позже, этот тест будет там тогда, когда о нем уже забудут и какой-то джуниор в попытке "улучшить" алгоритм его сломает. И этот тест тут же даст ему по рукам.

T>Я полагаю, что во многих случаях под дебаггером можно разобраться гораздо быстрее.

Нет. Дебаггер для разработчика — это даже не каменный топор. Это намного хуже.

P.S. Я всегда говорил, что на время разработки у программистов нужно отбирать отладчик.

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

T>Вот я по то же. black-box тестирование алгоритма может сказать только то, что он в некоторых случаях работает правильно или нет.

Это не black-box, это white-box. Вы можете посмотреть внутрь ящика и сказать "Ба!"

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

Если вы подозреваете, что в алгоритме есть баг, просто пишете тест, воспроизводящий условия, при котором, как вы подозреваете, алгоритм ломается. Это просто и быстро. Проверяете свои подозрения. В отладчике в общем случае это сделать уже невозможно.

L>>Если это программист, то он знает, какие условия нужно проверять. В том числе он также напишет тест, проверяющий, не расходится ли алгоритм в заоблачные дали. И так его и назовет. И если этот тест провалится, то даже никакого "пристального взгляда" не понадобится, все будет понятно сразу.
T>Так что именно будет понятно из теста-то? Что ничего не работает? Что дальше делать?

Во-первых, не "ничего не работает", а "не проходит тест А", что означает, что "алгоритм не выдает ожидаемый результат в определенных контролируемых условиях". К примеру, "ломается на граничных условиях". "Расходится при определенных валидных данных". "Падает на неправильных данных".
Как правило, этой информации достаточно для быстрой локализации и исправления ошибки.

L>>И, что характерно, написание такого теста (один раз, к слову сказать), займет меньше времени, чем просто запустить программу под отладчиком. Один раз. И, что будет оценено намного позже, этот тест будет там тогда, когда о нем уже забудут и какой-то джуниор в попытке "улучшить" алгоритм его сломает. И этот тест тут же даст ему по рукам.
T>Я совершенно не пытаюсь сказать, что тесты не нужны.

Тесты — необходимы. Отладчик — вреден.

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

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

L>Если вы подозреваете, что в алгоритме есть баг, просто пишете тест, воспроизводящий условия, при котором, как вы подозреваете, алгоритм ломается. Это просто и быстро. Проверяете свои подозрения. В отладчике в общем случае это сделать уже невозможно.

Дьявол кроется в ~~деталях~~ выделенном.
Не всегда просто и нифига не быстро.
В моей практике это сложно и геморройно. И еще объемно.

Как правило это добрая сотня строк, чтобы сварганить минимально-необходимый набор данных. И еще сотня — чтобы проверить результат. Написание одного теста занимало по полдня без перекуров. Работа алгоритма же не сводится к булевскому значению. Из полученных данных еще надо выудить нечто, что можно проверить. И в каждом тесте это "нечто" будет разным.
Из-за этого у нас прижились рантайм проверки (ассерты) всего и вся и отладчик.

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

L>>Как правило, этой информации достаточно для быстрой локализации и исправления ошибки.
T>По-моему — как повезёт. Может хватить, а может и нет

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

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

__>спасибо. а что делать с
__>

__>1.h
__>class CFoo
__>{
__>public:
__> struct TFoo{}
__>};

__>2.h

__>void foo(CSubFoo::TFoo& X);
__>

1) Сделать 1.h максимально дешёвым и включать его в 2.h
2) Вынести TFoo на уровень неймспейса и предобъявлять (в том числе шаблоны — их тоже можно предобъявлять)
3) Разнести CFoo на две части, одну лёгкую с определениями зависимых имён — и включать в 2.h, вторую тяжёлую унаследовать от первой и поместить в другой хедер 1impl.h

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

T>>А можно метрики проекта? Сколько строк кода, какие библиототеки используете?
__>2Mb чистого текста в rar-формате

А сколько в строках? (в студии, в проекте, ctrl+shift+f , во всём солюшене , use regular expressions , найти конец строки, в последней строке — в результатах — будет указано количество строк )

__>cereal (вот после начала его использования, субъективно, все и начало тормозиться)
Посмотрел исходники и возник вопрос: а как там с обратной совместимостью по данным? Имя какой-нибудь сереализуемой переменной уже пробовал поменять?

Здравствуйте, Stanislav V. Zudin, Вы писали:

L>>Если вы подозреваете, что в алгоритме есть баг, просто пишете тест, воспроизводящий условия, при котором, как вы подозреваете, алгоритм ломается. Это просто и быстро. Проверяете свои подозрения. В отладчике в общем случае это сделать уже невозможно.
SVZ>Дьявол кроется в ~~деталях~~ выделенном.
SVZ>Не всегда просто и нифига не быстро.

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

SVZ>В моей практике это сложно и геморройно. И еще объемно.

Хороший индиактор того, что тестируемый код пора дробить на части.

SVZ>Как правило это добрая сотня строк, чтобы сварганить минимально-необходимый набор данных. И еще сотня — чтобы проверить результат. Написание одного теста занимало по полдня без перекуров. Работа алгоритма же не сводится к булевскому значению.

И это тоже индикатор

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

Это как раз не проблема

SVZ>Из-за этого у нас прижились рантайм проверки (ассерты) всего и вся и отладчик.

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

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

Здравствуйте, landerhigh, Вы писали:
L>Я вот не понимаю, зачем при разработке новой функциональности вообще может потребоваться отладчик.
последний раз я дебагер запускал по-моему в 2013ом. а последний раз мысль "мм, как удобно иметь дебагер, надо его запустить" была году в 2008ом где-то

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

L>>Я вот не понимаю, зачем при разработке новой функциональности вообще может потребоваться отладчик.
__>последний раз я дебагер запускал по-моему в 2013ом. а последний раз мысль "мм, как удобно иметь дебагер, надо его запустить" была году в 2008ом где-то

Простите, landerhigh и __kot2, чисто интересно:

1. Пишете ли вы код сами?
2. На каком языке программирования/платформе/IDE?

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

__>>последний раз я дебагер запускал по-моему в 2013ом. а последний раз мысль "мм, как удобно иметь дебагер, надо его запустить" была году в 2008ом где-то
D>Простите, landerhigh и __kot2, чисто интересно:

D>1. Пишете ли вы код сами?

Очень много, наверное, пора даже несколько завязывать.

D>2. На каком языке программирования/платформе/IDE?

Плюсы в основном. Под Windows, почти все юниксы, микроконтроллеры, даже vxWorks было дело. Студия, vim, gcc и прочая чертовщина.
Java еще есть под Андроид, там тоже без юнит-тестов не обходится.
Scheme опять же в качестве DSL. С юнит-тестами.

Ты думал, мы теоретики? Наоборот, прожженые циничные практики, сконвертировавшие в свою веру уже пару десятков юных падаванов

Здравствуйте, Dair, Вы писали:
D>1. Пишете ли вы код сами?
конечно, дофига

D>2. На каком языке программирования/платформе/IDE?
C++/Python/Far/mc
иногда студией пользуюсь чисто как текстовым редактором, открывая только отдельные файлы, без проекта

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

D>>1. Пишете ли вы код сами?
L>Очень много, наверное, пора даже несколько завязывать.

Знакомо

D>>2. На каком языке программирования/платформе/IDE?

L>Плюсы в основном. Под Windows, почти все юниксы, микроконтроллеры, даже vxWorks было дело. Студия, vim, gcc и прочая чертовщина.
L>Java еще есть под Андроид, там тоже без юнит-тестов не обходится.

Круто

L>Scheme опять же в качестве DSL. С юнит-тестами.

DSL?..

L>Ты думал, мы теоретики? Наоборот, прожженые циничные практики, сконвертировавшие в свою веру уже пару десятков юных падаванов

Как вступить? Где почитать скрижали, евангелие?

Я просто тут вот прямо сейчас пишу C++/JNI/Java под Android, без отладчика C++ как без рук. Причём платформенно-зависимый код, вне андроида не отладиться.
Коллега как-то умудрился настроить Visual Studio для отладки Android-C++ кода, но у меня OS X и, как следствие, Visual Studio нет.

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

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

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

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

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

L>Вот сходил ты в курилку и придумал, что назовешь свою функцию

L>Ты мне лучше скажи, зачем тут вообще отладчик может понадобиться?

см. ветку "дебагинг vs unit-тесты"

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

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

T>>>А можно метрики проекта? Сколько строк кода, какие библиототеки используете?
__>>2Mb чистого текста в rar-формате

BFE>А сколько в строках? (в студии, в проекте, ctrl+shift+f , во всём солюшене , use regular expressions , найти конец строки, в последней строке — в результатах — будет указано количество строк )

так строки же — не показатель. например, я пишу всегда в стиле

//---
if()
{
      //---
    <...>
    //---
};
//---

что увеличивает количество строк по сравнению с

if(){
  <...>
};

__>>cereal (вот после начала его использования, субъективно, все и начало тормозиться)
BFE>Посмотрел исходники и возник вопрос: а как там с обратной совместимостью по данным? Имя какой-нибудь сереализуемой переменной уже пробовал поменять?

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

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

D>Круто

Да ладно, тут гораздо более крутые люди присутствуют.

L>>Scheme опять же в качестве DSL. С юнит-тестами.
D>DSL?..

Domain-Specific language

L>>Ты думал, мы теоретики? Наоборот, прожженые циничные практики, сконвертировавшие в свою веру уже пару десятков юных падаванов

D>Как вступить? Где почитать скрижали, евангелие?

А вот ч.е.з. Существует куча книг, но мой опыт показывает, что книги сами не объясняют ничего такого, чего разработчик не знал бы сам.
Тут практика нужна. В идеале — практика в присутствии адепта церкви TDD. Если на проекте попадается фанатик вроде меня, то переход происходит относительно плавно и безболезненно, замечено на многих проектах.
Иначе придется ломать привычки, что самому, да без поддержки, намного тяжелее.

D>Я просто тут вот прямо сейчас пишу C++/JNI/Java под Android, без отладчика C++ как без рук. Причём платформенно-зависимый код, вне андроида не отладиться.
D>Коллега как-то умудрился настроить Visual Studio для отладки Android-C++ кода, но у меня OS X и, как следствие, Visual Studio нет.

Хммм... а это интересная идея... Тут можно отдлять тесты логики, которая не зависит от платформы, от платформенно-зависимого кода. Я, честно говоря, удивлюсь, если кто-то не написал еще лончер нативных тестов для андроида.

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

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

A>>

A>># include <stl_all>

A>># include <my_first_file.cpp>
A>># include <my_second_file.cpp>
A>>

T>Только если заранее к этому не готовиться, то такое может совсем не просто оказаться.

Ну да. Я же сказал, что такие фокусы возможны только на своих проектах.

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

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

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

A>>>Что-то ты белаешь неправильно. Это твой проект?

__>>да

A>Тогда ты свободен в экспериментировании. Экспериментируй!

чем и занимаюсь

A>>>Посмотри-подумай, как ты добился таких выдающихся результатов.

__>>думаю, из-за шаблонов

A>Я тоже так думаю, но есть инструмент, а есть умение его применять.

потому и спрашиваю у тех, кто умеет

__>>несжатых у меня собственных файлов (не включая библиотек) — 9Мб

A>Это очень много. Как ты их вообще в голове держишь?

держусь из последних сил

A>У меня текста на порядок меньше и без шаблонов. Тебе действительно столько надо?

да, так выходит (это типа gui для сапра + движок самого объекта управления для возможности проведения эумляции)

A>>>Если правка в одном файле — то я просто не успеваю морнуть.

__>>смотря в каком. если в cpp, который к тому же слабо связан с другими, то конечно, будет быстро

A>Умение писать несвязаннае файлы — отдельное колдунство. От языка не зависит.

ну как же не зависит, если например, зависит от того, можно делать forward декларацию или нет.

A>>>Может быть не нужны тебе эти шаблоны?
A>>>Чё зря страдать-то?

__>>потому что, во-первых, они убирают дублирование кода,

A>По таким фразам видно очень молодого программиста, который пока очень мало книг прочитал.

(с с++ я уже 14 лет знаком и время от времени на нем пишу)

A>Где они убирают дублирование кода? Не дублируй код. Ты что, сотню типов расплодил? Не плоди типы.

stl + boost + cereal как минимум

__>>а во-вторых, речь жла не об этом,а о том, что с++ идет по пути все большей шаблонизации, а тут такая засада

A>Разумеется. Но тут уж твоя свобода воли — хочешь ты за компанию удавиться или нет.

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

A>Давай ещё пару советов дам.

A>1) Ну вот например шаблоны. Зачем они тебе нужны?
A>Шаблоны пошли в С++ мир из STL. Ты используешь именно STL?
A>Вот я пишу на Qt. А там — своя библиотека контейнеров.
A>И почему-то эти шаблоны собираются за секунды.

я не хочу смешивать бюизнес-логику и гуи, потому в бизнес-логике не использую возможнсоти qt

A>2) Можно писать вот так:
A>

A>// главный и единственный компилируемый файл
A># include <stl_all>

A># include <my_first_file.cpp>
A># include <my_second_file.cpp>
A>...
A>

A>В чём тут прикол — компилятор один раз проходит по ужасным файлам STL, а не много раз как в твоём проекте.
A>Но при этом cpp-шники должны быть написаны в особой манере, чтобы их можно было включать таким образом.
A>Но это же твой проект...

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

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

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

__>>спасибо. а что делать с
__>>

__>>1.h
__>>class CFoo
__>>{
__>>public:
__>> struct TFoo{}
__>>};

__>>2.h

__>>void foo(CSubFoo::TFoo& X);
__>>

К>1) Сделать 1.h максимально дешёвым и включать его в 2.h

но он логически не соответствует 2.h (в них лежат отдельные классы объектов)

К>2) Вынести TFoo на уровень неймспейса и предобъявлять (в том числе шаблоны — их тоже можно предобъявлять)

в смысле, можно писать NsFoo::TFoo; где NsFoo — namespace?

К>3) Разнести CFoo на две части, одну лёгкую с определениями зависимых имён — и включать в 2.h, вторую тяжёлую унаследовать от первой и поместить в другой хедер 1impl.h

тоже техническое решение

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

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

да, но и проблем с ними уйма (искать баги работы из-за неперекомпилированного кода — еще та радость)

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

К>>1) Сделать 1.h максимально дешёвым и включать его в 2.h
__>но он логически не соответствует 2.h (в них лежат отдельные классы объектов)

Как же он не соответствует, если 2.h использует объявления из 1.h ?

К>>2) Вынести TFoo на уровень неймспейса и предобъявлять (в том числе шаблоны — их тоже можно предобъявлять)
__>в смысле, можно писать NsFoo::TFoo; где NsFoo — namespace?

Ну, или на уровень неймспейса ::

Главное, что глобальные имена можно предобъявлять сами по себе, а зависимые — только в определении класса. А частичных классов в С++ нет.
Кстати, на всякий случай. Внутри класса можно делать предобъявления — на этом строится и идиома пимпл

///// публичный хедер
class Foo {
  class Impl;
  some_ptr<Impl> impl_;
     // если std::unique_ptr, то все конструкторы и деструктор Foo надо перенести в файл с объявлением Foo::Impl
     // если std::shared_ptr - то лишь код, инициализирующий этот указатель
  .....
};
///// частный файл с реализацией
class Foo::Impl { ..... };

К>>3) Разнести CFoo на две части, одну лёгкую с определениями зависимых имён — и включать в 2.h, вторую тяжёлую унаследовать от первой и поместить в другой хедер 1impl.h
__>тоже техническое решение

Частичные классы для бедных

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

__>>>2Mb чистого текста в rar-формате
BFE>>А сколько в строках? (в студии, в проекте, ctrl+shift+f , во всём солюшене , use regular expressions , найти конец строки, в последней строке — в результатах — будет указано количество строк )
__>так строки же — не показатель. например, я пишу всегда в стиле
так ничего не показатель, просто интересно.

__>>>cereal (вот после начала его использования, субъективно, все и начало тормозиться)
BFE>>Посмотрел исходники и возник вопрос: а как там с обратной совместимостью по данным? Имя какой-нибудь сереализуемой переменной уже пробовал поменять?
__>не копал пока эту тему.
Быть может зря.

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

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

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

__>Не совсем понимаю, как разрабатываются большие проекты на С++? У меня он пока средний — около 2 Mb в архиве, и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти) (а изначально так и вовсе доходило до 40, пока не сделал максимальную развязку). Ситуацию усугубляет повсеместно внедрение шаблонов, которые еще больше увеличивают это время. Все бы ничего, но невозможно же дебаггинг проводить — одно исправление — и опять длительное ожидание перекомпиляции.

Была же недавно подобная тема. Первое, что начнут втирать, так это установка SSD для ускорения перекомпиляции, именно пере, а не компиляции. На что я могу сказать, что прежде чем втыкать SSD не мешало бы купить быстрый компьютер с высокоскоростными портами к которым он будет подключен, а для опытов можно вообще ничего не покупать, а создать RAM диск, то есть диск в оперативной памяти. Далее должна быть включена многопоточная компиляция (количество логических ядер + 1), иначе толку с ядер не будет, и лучше чтобы при одинаковой общей производительности была более высокая производительность на ядро.

__>Из тех мер, что предлагается, самая естественная — forward declaration, но, во-первых, она работает только с классами верхнего уровня (сделать что-то наподoбие class CFoo::CSubFoo; уже нельзя), а во-вторых, и там есть подводные камни: Google C++ Style Guide/Forward_Declarations.

А что насчёт опций компилятора? Там ведь на самом деле можно сделать радикально разные настройки. В одном случае может скомпилироваться библиотечка в мегабайт, а в другом она же но уже в сотни мегабайт. Обработка того же видео, когда показывает фпс, там прямо видно, что в дебаге работает медленней, включаешь релиз и получаешь ускорение. Опять же компиляторов множество, может сменить и попробовать с другим.

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

D>>2. На каком языке программирования/платформе/IDE?

L>Плюсы в основном. Под Windows, почти все юниксы, микроконтроллеры, даже vxWorks было дело. Студия, vim, gcc и прочая чертовщина.
L>Java еще есть под Андроид, там тоже без юнит-тестов не обходится.
L>Scheme опять же в качестве DSL. С юнит-тестами.

L>Ты думал, мы теоретики? Наоборот, прожженые циничные практики, сконвертировавшие в свою веру уже пару десятков юных падаванов

А что для тестов и моков используете? Свой велосипед/gtest/boost/...?

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

L>>Ты думал, мы теоретики? Наоборот, прожженые циничные практики, сконвертировавшие в свою веру уже пару десятков юных падаванов

m2l>А что для тестов и моков используете? Свой велосипед/gtest/boost/...?

Больше гуглевым, конечно.
Но это вопрос привычки больше.

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

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

__>>>>2Mb чистого текста в rar-формате
BFE>>>А сколько в строках? (в студии, в проекте, ctrl+shift+f , во всём солюшене , use regular expressions , найти конец строки, в последней строке — в результатах — будет указано количество строк )
__>>так строки же — не показатель. например, я пишу всегда в стиле
BFE>так ничего не показатель, просто интересно.

наверняка, подсознательно вы этот вопрос связываете с размером проекта. а потому я и говорю, что размер адекватнее оценивать по архиву.
а так 207 299

__>>>>cereal (вот после начала его использования, субъективно, все и начало тормозиться)
BFE>>>Посмотрел исходники и возник вопрос: а как там с обратной совместимостью по данным? Имя какой-нибудь сереализуемой переменной уже пробовал поменять?
__>>не копал пока эту тему.
BFE>Быть может зря.

/cereal/serialization_archives
Out of order loading

The default behavior for all archives is to sequentially load data in the order in which it appears. XML (and JSON) archives support out of order loading, meaning that you can utilize name-value pairs to load data in an order different to that in which it appears in the XML file.

When cereal detects that you are using an NVP to load data from an XML archive, it checks to see if the name matches the next expected (in order) name. If they don't match, cereal will search for the provided name within the current level of nodes. If the name isn't found an exception will be thrown. Once cereal finds and loads the name, it will proceed sequentially from that location until forced to search for another name via an NVP.

...

Important! cereal's default behavior is to load in the order data is presented in an archive. If you use an NVP to load something out of order, cereal will immediately revert to this behavior starting at the node you caused it to jump to.

__>>а зачем менять имя? ясно же, что если она не найдет нужной метки, то будет ругаться.
BFE>Может код изменился, структура хранения поменятся, скажем раньше имя и путь файла хранились отдельно, а теперь — в одной переменной.

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

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

см. выше.

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

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

К>>>1) Сделать 1.h максимально дешёвым и включать его в 2.h
__>>но он логически не соответствует 2.h (в них лежат отдельные классы объектов)

К>Как же он не соответствует, если 2.h использует объявления из 1.h ?

использует и соответствует — разные вещи (это как использовать ключ от квартиры — он соответствует квартире, а не тому, кто им пользуется)

code

L>    Matrix transpose(const Matrix& original);
L>

L>Налил кофе и написал следующие три теста
L>

L>    TEST(transposeMatrix, transposeNegative)
L>    {
L>        // this is more a border case test
L>        ASSERT_TRUE(transpose(emptyMatrix).empty());   // Also checks that we don't crash if matrix is empty
L>    }

L>    TEST(transposeMatrix, transposePositiveSymmetrical)
L>    {
L>        Matrix symmetricalMatrix = ...; // Initialize
L>        Matrix expected = ...; // Manually transposed matrix
L>        ASSERT_EQ(expected, transpose(symmetricalMatrix));
L>        ASSERT_EQ(symmetricalMatrix, transpose(transpose(symmetricalMatrix)));
L>    }

L>    TEST(transposeMatrix, transposePositiveAsymmetrical)
L>    {
L>        Matrix asymmetricalMatrix = ...; // Initialize
L>        Matrix expected = ...; // Manually transposed matrix
L>        ASSERT_EQ(expected, transpose(asymmetricalMatrix ));
L>        ASSERT_EQ(asymmetricalMatrix , transpose(transpose(asymmetricalMatrix )));
L>    }
L>

L>Потом написал собственно код транспонирования.

L>Запустил тест. На все-про-все 5 минут времени и у тебя гораздо более полное покрытие, нежели ты может добиться ручными проверками в отладчике.

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

L>Ты мне лучше скажи, зачем тут вообще отладчик может понадобиться?

ну, например, в коде вы сделали описку — вместо resulted[i][j] = original[j][i] написали resulted[i][j] = original[i][j]Э, или у вас эксепш при вызове функции вылетает (вы неправильно рассчитали размерность транспонированной матрицы)

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

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

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

Эээ... путем нажатия на соответствующие клавиши на клавиатуре в редакторе кода, как же еще?
Я серьезно не понимаю, в чем вопрос.

L>>Ты мне лучше скажи, зачем тут вообще отладчик может понадобиться?

__>ну, например, в коде вы сделали описку — вместо resulted[i][j] = original[j][i] написали resulted[i][j] = original[i][j]Э, или у вас эксепш при вызове функции вылетает (вы неправильно рассчитали размерность транспонированной матрицы)

Соответствующий юнит-тест на это укажет:

TEST(transpose, matrixDimensions)
{
    // это вообще можно сделать в цикле, чтобы проверить все возможные варианты.
    // но обычно не надо, т.к. правильность алгоритма можно индукцией
    Matrix transposed = transpose(getMatrix(1,10));
    ASSERT_EQ(matrix::dimension(10,1), transposed);
}

Если тест ломается, то это практически прямое указание, что именно и где нужно править.

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

Когда кажется, нужно (и далее по тексту).

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

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

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

L>Эээ... путем нажатия на соответствующие клавиши на клавиатуре в редакторе кода, как же еще?
L>Я серьезно не понимаю, в чем вопрос.

а как найдете место, в который нужно поставить курсор, чтобы потом "нажать клавиши на клавиатуре в редакторе кода"?

L>>>Ты мне лучше скажи, зачем тут вообще отладчик может понадобиться?

__>>ну, например, в коде вы сделали описку — вместо resulted[i][j] = original[j][i] написали resulted[i][j] = original[i][j]Э, или у вас эксепш при вызове функции вылетает (вы неправильно рассчитали размерность транспонированной матрицы)

L>Соответствующий юнит-тест на это укажет:
L>

L>TEST(transpose, matrixDimensions)
L>{
L>    // это вообще можно сделать в цикле, чтобы проверить все возможные варианты.
L>    // но обычно не надо, т.к. правильность алгоритма можно индукцией
L>    Matrix transposed = transpose(getMatrix(1,10));
L>    ASSERT_EQ(matrix::dimension(10,1), transposed);
L>}
L>

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

L>Если тест ломается, то это практически прямое указание, что именно и где нужно править.

если у вас тесты на каждые пару строк кода, то согласен (но это нереально).

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

L>Когда кажется, нужно (и далее по тексту).

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

кстати, а что с эксепшенами? вот вылетает у вас он в куске кода — как вы тестируете?

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

— покрывают код настолько плотно, что юниты получаются очень простыми, а поэтому могут быть проанализированы на предмент ошибки и без дебагинга
— тесты настолько специфичные, что по срабатыванию сразу можно сказать, где кроется ошибка в юните

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

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

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

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

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

L>Совершенно верно.

__>>- тесты настолько специфичные, что по срабатыванию сразу можно сказать, где кроется ошибка в юните

L>Совершенно верно.

спасибо. тогда подход понятен.

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

L>С вопросами веры в другой форум. Код обязан быть простым вне зависимости от сложности системы. Сложный для понимания и тестирования код даже специальное название имеет. Говнокод.

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

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

L>А вот это уже пример так называемого вранья.

L>Есть такое правило — If it worth doing, it worth testing. If it not worth testing, why bother doing it in the first place?

это не совсем верно. ведь на деле исходят из соотношения — прибыль от достижения цели/затраты. и в ряде случаев тестируемый код может оказаться намного более затратным, чем прибыль (например,глупо писать тесты для демонстрационного hello world)

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

только в случае, если

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

Здравствуйте, _hum_, Вы писали:
__>это понятно. вот только декомпозиция для тестирования и для написания кода могут противоречить друг другу (иногда даже большую функцию сложно разбить на подфункции из-за отсутствия подходящих самостоятельных концептов для этих фрагментов).
я когда своего брата-школьника учил программированию, то говорил ему так: "пиши код так, будто любая ф-ия, которую ты можешь только вообразить уже существует". если вам нужно провести какие-то мутрные преобразрования, то так и пишиет
x = муторные_преобразования(x, y, z)

не надо пытатья их лепить на месте. и потом вы научитесь давать более разумные имена со временем и даже тесты писать на эти преобразования по отдельности

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

__>Здравствуйте, _hum_, Вы писали:
__>>это понятно. вот только декомпозиция для тестирования и для написания кода могут противоречить друг другу (иногда даже большую функцию сложно разбить на подфункции из-за отсутствия подходящих самостоятельных концептов для этих фрагментов).
__>я когда своего брата-школьника учил программированию, то говорил ему так: "пиши код так, будто любая ф-ия, которую ты можешь только вообразить уже существует". если вам нужно провести какие-то мутрные преобразрования, то так и пишиет
__>x = муторные_преобразования(x, y, z)

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

(иными словами, не x = муторные_преобразования(x, y, z), а x = вычислить_наименьшее_общее_кратное(x, y, z) )

Здравствуйте, _hum_, Вы писали:
__>а нас учили по-другому — сперва нужно выполнить декомпозицию задачи на отдельные имеющие самостоятельное логическое значение подзадачи, и только потом оформлять их в виде функций

__>(иными словами, не x = муторные_преобразования(x, y, z), а x = вычислить_наименьшее_общее_кратное(x, y, z) )
так это все устарело давно
в смысле, идея-то неплоха, но если "ничего не выделяется", то не надо пилить это в столбик

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

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

Qt хорошо следят за модульностью. И forward declaration по максимуму используют. Так что да, не боюсь (думаю, как и nen777w).

С использованием IncrediBuild-а больше всего времени занимает линковка, а не компиляция.

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

A>2) Можно писать вот так:
A>

A>// главный и единственный компилируемый файл
A># include <stl_all>

A># include <my_first_file.cpp>
A># include <my_second_file.cpp>
A>...
A>

A>В чём тут прикол — компилятор один раз проходит по ужасным файлам STL, а не много раз как в твоём проекте.
A>Но при этом cpp-шники должны быть написаны в особой манере, чтобы их можно было включать таким образом.
A>Но это же твой проект...

Это называется "unity build". Некоторые системы сборки умеют это делать автоматически. Использовал когда-то с CMake — cotire.
Если правильно это дело настраивать, то можно добиться очень хорошей производительности совместно с распределёнными системами сборки.

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

__>>>>>2Mb чистого текста в rar-формате
BFE>>>>А сколько в строках? (в студии, в проекте, ctrl+shift+f , во всём солюшене , use regular expressions , найти конец строки, в последней строке — в результатах — будет указано количество строк )
__>>>так строки же — не показатель. например, я пишу всегда в стиле
BFE>>так ничего не показатель, просто интересно.

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

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

__>а так 207 299
20 минут для такого проекта на не быстрой машине — это нормально.

	Скрытый текст
	__> __>/cereal/serialization_archives __>Out of order loading __>The default behavior for all archives is to sequentially load data in the order in which it appears. XML (and JSON) archives support out of order loading, meaning that you can utilize name-value pairs to load data in an order different to that in which it appears in the XML file. __>When cereal detects that you are using an NVP to load data from an XML archive, it checks to see if the name matches the next expected (in order) name. If they don't match, cereal will search for the provided name within the current level of nodes. If the name isn't found an exception will be thrown. Once cereal finds and loads the name, it will proceed sequentially from that location until forced to search for another name via an NVP. __>... __>Important! cereal's default behavior is to load in the order data is presented in an archive. If you use an NVP to load something out of order, cereal will immediately revert to this behavior starting at the node you caused it to jump to. Что ж, вполне ожидаемо...

__>>>а зачем менять имя? ясно же, что если она не найдет нужной метки, то будет ругаться.
BFE>>Может код изменился, структура хранения поменятся, скажем раньше имя и путь файла хранились отдельно, а теперь — в одной переменной.
__>я все ранво ен понимаю. это же теоретически невозможно — чтобы сериализованные со старыми именами данные смогли загрузиться в формате, предполагающем новые.
MS Word поддерживает обратную совместимость с файлами забытого года, так что всё возможно не только теоретически, но и практически. Впрочем, не все так делают.

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

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

__>> а потому я и говорю, что размер адекватнее оценивать по архиву.
BFE>Это смотря что вы оцениваете. Скорость компиляции мало коррелирует с размером архива исходников. (К тому же с rar архивом, в котором есть уйма опций влияющих на размер архива)

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

__>>а так 207 299
BFE>20 минут для такого проекта на не быстрой машине — это нормально.

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

__>>>>а зачем менять имя? ясно же, что если она не найдет нужной метки, то будет ругаться.
BFE>>>Может код изменился, структура хранения поменятся, скажем раньше имя и путь файла хранились отдельно, а теперь — в одной переменной.
__>>я все ранво ен понимаю. это же теоретически невозможно — чтобы сериализованные со старыми именами данные смогли загрузиться в формате, предполагающем новые.
BFE>MS Word поддерживает обратную совместимость с файлами забытого года, так что всё возможно не только теоретически, но и практически. Впрочем, не все так делают.

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

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

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

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

SaZ>Qt хорошо следят за модульностью. И forward declaration по максимуму используют. Так что да, не боюсь (думаю, как и nen777w).

qt — это не самостоятельный язык, так что следи не следи, а все равно упрется в ограничения с++ (если только не расширит возможности moc-а)

SaZ>С использованием IncrediBuild-а больше всего времени занимает линковка, а не компиляция.

один черт — трата времени впустую.

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

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

__>>>а так 207 299
BFE>>20 минут для такого проекта на не быстрой машине — это нормально.
__>это де-факто может быть нормально, но ненормально с точки зрения разработки программ в 21 веке (сколько времени тратится впустую)
Меня не напрягает. По сравнению с обдумыванием время компиляции занимает совсем не много.

__>это поддержка на уровне программы, а не библиотеки (откуда библиотека может знать, как вы поменяли там свой формат, и что чему теперь соответствует)
Хорошая библиотека должна предоставлять API для обработки такой ситуации.

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

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

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

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

__>>>>а так 207 299
BFE>>>20 минут для такого проекта на не быстрой машине — это нормально.
__>>это де-факто может быть нормально, но ненормально с точки зрения разработки программ в 21 веке (сколько времени тратится впустую)
BFE>Меня не напрягает. По сравнению с обдумыванием время компиляции занимает совсем не много.

а что насчет дебагинга — одна правка, и жди еще 20 минут?

__>>это поддержка на уровне программы, а не библиотеки (откуда библиотека может знать, как вы поменяли там свой формат, и что чему теперь соответствует)
BFE>Хорошая библиотека должна предоставлять API для обработки такой ситуации.

вы хоть одну такую встречали?

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

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

__>а что насчет дебагинга — одна правка, и жди еще 20 минут?
дебагинг нужен в основном для исправления ошибок в чужом коде. Для нахождения своей ошибки обычно достаточно посмотреть на поведение программы, если этого не хватает, то достаточно посмотреть на лог. А если не хватает лога, то запустить debug версию до первого ассёрта.

__>>>это поддержка на уровне программы, а не библиотеки (откуда библиотека может знать, как вы поменяли там свой формат, и что чему теперь соответствует)
BFE>>Хорошая библиотека должна предоставлять API для обработки такой ситуации.
__>вы хоть одну такую встречали?
Нет. Впрочем, я не использую сериализацию по концептуальным соображениям, поэтому не искал библиотек подобного рода.

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

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

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

по моим ощущениям тормозит все-таки из-за темплейтов (очень резко увеличилось врем, когда стал использовать cereal)

__>>а что насчет дебагинга — одна правка, и жди еще 20 минут?
BFE>дебагинг нужен в основном для исправления ошибок в чужом коде. Для нахождения своей ошибки обычно достаточно посмотреть на поведение программы, если этого не хватает, то достаточно посмотреть на лог. А если не хватает лога, то запустить debug версию до первого ассёрта.

не для нахождения, а для исправления. ну вот влеетели в асерт, нашли в чем дело, исправили, и дальше 20 минут ожидания следующей проверки

__>>>>это поддержка на уровне программы, а не библиотеки (откуда библиотека может знать, как вы поменяли там свой формат, и что чему теперь соответствует)
BFE>>>Хорошая библиотека должна предоставлять API для обработки такой ситуации.
__>>вы хоть одну такую встречали?
BFE>Нет. Впрочем, я не использую сериализацию по концептуальным соображениям, поэтому не искал библиотек подобного рода.

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

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

__>по моим ощущениям тормозит все-таки из-за темплейтов (очень резко увеличилось врем, когда стал использовать cereal)
А не факт, что всё это из-за шаблонности (но вполне может быть что и из-за неё). Добавление такой библиотеки требует включение большого числа хедеров для каждого класса, где эта библиотека используется.
Только в cereal.hpp девять включений системных заголовков:
#include <type_traits>
#include <string>
#include <memory>
#include <unordered_map>
#include <unordered_set>
#include <vector>
#include <cstddef>
#include <cstdint>
#include <functional>

__>не для нахождения, а для исправления. ну вот влеетели в асерт, нашли в чем дело, исправили, и дальше 20 минут ожидания следующей проверки
Ну да. Следующая проверка минут через 20, а следующий ассерт дня через 2 если писать новую функциональность.

BFE>>Нет. Впрочем, я не использую сериализацию по концептуальным соображениям, поэтому не искал библиотек подобного рода.
__>а что значит "по концептуальным соображениям"?
В данном случае это означает, что формат данных должен быть отделён и независим от формата используемых для их обработки структур.

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

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

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

__>>не для нахождения, а для исправления. ну вот влеетели в асерт, нашли в чем дело, исправили, и дальше 20 минут ожидания следующей проверки
BFE>Ну да. Следующая проверка минут через 20, а следующий ассерт дня через 2 если писать новую функциональность.

да, но при написании новой функциональности разве не приходится править по несколькую ошибок? или вы достигли того уровня, что у вас они если и встречаются, тоне более одной на новую функциональность?

BFE>>>Нет. Впрочем, я не использую сериализацию по концептуальным соображениям, поэтому не искал библиотек подобного рода.
__>>а что значит "по концептуальным соображениям"?
BFE>В данном случае это означает, что формат данных должен быть отделён и независим от формата используемых для их обработки структур.

это да, согласен. но так проще и быстрее. да и ошибок меньше.

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

аа, ну тогда да, можно и покритиковать

BFE>Но надо заметить, что некоторые используют сереализацию для создания сообщений обмена по сети. Я считаю это концептуально не верным и не использую.

а какой вы предпочитаете?

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

__>>>не для нахождения, а для исправления. ну вот влеетели в асерт, нашли в чем дело, исправили, и дальше 20 минут ожидания следующей проверки
BFE>>Ну да. Следующая проверка минут через 20, а следующий ассерт дня через 2 если писать новую функциональность.

__>да, но при написании новой функциональности разве не приходится править по несколькую ошибок? или вы достигли того уровня, что у вас они если и встречаются, тоне более одной на новую функциональность?
На прошлой неделе писал новую функциональность — пульт дистанционного управления. Совершил следующие ошибки:
1. перепутал поле маски с полем смещения — заметил при просмотре записанного файла — нашёл просмотром кода записи файла
2. вывод в лог одного и того же значения вместо двух разных — заметил при тестировании на некорректных входных данных — просто посмотрел в коде, что я вывожу
3. использовал unsigned вместо signed для изменения позиции слайдера — заметил при тестировании слайдера — ещё до просмотра кода знал, что скорее всего ошибка в типе (не первый раз)
4. удалял дефолтный список кнопок консоли при загрузке старого конфигурационного файла — заметил при тестировании (нет реакции на кнопки) — знал где искать, так как в логе не было вывода о сконфигурированных кнопках.
Для этих целей дебагер не потребовался ни разу.

Дебагер использовал для отладки чужого кода — код писали электронщики для микроконтроллера и там, как это обычно у них бывает и не изменилось за 20 лет, всё перемешано, имена — короткие, переменные — глобальные, функции на прерываниях, инициализация memset'ом, длины массивов не выверены, часть кода не работает, протокол не соблюдён, на переполнения переменных никто внимания не обращает и, разумеется, моя любимая не инициализированная глобальная переменная int i;.

BFE>>Но надо заметить, что некоторые используют сереализацию для создания сообщений обмена по сети. Я считаю это концептуально не верным и не использую.
__>а какой вы предпочитаете?
Протокол сначала описывается в документе, а код пишется потом с учётом того, что протокол может меняться в следующих версиях. Ничего особенного.

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

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

__>>>>не для нахождения, а для исправления. ну вот влеетели в асерт, нашли в чем дело, исправили, и дальше 20 минут ожидания следующей проверки
BFE>>>Ну да. Следующая проверка минут через 20, а следующий ассерт дня через 2 если писать новую функциональность.

__>>да, но при написании новой функциональности разве не приходится править по несколькую ошибок? или вы достигли того уровня, что у вас они если и встречаются, тоне более одной на новую функциональность?
BFE>На прошлой неделе писал новую функциональность — пульт дистанционного управления. Совершил следующие ошибки:
BFE>1. перепутал поле маски с полем смещения — заметил при просмотре записанного файла — нашёл просмотром кода записи файла

исправили и +20 минут ожидания

BFE>2. вывод в лог одного и того же значения вместо двух разных — заметил при тестировании на некорректных входных данных — просто посмотрел в коде, что я вывожу

исправили и +20 минут ожидания

BFE>3. использовал unsigned вместо signed для изменения позиции слайдера — заметил при тестировании слайдера — ещё до просмотра кода знал, что скорее всего ошибка в типе (не первый раз)

исправили и +20 минут ожидания

BFE>4. удалял дефолтный список кнопок консоли при загрузке старого конфигурационного файла — заметил при тестировании (нет реакции на кнопки) — знал где искать, так как в логе не было вывода о сконфигурированных кнопках.

исправили и +20 минут ожидания

итого, почти полтора часа потраченного впустую времени

BFE>Для этих целей дебагер не потребовался ни разу.

дебагинг != работа под дебагером. дебагинг (по крайней мере в том смысле , что я вкладывал) — устранение ошибок.

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

__>итого, почти полтора часа потраченного впустую времени
Это много для одной недели?

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

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

__>>итого, почти полтора часа потраченного впустую времени
BFE>Это много для одной недели?

если вы реализуете только одну функциональность в неделю, то, может, и нет. у меня просто другая ситуация.

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

T>Вот я по то же. black-box тестирование алгоритма может сказать только то, что он в некоторых случаях работает правильно или нет.
T>Если алгоритм достаточно сложен, и мы знаем, что он неисправен, далеко не всегда тесты помогут выявить ошибку.

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

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

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

T>>Вот я по то же. black-box тестирование алгоритма может сказать только то, что он в некоторых случаях работает правильно или нет.
T>>Если алгоритм достаточно сложен, и мы знаем, что он неисправен, далеко не всегда тесты помогут выявить ошибку.

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

ну вот очередной пример: как обнаружить юнит-тестами эту ошибку

 for(uint8_t i = 10; i >= 0; --i){<...>};

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

__>ну вот очередной пример: как обнаружить юнит-тестами эту ошибку
__>

__> for(uint8_t i = 10; i >= 0; --i){<...>};
__>

Такая ошибка обрануживается на code review.
Впрочем, зависание теста тоже покажет.

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

__>ну вот очередной пример: как обнаружить юнит-тестами эту ошибку
__>

__> for(uint8_t i = 10; i >= 0; --i){<...>};
__>

__>?

Тест не будет пройден.
Ну и вообще, согласно последнему постановлению ВЦСПС этот цикл должен быть записан так

Здравствуйте, _hum_, Вы писали:
__>ну вот очередной пример: как обнаружить юнит-тестами эту ошибку
__>

__> for(uint8_t i = 10; i >= 0; --i){<...>};
__>

__>?
да, в общем, можно.
два теста — проверка кол-ва итераций (что 10) и что когда итерации две, то и код вызывается 2 раза

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

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

__>>ну вот очередной пример: как обнаружить юнит-тестами эту ошибку
__>>

__>> for(uint8_t i = 10; i >= 0; --i){<...>};
__>>

L>Такая ошибка обрануживается на code review.

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

L>Впрочем, зависание теста тоже покажет.

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

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

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

uint, >=0 и --, использованные в одном for, в моем моску вызывают хардверное прерывание.

L>>Впрочем, зависание теста тоже покажет.
__>это если есть зависание, а если внутри цикла стоит брейк, то будем долго и упорно ревьювить, где ж у нас что не так работает.

При покрытии всех возможных сценариев наличие зависания вылезет при первом же прогоне тестов.

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

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

__>>ну вот очередной пример: как обнаружить юнит-тестами эту ошибку
__>>

__>> for(uint8_t i = 10; i >= 0; --i){<...>};
__>>

__>>?

BFE>Тест не будет пройден.

и что?

как понять, в чем ошибка, не пошагав по циклу и не увидев, что он делает лишние итерации?

BFE>Ну и вообще, согласно последнему постановлению ВЦСПС этот цикл должен быть записан так:
C>Стандартная идиома:

C>

C>for (unsigned i = n; i --> 0 ;)
C>    std::cout << i << std::endl;
C>

это плохо, потому что все равно делается декремент беззнаковой переменной в нуле (хоть и после ее использования). кстати, как там по стандарту — это UB или нет?

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

__>Здравствуйте, _hum_, Вы писали:
__>>ну вот очередной пример: как обнаружить юнит-тестами эту ошибку
__>>

__>> for(uint8_t i = 10; i >= 0; --i){<...>};
__>>

__>>?
__>да, в общем, можно.
__>два теста — проверка кол-ва итераций (что 10) и что когда итерации две, то и код вызывается 2 раза

то есть, на каждый цикл пишется тест?

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

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

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

L>uint, >=0 и --, использованные в одном for, в моем моску вызывают хардверное прерывание.

согласен. выглядит ужасно.

L>>>Впрочем, зависание теста тоже покажет.
__>>это если есть зависание, а если внутри цикла стоит брейк, то будем долго и упорно ревьювить, где ж у нас что не так работает.

L>При покрытии всех возможных сценариев наличие зависания вылезет при первом же прогоне тестов.

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

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

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

__>вот-вот "всех возможных". а это возможно только для очень простых ситуаций.

А код и должен сводить эти ситуации к простым.

__>к тому же вы не можете доказать, что покрыли все возможные сценарии, а значит, даже если тест пройден, не факт, что все равботает правильно.

Доказать? Гхм, я этот код написал, я знаю, какие сценарии мне нужно покрыть.

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

Нисколько, это происходит автоматически.

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

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

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

__>>вот-вот "всех возможных". а это возможно только для очень простых ситуаций.

L>А код и должен сводить эти ситуации к простым.

всегда ли это возможно... вот в чем вопрос

__>>к тому же вы не можете доказать, что покрыли все возможные сценарии, а значит, даже если тест пройден, не факт, что все равботает правильно.

L>Доказать? Гхм, я этот код написал, я знаю, какие сценарии мне нужно покрыть.

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

а вот если бы вы могли доказать, что все сценарии учли, то такая ситуация бы была невозможна.

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

L>Нисколько, это происходит автоматически.

это неправда. создание тестов — алгоритмически неразрешимая задача.

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

L>>А код и должен сводить эти ситуации к простым.
__>всегда ли это возможно... вот в чем вопрос

Ээээ, всегда.

__>>>к тому же вы не можете доказать, что покрыли все возможные сценарии, а значит, даже если тест пройден, не факт, что все равботает правильно.

L>>Доказать? Гхм, я этот код написал, я знаю, какие сценарии мне нужно покрыть.

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

Ничего никто чесать не будет. Сценарии покрыты на 100% — значит проблема в другом месте. Разматываем клубок, находим виновника.
В этом-то и соль юнит-тестов — отдаешь код джуну, он что-то меняет, что ломает юнит-тест в другом модуле. Обнаруживается это сразу и исправляется тоже сразу.

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

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

Не надо никакого пошагового выполнения.

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

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

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

BFE>Здравствуйте, _hum_
C>>>Стандартная идиома:

C>>>

C>>>for (unsigned i = n; i --> 0 ;)
C>>>    std::cout << i << std::endl;
C>>>

__>>это плохо, потому что все равно делается декремент беззнаковой переменной в нуле (хоть и после ее использования). кстати, как там по стандарту — это UB или нет?

BFE>По стандарту всё корректно: ни переполнения, ни UB. Для беззнаковых, после нуля следует максимальное для данного типа число.

ну тогда приму к сведению, спасибо.

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

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

L>>>А код и должен сводить эти ситуации к простым.
__>>всегда ли это возможно... вот в чем вопрос

L>Ээээ, всегда.

__>>>>к тому же вы не можете доказать, что покрыли все возможные сценарии, а значит, даже если тест пройден, не факт, что все равботает правильно.

L>>>Доказать? Гхм, я этот код написал, я знаю, какие сценарии мне нужно покрыть.

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

L>Ничего никто чесать не будет. Сценарии покрыты на 100% — значит проблема в другом месте.

"Сценарии покрыты на 100%"
это примерно как заявить — код написан на 100% без ошибок. "ваши доказательства?"

L>В этом-то и соль юнит-тестов — отдаешь код джуну, он что-то меняет, что ломает юнит-тест в другом модуле. Обнаруживается это сразу и исправляется тоже сразу.

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

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

L>Еще раз напомню — с вопросами веры в другой форум.

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

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

"Сценарии покрыты на 100%"
__>это примерно как заявить — код написан на 100% без ошибок. "ваши доказательства?"
ну кодом же вы как-то покрываете сценарии исполнения?

__>при чем тут вера, если это чисто математический факт: из теоремы райса вытекает, что не существует даже алгоритма, позволяющего проверить, покрывают ваши тесты 100% сценариев ошибок или нет, не говоря уже об автоматической генерации таких тестов.
вот есть Вася и Петя. и дали им задачу — написать автоисправление русского текста. задачи хитрая и четкого решения не имеющая.

Вася что-то написал, приносит код, мы открываем папочку с тестами и видим
чяща -> чаща
жыр -> жир
несделал -> не сделал

думаем, какой Вася молодец. вот мы сразу поняли, что кодом поддерживается, нам даже лезть в него не надо

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

вы можете выбрать какой код развивать. и какой будете — Васин, который понятно что делает или Петин, который вообще непонятно что делает?

при этом, понимаете, Вася создал огромную ценность в виде минимальных некорректных примеров разных классов, а Петя просто проторчал в дебагере, выискивая какие-то опечатки, по всей видимости, еще и не все найденные. есть желание заниматься поиском его опечаток?

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

__>Не совсем понимаю, как разрабатываются большие проекты на С++? У меня он пока средний — около 2 Mb в архиве, и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти) ...
__>Разработчики языка вообще в эту сторону смотрят?
Компиляция больших с++ проектов это решенная инженерная задача. Просто, никто не делится решениями.
Для интерактивной сборки разработчики используют 1-2 конфигурации. В них
а) все разбито на бинарные модули (убирает линковку всего вместе), даже если финальная сборка это 1 исполняемый файл;
б) в каждом модуле есть forward declarations где разрешен только небольшой набор типов.
в) в каждом модуле есть pch
г) автоматически мелкие cpp файлы объединяются группами (unity build), в теме был пример как это делать руками;
д) компиляция запускается на кластере из множества машин (даже если это только машины коллег это все равно дает много);
е) используется кеш с результатами компиляции (заполняется чистым билдом ночью).
...

в домашних условиях обычно никто не идет дальше первых трех пунктов и просто дозакупают железо тк "(на двухядерном 2ГГц и 4Г памяти)" бороться за время компиляции несерьезно.
Настоящие неудобства большие/сложные проекты приносят, когда надо туда заливать большие изменения а не при компиляции =)

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

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

__>>Не совсем понимаю, как разрабатываются большие проекты на С++? У меня он пока средний — около 2 Mb в архиве, и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти) ...
__>>Разработчики языка вообще в эту сторону смотрят?
SD>Компиляция больших с++ проектов это решенная инженерная задача. Просто, никто не делится решениями.
SD>Для интерактивной сборки разработчики используют 1-2 конфигурации. В них

	текст
	SD>а) все разбито на бинарные модули (убирает линковку всего вместе), даже если финальная сборка это 1 исполняемый файл; SD>б) в каждом модуле есть forward declarations где разрешен только небольшой набор типов. SD>в) в каждом модуле есть pch SD>г) автоматически мелкие cpp файлы объединяются группами (unity build), в теме был пример как это делать руками; SD>д) компиляция запускается на кластере из множества машин (даже если это только машины коллег это все равно дает много); SD>е) используется кеш с результатами компиляции (заполняется чистым билдом ночью). SD>...

ну так, это же "ужас-ужас-ужас" — превращать подготовку к компиляции в отдельную инженерную задачу. эдак со временем стоит ожидать появления "специалиста по предкомпиляционной подготовке с++ проекта".

SD>в домашних условиях обычно никто не идет дальше первых трех пунктов и просто дозакупают железо тк "(на двухядерном 2ГГц и 4Г памяти)" бороться за время компиляции несерьезно.

я ж вам при вел пример — в "домашних условиях" на не слишком большом проекте на перекомпиляцию тратится 20-40 минут, что при разработке — непозволительная потеря времени.

SD>Настоящие неудобства большие/сложные проекты приносят, когда надо туда заливать большие изменения а не при компиляции =)

по-моему, эти проблемы ортогональны

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

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

простите, так вася тестировщик или девелопер?

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

__>>

"Сценарии покрыты на 100%"
__>>это примерно как заявить — код написан на 100% без ошибок. "ваши доказательства?"
__>ну кодом же вы как-то покрываете сценарии исполнения?

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

__>>при чем тут вера, если это чисто математический факт: из теоремы райса вытекает, что не существует даже алгоритма, позволяющего проверить, покрывают ваши тесты 100% сценариев ошибок или нет, не говоря уже об автоматической генерации таких тестов.
__>вот есть Вася и Петя. и дали им задачу — написать автоисправление русского текста. задачи хитрая и четкого решения не имеющая.

__>Вася что-то написал, приносит код, мы открываем папочку с тестами и видим
__>чяща -> чаща
__>жыр -> жир
__>несделал -> не сделал

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

__>Петя отдает код и говорит "ну и задачку же вы мне подсунули". короче, говорит, я там что-то написал, я проверил у себя на компе там, я ему тест создал, просто опечаток понараскидал, он нашел 70%. улучшить можно, но пока не знаю как.
__>вы можете выбрать какой код развивать. и какой будете — Васин, который понятно что делает или Петин, который вообще непонятно что делает?
Действительно, у Васи всё понятно: опечатка — исправление. А у Пети не пойми что, какой-то нечёткий поиск, вероятности, проценты...

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

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

Здравствуйте, B0FEE664, Вы писали:
BFE>Бывает так, что в сложных, развитых проектах некоторые части кода не вызываются никогда за время эксплуатации (даже при массовом использовании).
и этот код должен быть удален

__>>вы можете выбрать какой код развивать. и какой будете — Васин, который понятно что делает или Петин, который вообще непонятно что делает?
BFE>Действительно, у Васи всё понятно: опечатка — исправление. А у Пети не пойми что, какой-то нечёткий поиск, вероятности, проценты...
ну то есть берем код Пети?

BFE>Ну, серьёзно: на практике есть классы задач, которые никак не покрываются тестами (классический пример — числа неограниченной длины) или же написание тестов превосходит по затратам написание кода на несколько порядков — это, как правило, задачи связанные с реальным миром: интерфейс, реалтайм системы, время, перегрузка входными данными от датчиков...
когда у вас не только Вася и Петя, а команда человек 20, вносящая хаотичные правки, то вам уже на самом деле без разницы на демагогию про что можно, а что нельзя, для вас написание юнит тестов будет единственным способом релизить проект во вменяемом состоянии. а по интересному стечению обстоятельств именно именитые говнокодеры будут ныть, что тесты писать долго и д-но будут выдавать очень запутанные невероятно гигантские тесты, которые еще и ничего не тестируют. потому что тестировать говнокод очень сложно.

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

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

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

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

__>>>вы можете выбрать какой код развивать. и какой будете — Васин, который понятно что делает или Петин, который вообще непонятно что делает?
BFE>>Действительно, у Васи всё понятно: опечатка — исправление. А у Пети не пойми что, какой-то нечёткий поиск, вероятности, проценты...
__>ну то есть берем код Пети?

Может — да, а может и нет. Выбор может быть сделан по другому критерию.

BFE>>Ну, серьёзно: на практике есть классы задач, которые никак не покрываются тестами (классический пример — числа неограниченной длины) или же написание тестов превосходит по затратам написание кода на несколько порядков — это, как правило, задачи связанные с реальным миром: интерфейс, реалтайм системы, время, перегрузка входными данными от датчиков...
__>когда у вас не только Вася и Петя, а команда человек 20, вносящая хаотичные правки, то вам уже на самом деле без разницы на демагогию про что можно, а что нельзя, для вас написание юнит тестов будет единственным способом релизить проект во вменяемом состоянии. а по интересному стечению обстоятельств именно именитые говнокодеры будут ныть, что тесты писать долго и д-но будут выдавать очень запутанные невероятно гигантские тесты, которые еще и ничего не тестируют. потому что тестировать говнокод очень сложно.
Тесты, как средство управления проектом — ok, а вот как средство разработки — подходит не для всех задач.

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

__>Здравствуйте, _hum_, Вы писали:
__>>>при этом, понимаете, Вася создал огромную ценность в виде минимальных некорректных примеров разных классов, а Петя просто проторчал в дебагере, выискивая какие-то опечатки, по всей видимости, еще и не все найденные. есть желание заниматься поиском его опечаток?
__>>простите, так вася тестировщик или девелопер?

__>вообще, этот подход с тестами стал вырисовываться в начале 2000ых — пришло наверное даже их спортивного программирования, но адаптированного к реальному миру.
__>помню, году в 2005ом были предложения у нас по проекту так сделать, но непонятно было как наш говнокод переписывать. самые прошаренные именно тогда и стали переходить и даже тормозной микрософт, позже всех, 3 года назад перешел на эту схему.
__>почти все сильные программисты, с которыми я когда-то работал по разны причинах, в разные компании, свалили из России. и вот остались по всей видимости те, кто остает от общего мирового тренда в разработке, лет, уже получается, на 10. это меня, конечно, удивило очень сильно, прямо мега-открытие. когда люди в 2016ом году говорят про девелоперов и тестеров, размышляют о преимуществах дебагера или о невозможности написания тестов — это сильно!

это сильная заявка в мировые аутсайдеры разработки

столько текста, и только одни эмоции. вы точно профессионал ?

если все такие отсталые, зачем же до сих пор идет поддержка и усовершенствование дебагера?

ну и, в конце-концов, читаем Test-driven_development#Limitations и убеждаемся, что не все так гладко, как в песне поется.

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

L>>Еще раз напомню — с вопросами веры в другой форум.

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

Ээээ, ты опять не понял смысла юнит-тестирования и TDD в частности.
Юнит-тесты не являются black-box тестами и в общем случае они не верифицируют правильность алгоритма.
Юнит-тесты верифицируют, что поведение юнита соответствует ожидаемому в определенных условиях. Хорошие юнит тесты покрывают все возможные типы условий. Когда все граничные (все виды граничных) условий покрыты, а у хорошего тестируемого кода этих видов крайне мало, то верификация алгоритма может быть проведена по индукции на основании прохождения тестов на ограниченном наборе данных.
На практике это означает, что достаточно того, что написаны тесты, которые проверяют поведение вокруг всех ветвлений, переполнения и т.п., и на некоем ограниченном наборе валидных данных.

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

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

__>ну и, в конце-концов, читаем Test-driven_development#Limitations и убеждаемся, что не все так гладко, как в песне поется.

Подавляющее большинство разработчиков в своей жизни столкнутся лишь с одним ограничением TDD: нежелание (неумение) вести разработку в стиле TDD сводит все его преимущества на нет и даже хуже.

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

BFE>реалтайм системы, время, перегрузка входными данными от датчиков...

прекрасно тестируется.
Только это уже не юнит-тесты.

Время, кстати, тоже тестируется, если выбраны правильные уровни абстракции.

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

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

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

Такой код может и должен быть протестирован.

BFE>Тесты, как средство управления проектом — ok, а вот как средство разработки — подходит не для всех задач.

Не подходит для крайне малого домена задач.

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

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

__>>ну и, в конце-концов, читаем Test-driven_development#Limitations и убеждаемся, что не все так гладко, как в песне поется.

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

Ой-ли. А

Test-driven development does not perform sufficient testing in situations where full functional tests are required to determine success or failure, due to extensive use of unit tests.[21] Examples of these are user interfaces, programs that work with databases, and some that depend on specific network configurations.

Unit tests created in a test-driven development environment are typically created by the developer who is writing the code being tested. Therefore, the tests may share blind spots with the code: if, for example, a developer does not realize that certain input parameters must be checked, most likely neither the test nor the code will verify those parameters. Another example: if the developer misinterprets the requirements for the module he is developing, the code and the unit tests he writes will both be wrong in the same way. Therefore, the tests will pass, giving a false sense of correctness.

A high number of passing unit tests may bring a false sense of security, resulting in fewer additional software testing activities, such as integration testing and compliance testing.

Ну и, наконец, из Software_testing:

Testing tools

Program testing and fault detection can be aided significantly by testing tools and debuggers. Testing/debug tools include features such as:

Program monitors, permitting full or partial monitoring of program code including:
Instruction set simulator, permitting complete instruction level monitoring and trace facilities
Hypervisor, permitting complete control of the execution of program code including:-
Program animation, permitting step-by-step execution and conditional breakpoint at source level or in machine code
Code coverage reports
Formatted dump or symbolic debugging, tools allowing inspection of program variables on error or at chosen points
Automated functional GUI testing tools are used to repeat system-level tests through the GUI
Benchmarks, allowing run-time performance comparisons to be made
Performance analysis (or profiling tools) that can help to highlight hot spots and resource usage

Some of these features may be incorporated into a single composite tool or an Integrated Development Environment (IDE).

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

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

L>>>Еще раз напомню — с вопросами веры в другой форум.

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

L>Ээээ, ты опять не понял смысла юнит-тестирования и TDD в частности.
L>Юнит-тесты не являются black-box тестами и в общем случае они не верифицируют правильность алгоритма.
L>Юнит-тесты верифицируют, что поведение юнита соответствует ожидаемому в определенных условиях. Хорошие юнит тесты покрывают все возможные типы условий. Когда все граничные (все виды граничных) условий покрыты, а у хорошего тестируемого кода этих видов крайне мало, то верификация алгоритма может быть проведена по индукции на основании прохождения тестов на ограниченном наборе данных.
L>На практике это означает, что достаточно того, что написаны тесты, которые проверяют поведение вокруг всех ветвлений, переполнения и т.п., и на некоем ограниченном наборе валидных данных.

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

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

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

BFE>>реалтайм системы, время, перегрузка входными данными от датчиков...
L>прекрасно тестируется.
L>Только это уже не юнит-тесты.
Ну как "прекрасно". Может оказаться, что для этого надо затратить труд превосходящий по времени написание приложения.

L>Время, кстати, тоже тестируется, если выбраны правильные уровни абстракции.
Не совсем понятно, как вам помогут уровни абстракции и причём они тут. Багов связанных со временем очень много, они весьма разнообразны и встречаются во всех системах. Apple, MS и Unix страдают ими перманентно. Думаете многие готовы к проблеме 2038-ого года или хотя бы задумываются/знают о ней? А ведь осталось каких-нибудь 22 года.

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

BFE>>>>Бывает так, что в сложных, развитых проектах некоторые части кода не вызываются никогда за время эксплуатации (даже при массовом использовании).
__>>>и этот код должен быть удален
BFE>>Нет, не должен. Это, например, может быть код обрабатывающий ошибку записи данных на диск.
L>Такой код может и должен быть протестирован.
Может и должен. Что не отменяет того факта, что за всё время эксплуатации он никогда не будет вызван.
Кстати, можете предложить не инвазивный способ тестирования?

BFE>>Тесты, как средство управления проектом — ok, а вот как средство разработки — подходит не для всех задач.
L>Не подходит для крайне малого домена задач.
Да ладно! Есть большие классы задач, которые сложно или крайне сложно протестировать. Давайте, предложите тест для проверки отрисовки, скажем, кнопки.

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

L>>Только это уже не юнит-тесты.
BFE>Ну как "прекрасно". Может оказаться, что для этого надо затратить труд превосходящий по времени написание приложения.

Вот у нас, почему-то, не оказалось. Мы, наверное, что-то делаем неправильно.

L>>Время, кстати, тоже тестируется, если выбраны правильные уровни абстракции.
BFE>Не совсем понятно, как вам помогут уровни абстракции и причём они тут. Багов связанных со временем очень много, они весьма разнообразны и встречаются во всех системах. Apple, MS и Unix страдают ими перманентно. Думаете многие готовы к проблеме 2038-ого года или хотя бы задумываются/знают о ней? А ведь осталось каких-нибудь 22 года.

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

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

L>>Такой код может и должен быть протестирован.
BFE>Может и должен. Что не отменяет того факта, что за всё время эксплуатации он никогда не будет вызван.

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

BFE>Кстати, можете предложить не инвазивный способ тестирования?

Код рефакторится так, чтобы это можно было сделать не инвазивным способом. Ваш К.О.

BFE>>>Тесты, как средство управления проектом — ok, а вот как средство разработки — подходит не для всех задач.
L>>Не подходит для крайне малого домена задач.
BFE>Да ладно! Есть большие классы задач, которые сложно или крайне сложно протестировать. Давайте, предложите тест для проверки отрисовки, скажем, кнопки.

Легко. Формулируй критерий валидности отрисовки кнопки и задача сводится к предыдущей.
Критерий "нравится дизайнеру" не катит, как ты понимаешь.

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

L>>>Только это уже не юнит-тесты.
BFE>>Ну как "прекрасно". Может оказаться, что для этого надо затратить труд превосходящий по времени написание приложения.
L>Вот у нас, почему-то, не оказалось. Мы, наверное, что-то делаем неправильно.
Наверное у вас датчики только одного (стандартизованного) типа.

L>>>Время, кстати, тоже тестируется, если выбраны правильные уровни абстракции.
BFE>>Не совсем понятно, как вам помогут уровни абстракции и причём они тут. Багов связанных со временем очень много, они весьма разнообразны и встречаются во всех системах. Apple, MS и Unix страдают ими перманентно. Думаете многие готовы к проблеме 2038-ого года или хотя бы задумываются/знают о ней? А ведь осталось каких-нибудь 22 года.
L>Мы говорим о юнит-тестах для вновь написанного кода, а не системной ошибке.
Не, ну с таким подходом конечно всё просто.

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

L>>>Такой код может и должен быть протестирован.
BFE>>Может и должен. Что не отменяет того факта, что за всё время эксплуатации он никогда не будет вызван.
L>Только когда он будет вызван тот самый единственный и последний раз, протестированный код с бОльшей вероятностью поведет себя так, как вы ожидали.
Значит удалять его не надо? Обнадёжили.

BFE>>Кстати, можете предложить не инвазивный способ тестирования?
L>Код рефакторится так, чтобы это можно было сделать не инвазивным способом. Ваш К.О.
И получаем усложнение кода, что потенциально чревато новыми ошибками.

BFE>>Да ладно! Есть большие классы задач, которые сложно или крайне сложно протестировать. Давайте, предложите тест для проверки отрисовки, скажем, кнопки.
L>Легко. Формулируй критерий валидности отрисовки кнопки и задача сводится к предыдущей.
К предыдущей — это которой?

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

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

BFE>>>Может и должен. Что не отменяет того факта, что за всё время эксплуатации он никогда не будет вызван.
L>>Только когда он будет вызван тот самый единственный и последний раз, протестированный код с бОльшей вероятностью поведет себя так, как вы ожидали.
BFE>Значит удалять его не надо? Обнадёжили.

Если он протестирован — не надо.

BFE>>>Кстати, можете предложить не инвазивный способ тестирования?
L>>Код рефакторится так, чтобы это можно было сделать не инвазивным способом. Ваш К.О.
BFE>И получаем усложнение кода, что потенциально чревато новыми ошибками.

И получаем упрощение кода.
(Анекдот про стеклянный буй как нельзя к месту)

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

И при этом размер кнопки менять нельзя, да? Это и есть "нравится дизайнеру". Это не задача юнит-тестов, это задача для дизайнера.
Юнит тесты должны проверять четко формализованные критерии.

Здравствуйте, B0FEE664, Вы писали:
BFE>Ух ты! Адепт использует приём "я модный и успешный". Оно, конечно, хорошо — быть д'Артаньяном, только вот Россию приплели не к месту. Я, например, давно уехал.
а вы тут вообще причем?

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

BFE>>>>Кстати, можете предложить не инвазивный способ тестирования?
L>>>Код рефакторится так, чтобы это можно было сделать не инвазивным способом. Ваш К.О.
BFE>>И получаем усложнение кода, что потенциально чревато новыми ошибками.

L>И получаем упрощение кода.
Каким образом поменяв вызов обычной функции ввода вывода насложную конструкцию мы получим упрощение кода?

L>(Анекдот про стеклянный буй как нельзя к месту)
Вот-вот. Сначала применим неподходящий материал, а потом будем обращатся с нежностью. Умно!

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

L>И при этом размер кнопки менять нельзя, да?
Можно.
L>Юнит тесты должны проверять четко формализованные критерии.
И?

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

Можно просто регрессивные тесты по подсистемам...

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

От задач зависит. Есть такие, где юнит-тесты хорошо работают, а есть такие, где почти бесполезны...
Если поведение очень сложное, то юнит-тестирвание всех запчастей даст процентов 10 надёжности, а функциональное тестирование всего в сборе — сложное.
Это мы не говорим ещё о таких вещах, как data-driven AI.
Вот пишешь ты AI, которое рожи на фейсбучке ищет и отождествляет, и надо гарантировать, что бы негров на обезьян не матчили и т. п.
И как ты это юнит-тестами обеспечишь?

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

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

это сильная заявка в мировые аутсайдеры разработки

ЧСВ атакует, однако...
1) Есть задачи, где юнит-тесты, аджайл и прочее итерактивное программирование рулят. Обычно это код не особо наукоёмкий, но зато много работы для программиста. А есть задачи, где главные затраты — НИР. И там юнит-тесты, обычно, малополезны...

Вот надо тебе сделать ПО к коробасу или роботу в машину, в те же деньги, что раньше, но плавнее и ресурс что бы зря не жечь. Что-то в железе надо делать, что-то в ПО, и чего?

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

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

Ну вот расскажи, например, как обеспечить работу спам-фильтра таким образом? Или, например, фильтра, который вылавливает в трафике письма арабских террористов и стучит в ЦРУ и ФБР...

Юнит-тесты -- это обратная сторона отказа от assert's в релизной версии кода. В каком-то смысле одно заменяет другое.
Это может гарантировать какой-то уровень стабильности и очень простой функционал. Ну, вроде того, что функция сортировки таки сортирует.
Если поведение сложное, скажем какой-то генетический алгоритм, то обеспечения общей стабильности и функционала базовых примитивов недостаточно

Бывают проблемы сложнее, "ошибка в ветвлении". Ну, например, выбрали не ту условно-устойчивую конечно-разностную схему и в каком-то РЕАЛЬНОМ режиме, утратили аппроксимацию. И привет, реактор пошёл в разнос или МБР полетела не туда...

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

Это +100500!
Тока начиная с некоторого уровня неспособность это сделать без юнит-тестов означает проф. непригодность...

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

L>Время, кстати, тоже тестируется, если выбраны правильные уровни абстракции.

от железа зависит...

Если пишешь управление чем-то таким быстрым, да ещё и с ограничением по скорости эффекторов и самого проца, ну, например, ПО для С-400, скажем, то увы, точную модель сделать может быть дороже, чем время от времени осуществлять "прогон" путём отстрела тестовой ракеты по мишени

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

L>Не подходит для крайне малого домена задач.

Как измеряешь мощность доменов?

Весь AI и UI, как минимум, юнит-тестами покрываются плохо...

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

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

Ну дебагер часто и правда лишний...

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

__>смотрите сериал "физрук"? там есть такой персонаж — Усач. ух, извращенец, меня аж всего передергивает когда он там начинает то с баяном, то еще с чем красоваться. но персонаж яркий! мне он нравится, крассный актер, офигенная находка. за людьми, которые сидят в дебагере, прикольно наблюдать, но работать с ними — нет, не сложно, а, если точнее, невыносимо

__>вспоминая еще одного персонажа — как говорил Гомер Симпсон — "это противоествественно. и должно быть противозаконно!"

Тоже от задач зависит...

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

BFE>Кстати, можете предложить не инвазивный способ тестирования?
RAM-диск с драйвером, позволяющим эмулировать проблемы...

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

L>Вот у нас, почему-то, не оказалось. Мы, наверное, что-то делаем неправильно.
От задачи зависит.

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

L>Легко. Формулируй критерий валидности отрисовки кнопки и задача сводится к предыдущей.
L>Критерий "нравится дизайнеру" не катит, как ты понимаешь.

А критерий "пользователь испытывает дикий восторг от красивого и удобного интерфейса" катит?..

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

L>Как ты думаешь, сколько типов датчиков поддерживает одна наиболее используемых в мире SCADA систем в мире?

Думаю, что меньше, чем число моделей сканеров, которым хорошо умеет сканировать фотошоп...

При чём может и не на один порядок...

А теперь задачка попроще, мы хотим сделать небольшую дешевую прогу, которая сканирует ЛЮБЫМ сканером фотку без вопросов и публикует её в альбоме.
Как будем тестировать совместимость со всем зоопарком сканеров?

L>Конечно. Это системная проблема, пусть у ответственных за систему голова об этом болит для начала.

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

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

L>Юнит тесты должны проверять четко формализованные критерии.

Бинго! Есть КУЧА ПО, критерии на который плохо поддаются формализации

Например, "Хорошая игрушка", "удачная стиральная машина", "лучшая в мире система ПВО" и т. д...

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

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

__>>

__>>Unit tests created in a test-driven development environment are typically created by the developer who is writing the code being tested. Therefore, the tests may share blind spots with the code: if, for example, a developer does not realize that certain input parameters must be checked, most likely neither the test nor the code will verify those parameters. Another example: if the developer misinterprets the requirements for the module he is developing, the code and the unit tests he writes will both be wrong in the same way. Therefore, the tests will pass, giving a false sense of correctness.

L>Иными словами, если девелопер не использует /dev/brain в ежедневной работе, то он может даже получить false sense of correctness. Только это не проблемы юнит-тестов, любой инструмент нужно уметь правильно использовать.

__>>A high number of passing unit tests may bring a false sense of security, resulting in fewer additional software testing activities, such as integration testing and compliance testing.

L>or may not.

тут логическое ударение не на may, а на то, что люди теряют бдительность, начиная неадекватно воспринимать тестирование как панацею ото всех ошибок, при этом предавая анафеме (как вы и __kot2) все остальные средства.

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

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

__>>Ну и, наконец, из Software_testing:

L>Юнит-тесты — не инструмент тестирования. Это инструмент разработки.

в моем представлении, юнит-сесты — это инструмент тестирования. а вот методология разработки TDD — это инструмент разработки.

L>Впрочем, называть отладчик инструментом тестирования... можно, конечно....

и использовать совместно с юнит-тестами

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

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

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

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

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

ммм... а где я успел рассказать, как я его использую?

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

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

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

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

E>Ну дебагер часто и правда лишний...

тоже, можно примеры, когда он лишний?

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

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

__>>ну так, это же "ужас-ужас-ужас" — превращать подготовку к компиляции в отдельную инженерную задачу. эдак со временем стоит ожидать появления "специалиста по предкомпиляционной подготовке с++ проекта".

SaZ>Когда работал в Варгейминге (проект wot blitz), да и не только там, у нас в команде была позиция, которая так и называлась — build engineer. Собственно сейчас, средствами CMake, танчики собираются под всё (ios/win/android + все десктопы). У всех стоит IncrediBuild. 20 минут — полная пересборка проекта (без конвертации ресурсов).

и вы считаете это естественным? а что будет через пару лет, когда объем проектов во много раз возрастет?

SaZ>Если у вас в одиночку получился столь большой проект, что вас парит время комипляции — то что-то тут не то. Или плохо накодили или не туда двигаетесь. Где-то тут, несколько лет назад, пробегал этюд товарища Nikov (правда для C#). Как обычным дженериком на 5 аргументов нагенерить 25 метров кода и ждать компиляции более 7 минут. Жаль не могу найти.

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

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

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

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

В самом первом сообщении в этой теме.

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

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

Спам-фильтр у нас как выглядит? void filter_spam()?

Или все же состоит из мелких тестируемых модулей? Вот их-то и надо тестировать.

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

E>Или, например, фильтра, который вылавливает в трафике письма арабских террористов и стучит в ЦРУ и ФБР...

То же самое.

E>Юнит-тесты -- это обратная сторона отказа от assert's в релизной версии кода. В каком-то смысле одно заменяет другое.
E>Это может гарантировать какой-то уровень стабильности и очень простой функционал. Ну, вроде того, что функция сортировки таки сортирует.

Если функция сортировки не сортирует, спам-фильр тестировать несколько рановато.

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

L>>Время, кстати, тоже тестируется, если выбраны правильные уровни абстракции.
E>от железа зависит...

E>Если пишешь управление чем-то таким быстрым, да ещё и с ограничением по скорости эффекторов и самого проца, ну, например, ПО для С-400, скажем, то увы, точную модель сделать может быть дороже,

А может и не стоить.
Всегда можно выбрать подход и базис для тестирования, даже если полноценное тестирование на макете провести по каким-то причинам нельзя.

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

E>Как измеряешь мощность доменов?

E>Весь AI и UI, как минимум, юнит-тестами покрываются плохо...

А модули, на которых он стрится?

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

L>>Вот у нас, почему-то, не оказалось. Мы, наверное, что-то делаем неправильно.
E>От задачи зависит.

От подхода к разработке, а не от задачи. Некоторых послушать, все задачи офигеть какие сложные, не тестируемые и т.п.

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

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

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

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

L>В самом первом сообщении в этой теме.

там только фраза:
"Все бы ничего, но невозможно же дебаггинг проводить — одно исправление — и опять длительное ожидание перекомпиляции."

кстати, "дебаггинг" не только работа под дебагером, но и просто поиск ошибок в коде.

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

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

Этого достаточно. Свеженаписанному коду дебаггинг не нужен. Ему нужна верификация.

__>кстати, "дебаггинг" не только работа под дебагером, но и просто поиск ошибок в коде.

Если же вести "просто поиск", то зачем тогда ждать компиляции?

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

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

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

L>Этого достаточно. Свеженаписанному коду дебаггинг не нужен. Ему нужна верификация.

в каком понимании "дебагинг" — в "работе под дебагером" или

Debugging is the process of finding and resolving of defects that prevent correct operation of computer software or a system.

__>>кстати, "дебаггинг" не только работа под дебагером, но и просто поиск ошибок в коде.

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

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

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

L>>or may not.

__>тут логическое ударение не на may, а на то, что люди теряют бдительность, начиная неадекватно воспринимать тестирование как панацею ото всех ошибок, при этом предавая анафеме (как вы и __kot2) все остальные средства.

Отладчик — это самое крайнее средство. Как тот самый доктор, который все знает, все умеет, но приходит слишком поздно.

L>>Юнит-тесты — не инструмент тестирования. Это инструмент разработки.
__>в моем представлении, юнит-сесты — это инструмент тестирования. а вот методология разработки TDD — это инструмент разработки.

Нет. Юнит-тесты — это инструмент разработки. Они не заменяют тестирование, но очень сильно смещают акценты.

L>>Впрочем, называть отладчик инструментом тестирования... можно, конечно....
__>и использовать совместно с юнит-тестами

Ну незачем использовать отладчик на проекте, который ведется в хорошем TDD стиле.

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

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

L>>Юнит тесты должны проверять четко формализованные критерии.

E>Бинго! Есть КУЧА ПО, критерии на который плохо поддаются формализации

E>Например, "Хорошая игрушка", "удачная стиральная машина", "лучшая в мире система ПВО" и т. д...

Дай подумаю...

class good_toy;
class excellent_washing_mashine;
class best_airspace_protection_system_in_the_world;

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

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

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

L>>>or may not.

__>>тут логическое ударение не на may, а на то, что люди теряют бдительность, начиная неадекватно воспринимать тестирование как панацею ото всех ошибок, при этом предавая анафеме (как вы и __kot2) все остальные средства.

L>Отладчик — это самое крайнее средство. Как тот самый доктор, который все знает, все умеет, но приходит слишком поздно.

кхм.. а __kot2 говорил, что это скрипучая телега в век,к огда все ездят на машинах

L>>>Впрочем, называть отладчик инструментом тестирования... можно, конечно....
__>>и использовать совместно с юнит-тестами

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

затем, что тесты не гарантия безошибочности

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

L>>Как ты думаешь, сколько типов датчиков поддерживает одна наиболее используемых в мире SCADA систем в мире?
E>Думаю, что меньше, чем число моделей сканеров, которым хорошо умеет сканировать фотошоп...

Когда кажется, креститься надо.

E>При чём может и не на один порядок...

Возможно, только не в ту сторону, о которой ты подумал.. Тем более, что имхо сканирует не фотошоп, а драйвер сканера.

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

I>...
I>Вроде всё, сделать так лучше только для Debug версии, а в релизе переодически проверять что не забыл включить нужные заголовки.
I>И выставь еще Configuration Properties\C/C++\General\Multi-processor Compilation Yes

У себя юзаю такое в precompiled headers. Периодически пополняю:

stl_includes.h

#pragma once

// Types
#include <ctime>
#include <chrono>
#include <functional>
#include <numeric>
#include <type_traits>
#include <typeinfo>
#include <typeindex>
#include <algorithm>

// Containers
#include <array>
#include <string>
#include <set>
#include <vector>
#include <map>
#include <list>
#include <queue>
#include <deque>
#include <bitset>
#include <stack>
#include <unordered_set>
#include <unordered_map>
#include <iterator>

// Streams
#include <sstream>
#include <iostream>
#include <iomanip>
#include <fstream>

// Memory
#include <memory>

// Misc
#include <cassert>
#include <utility>

// Threads
#include <atomic>
#include <thread>
#include <mutex>
#include <shared_mutex>
#include <future>

// Other
#include <filesystem>

Ну и для кутэ. Оличие от вашего варианта — корректно разруливаются инклюды в зависимости от подключенных модулей:

qt_includes.h

#pragma once

#ifdef QT_CORE_LIB
# include <QtCore>
#endif

#ifdef QT_CONCURRENT_LIB
# include <QtConcurrent>
#endif

#ifdef QT_GUI_LIB
# include <QtGui>
#endif

#ifdef QT_WIDGETS_LIB
# include <QtWidgets>
#endif

#ifdef QT_MULTIMEDIA_LIB
# include <QtMultimedia>
#endif

#ifdef QT_NETWORK_LIB
# include <QtNetwork>
#endif

#ifdef QT_XML_LIB
# include <QtXml>
#endif

#ifdef QT_QML_LIB
# include <QtQml>
#endif

#ifdef QT_QUICK_LIB
# include <QtQuick>
#endif

#ifdef QT_SQL_LIB
# include <QtSql>
#endif

#ifdef QT_PRINTSUPPORT_LIB
# include <QtPrintSupport>
#endif

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

E>>Это +100500!
E>>Тока начиная с некоторого уровня попытка это сделать без юнит-тестов означает проф. непригодность...

L>fixed.

Ты правда не можешь понять, что надо написать, пока не написал тесты?

Про пред/пост-условия что-то слышал?

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

L>Спам-фильтр у нас как выглядит? void filter_spam()?

L>Или все же состоит из мелких тестируемых модулей? Вот их-то и надо тестировать.
Конечно надо, только этот слой — 10%-20% фильтра...

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

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

L>То же самое.
То же самое...

L>Если функция сортировки не сортирует, спам-фильр тестировать несколько рановато.
Да, разумеется. Если проблема с тем, что бы реализовать функцию сортировки, то надо или брать готовый фрейморк или вообще такие задачи не по зубам. Суть в том, что главные сложности разработки такого ПО не в плоскости обеспечения стабильности, даваемой юнит-тестами лежит...

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

L>А может и не стоить.
L>Всегда можно выбрать подход и базис для тестирования, даже если полноценное тестирование на макете провести по каким-то причинам нельзя.

Что-то можно, но в целом не получится без "прогонов в железе"

То, что ты пишешь — всё правильно, если доступно.

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

L>А модули, на которых он стрится?

Часто это просто готовый Фреймворк...

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

E>Часто это просто готовый Фреймворк...

Тогда, простите, что тут тестировать? Фреймворк?

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

E>>От задачи зависит.

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

Я тебе несколько задач уже привёл, где IMHO, TDD мало полезна. Покажешь как надо?

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

E>>А критерий "пользователь испытывает дикий восторг от красивого и удобного интерфейса" катит?..

L>Катит. Если пользователя можно подключить электродами к компьютеру и залить в репозиторий.

Это не серьёзно...

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

L>>От подхода к разработке, а не от задачи. Некоторых послушать, все задачи офигеть какие сложные, не тестируемые и т.п.
E>Я тебе несколько задач уже привёл, где IMHO, TDD мало полезна. Покажешь как надо?

Какая из? AI на базе некоего абстрактного фреймворка или kick_ass_washing_machine?

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

E>>Есть задачи, где под 100%, а есть где и 10% может не набраться...

L>Скорее, где поленились остальные 90% хоть как-то формализовать

Что значит "поленились"? Дорого или вообще не понятно как...

Давай ты расскажешь как ловца писем террористов на 100% формализовать?

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

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

Это, скорее всего, must have, но это уже вопрос проектирования. И все эти запчасти, скорее всего есть уже готовые вообще.
Дальше нужна компоновка, проект UI, и т. д...

Но мы же не про железо, а про рулящее им ПО?..

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

L>Возможно, только не в ту сторону, о которой ты подумал.. Тем более, что имхо сканирует не фотошоп, а драйвер сканера.
Фотошоп управляет драйвером.
Так скока типов датчиков? Сканеров тысяч 5 есть, если не больше...

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

L>>Отладчик — это самое крайнее средство. Как тот самый доктор, который все знает, все умеет, но приходит слишком поздно.
__>кхм.. а __kot2 говорил, что это скрипучая телега в век,к огда все ездят на машинах

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

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

Тесты — инструмент верификации. На этом поле отладчику ловить совершенно нечего.
Единственное применение отладчика на проекте с TDD — ловля всяких НЕХ, которых "не может быть никогда". Вроде багов оптимизатора или свинячества сторонней библиотеки.

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

__>тоже, можно примеры, когда он лишний?

Ну вычматы, например...

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

L>>Всегда можно выбрать подход и базис для тестирования, даже если полноценное тестирование на макете провести по каким-то причинам нельзя.
E>Что-то можно, но в целом не получится без "прогонов в железе"

Симуляторы и эмуляторы изобрели даже не в прошлом веке.

E>То, что ты пишешь — всё правильно, если доступно.

Почти все доступно почти всегда. Было бы желание.

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

E>Ты правда не можешь понять, что надо написать, пока не написал тесты?

Нет, я обоснованно считаю написание кода без тестов напрасной работой.

E>Про пред/пост-условия что-то слышал?

Мы, кажется, на разных языках говорим. Юнит-тесты делают намного больше, нежели ты можешь добиться от самых хитрых ассертов.

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

E>>Часто это просто готовый Фреймворк...

L>Тогда, простите, что тут тестировать? Фреймворк?

Работу фильтра...

Я про то и говорю, что есть задачи, где юнит-тестирование малоактуально...

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

L>Какая из? AI на базе некоего абстрактного фреймворка или kick_ass_washing_machine?

Давай возьмём задачу сделать прототип ловца писем терроритстов на лазаньи на глубоких нейросетях?
Что бы ты там юнит-тестами и вообще тдд разрабатывал?

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

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

Не, я хочу тест того, что юзеру понравится, и разработку направлять в эту сторону.
А юнит-тест и вообще TDD юзать или чего иного -- вопрос осознанного выбора уже. IMHO тут юнит-тесты малополезны.

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

E>Это, скорее всего, must have, но это уже вопрос проектирования. И все эти запчасти, скорее всего есть уже готовые вообще.

Воот. Must Have!
и эти мастхевы есть вполне формализуемые критерии. Без удовлетворения которых тестировать конечный продукт вообще смысла нет.

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

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

E>>Что-то можно, но в целом не получится без "прогонов в железе"

L>Симуляторы и эмуляторы изобрели даже не в прошлом веке.
Симуляторы/эмуляторы чего? ТТ-движка и системы рулей?

L>Почти все доступно почти всегда. Было бы желание.
Вопрос цены/точности эмуляции...

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

L>>Возможно, только не в ту сторону, о которой ты подумал.. Тем более, что имхо сканирует не фотошоп, а драйвер сканера.
E>Фотошоп управляет драйвером.
E>Так скока типов датчиков? Сканеров тысяч 5 есть, если не больше...

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

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

L>>Симуляторы и эмуляторы изобрели даже не в прошлом веке.
E>Симуляторы/эмуляторы чего? ТТ-движка и системы рулей?

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

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

L>>Почти все доступно почти всегда. Было бы желание.
E>Вопрос цены/точности эмуляции...

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

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

E>Не, я хочу тест того, что юзеру понравится, и разработку направлять в эту сторону.

Говрю же, без вопросов. Залей юзера в репозиторий и задача становится тривиальной.

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

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

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

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

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

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

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

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

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

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

__>>тоже, можно примеры, когда он лишний?

E>Ну вычматы, например...

и в каком смысле он там лишний?

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

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

E>>Ты правда не можешь понять, что надо написать, пока не написал тесты?

L>Нет, я обоснованно считаю написание кода без тестов напрасной работой.

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

2) Ты сделал несколько иное утверждение, что понять что и зачем делать, без тестов нельзя...

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

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

E>>Давай ты расскажешь как ловца писем террористов на 100% формализовать?

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

угу-угу... Я и говорю, что слишком дорого

L>Даже если задача на 100% не формализуется, это не повод не попытаться формализовать ее на достижимые 80(79, 65, 95)%.

Мы всё ещё о ТДД и юнит-тестах?

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

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

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

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

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

SaZ>>>Когда работал в Варгейминге (проект wot blitz), да и не только там, у нас в команде была позиция, которая так и называлась — build engineer. Собственно сейчас, средствами CMake, танчики собираются под всё (ios/win/android + все десктопы). У всех стоит IncrediBuild. 20 минут — полная пересборка проекта (без конвертации ресурсов).

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

SaZ>Конечно. Свою карьеру я начинал в Епаме. Там для нашего проекта была целая команда билд инженеров. А ещё devops-ы есть.

то, что есть де-факто, не значит, что это естественно

раньше наверное тоже отдельные должности были по набиванию перфокарт, и что?

SaZ>В вашем же случае получается так: вы заранее знаете о том, что сложность проекта будет нелинейно расти в течение нескольких лет, но всё равно не хотите выделить должные ресурсы на проработку архитектуры.

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

SaZ>>>Если у вас в одиночку получился столь большой проект, что вас парит время комипляции — то что-то тут не то. Или плохо накодили или не туда двигаетесь. Где-то тут, несколько лет назад, пробегал этюд товарища Nikov (правда для C#). Как обычным дженериком на 5 аргументов нагенерить 25 метров кода и ждать компиляции более 7 минут. Жаль не могу найти.

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

SaZ>В вашем понимании программист — это кодер. Таких, конечно, не должны заботить проблемы компилятора. Такие обычно делают всякие несложные фронтэнды на пхп/асп на аутсорс.
SaZ>В моём понимании программист — это инженер. Это человек, который способен спроектировать и реализовать систему, которая будет работать. А при наличии требований к масштабированию — спроектировать хорошую архитектуру.

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

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

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

Здравствуйте, 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>>И как же это "проверить" осуществляется?

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

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

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

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

__>>и в каком смысле он там лишний?

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

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

вы о чем?

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

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

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

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

Почему?

Здравствуйте, 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>Ты спрашиваешь, написал ли я её? Да, до какой-то степени покрытия всех существующих сканеров...

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

Здравствуйте, _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 тестирование.

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

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

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

L>

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

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

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

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

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

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

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

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

По факту С-?00 таки летают же

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

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

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

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

__>вы о чем?
Мы о сохранении инвариантов...

Проверяется assert's или юнит-тестами...

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

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

А как узнать, "как должно быть"?

На коленке сосчитать?
А если задача многомерная?

ай, SaZ, вы в своем репертуаре

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

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

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

L>>>Например, что если пользователь просил латте, то они получает латте, а не флэт вайт, и что латте — это именно латте, а не каппучино?

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

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

нет, это относится ко всему тестированию — см. статью по ссылке

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

E>Я привёл тебе несколько разных задач, где юнит-тесты, в частности, и ТДД, в целом, экономически не целесообразны.
E>Ты не про одну так и не показал, что целесообразны...

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

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

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

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

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

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

Что такое автотесты в данном случае?

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

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

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

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

а, ну вот теперь более конкретно.

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

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

__>>не понял

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

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

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

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

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

ок. спасибо.

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

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

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

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

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

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

почему?

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

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

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

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

L>>Это относится только к black-box тестированию. Юнит-тесты — это white-box тестирование.
__>нет, это относится ко всему тестированию — см. статью по ссылке

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

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

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

Таки если мы ещё про вычматы, и если откуда-то известно "как надо", то момент расхождения с "как надо" лучше искать заточенным под это тестом, а не отладчиком...

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

E>>Я про то и говорю, что не все задачи хорошо покрываются юнит-тестами и ТДД...

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

Несколько раз писал прямым текстом...

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

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

__>>вы о чем?
E>Мы о сохранении инвариантов...

E>Проверяется assert's или юнит-тестами...

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

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

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

E>А как узнать, "как должно быть"?

E>На коленке сосчитать?
E>А если задача многомерная?

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

с тестами будет то же самое — все размерности и комбинации не обсчитать

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

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

E>>>Я про то и говорю, что не все задачи хорошо покрываются юнит-тестами и ТДД...

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

E>Несколько раз писал прямым текстом...

да, н без аргументов наподробие "даже если в системе все элементы в отдельности протестированы, это не означает, что система будет работать как надо"

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

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

Так любые тесты делают, не только юнит...

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

Бывает ещё и функциональное тестирование и регрессивное и т. д...

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

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

)

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

Ну, например, часто пишут прототип, который можно запускать, а потом в нём реализуют подсистемы...

Ну и вообще, пусть мы UI пишем, например. Пишем, запускаем, смотрим...

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

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

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

E>Таки если мы ещё про вычматы, и если откуда-то известно "как надо", то момент расхождения с "как надо" лучше искать заточенным под это тестом, а не отладчиком...

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

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

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

Вроде и сейчас мировой лидер и по цене и по ТТХ...

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

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

Тем не менее, ты, со своим 10+ опытом внедрения дал оценку формализации требований к ловцу писем террористов в "тысячи учёных работающих за большие деньги" или как-то так примерно. Я с ней согласен.

А тестовые базы писем с разметкой, где террористы, а где нет, стоят НАМНОГО дешевле и работают ЛУЧШЕ...

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

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

Регрессивные тесты по границам подсистем полезны тоже и т. д...
Задача тестирования сложного трудноформализуемого поведения сложна сама по себе, и тут важно выбрать верный компромисс...

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

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

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

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

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

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

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

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

Конечно не значит, особенно, если система data-driven...

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

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

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

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

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

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

E>Конечно не значит, особенно, если система data-driven...

токо не "конечно", ибо это не совсем тривиальный факт (даже отдельное название имеет — эмерджентность системы)

Здравствуйте, 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>>В моей книге "523 оправдания, почему мы не пишем автотесты" этот вывод вместе с преамбулой войдет в предисловие.
E>Что такое автотесты в данном случае?

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

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

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

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

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

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

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

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

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

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

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

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

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

Это в каком смысле "в отсутствии конкурентов"?

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

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

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

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

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

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

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

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

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

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

Вовсе нет.
Но это уже оч. сильно офтоп...

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

L>Им вообще остается проверять сборку на соответствие спецификациям, по большому счету.

Если над уровнем юитов нет какого-то сложного их взаимодействия....

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

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

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

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

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

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

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

L>При правильном подходе к организации кода и покрытию сценариев его использования прогаммист может протестировать все сценарии использования юнита. Абсолютно все.

но это же неправда — даже для обычной foo(uint32_t x, uint32_t y) практически невозможно проверить абсолютно все комбинации аргументов/

L>Обычно. Как правило. Чем опытнее TDD-программист, тем сильнее его "обычно" стремится к "всегда". Иногда это не так, иногда это и правда дорого (привет, Erop), иногда просто лень, иногда тупо непонятно, что нужно делать в случае определенных входных данных, которых никогда быть не должно.

вот это уже "ближе к телу". и вроде бы я с вами в этом соглашался — что юнит-тесты (хотя я еще не до конца осознал их суть) позволяют снизить вероятность появления ошибок, но требуют затрат. поэтому всегда нужно смотреть на соотношение цена/качество, а не рассматривать их как панацею и замену дебагера.

L>Что это означает? Что система, состоящая из оттестированных юнитов, в тестировании не нуждается? You wish! Это означает нечто другое, а именно то, что система уже прошла раннюю верификацию. Тестерам не нужно искать сломанное сетевое устройство, чтобы проверить поведение системы в случае общения с устройством, которое портит сообщения, так как логика этого поведения уже проверена.
L>Им вообще остается проверять сборку на соответствие спецификациям, по большому счету.

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

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

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

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

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

например, CA A; A.foo(0); A.foo(1); A.foo(0.5)// для крайних значений 0, -1 и обычного 0.5

__>>>>не понял

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

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

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

это означает, что при нормально работающей системе nullptr-а там быть не должно, а вот на этапе разработке, вполне может появиться, и это будет свидетельствовать об ошибке

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

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

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

ммм... пока не понял, как именно осуществляется тестирование функциональности (задача вроде неподъемная из-за "комбинаторного взрыва"), и почему его нужно считать качественным шагом вперед. но спасибо за диалог — начало что-то проясняться

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

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

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

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

L>Многопоточные, наверное? Они, родимые.

не, их в рассмотрение не включаем

это отдельная головная боль

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

это почему же?

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

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

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

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

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

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

L>>При правильном подходе к организации кода и покрытию сценариев его использования прогаммист может протестировать все сценарии использования юнита. Абсолютно все.
__>но это же неправда — даже для обычной foo(uint32_t x, uint32_t y) практически невозможно проверить абсолютно все комбинации аргументов/

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

L>>Обычно. Как правило. Чем опытнее TDD-программист, тем сильнее его "обычно" стремится к "всегда". Иногда это не так, иногда это и правда дорого (привет, Erop), иногда просто лень, иногда тупо непонятно, что нужно делать в случае определенных входных данных, которых никогда быть не должно.

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

Не требуют они затрат. Пишутся на автомате.

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

Юнит-тесты применяются в основном как раз для тестирования этих самых блоков при их разработке. Любое другое тестирование при этом выглядит проигрышно.

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

L>>Многопоточные, наверное? Они, родимые.
__>не, их в рассмотрение не включаем

это отдельная головная боль

А вот надо включать, чтобы головную боль как можно раньше отгильотинить

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

Ну тут уже упоминали такую приятную вещь, как стрельбу по памяти, например.

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

__>>>да спокойно. возьму и отдельно повызываю его методы на прогонных значениях (ведь прогон же не считается юнит-тестом?)
L>>Таак, уже теплее. Вот это "возьму отдельно и повызываю методы" ты как делаешь? Вот новый проект, ничего запускаемого еще нет. Какие действия?
__>например, CA A; A.foo(0); A.foo(1); A.foo(0.5)// для крайних значений 0, -1 и обычного 0.5

То есть пишете маленький лончер и запускаете его в отладчике? Поздравляю, вы изобрели юнит-тесты вручную! (Бурные продолжительные аплодисменты, переходящие в овацию.)
Серьезно, все, что вы делаете в отладчике, можно и нужно делать автоматически в коде теста. Потом, через полгода, когда будете править код, сами себе спасибо скажете, и не один раз, а когда новонанятый джун "улучшит" уже "отлаженный" код, скажете еще миллион раз.

__>>>>>не понял

что нельзя написать assert(nullptr != data); ?
L>>>>Нет, во многих случаях писать его там бессмысленно.
L>>Потому что это либо означает, что нужна полноценная проверка в рантайме, либо архитектура плохо продумана, либо ассерт просто воткнут туда "на всякий случай", потому что "так принято".
__>это означает, что при нормально работающей системе nullptr-а там быть не должно, а вот на этапе разработке, вполне может появиться, и это будет свидетельствовать об ошибке

При TDD выделенное почему-то — редкость.

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

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

__>ммм... пока не понял, как именно осуществляется тестирование функциональности (задача вроде неподъемная из-за "комбинаторного взрыва"), и почему его нужно считать качественным шагом вперед. но спасибо за диалог — начало что-то проясняться

Функциональность в первую и вторую очередь определяется сценариями, которые реализуют юниты в отдельности. Хорошо изолированные юниты реально полностью провалидировать в отдельности конечным числом юнитов. Когда они уже склеены в систему, сделать это невозможно из-за комбинаторного взрыва, а вот по отдельности — пожалуйста.

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

__>во-первых, что такое "границы" ? граничные точки области определения функции? и почему именно в них нужно, а в других точках — не нужно?

Экстремумы, точки перегиба, границы применимости алгоритма. Или тупо все if или switch..case.

__>а во-вторых, таких граничных точек может быть тоже неподъемно много для обычных вычислений

Не может, иначе реализация такого алгоритма займет бесконечное время.

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

Нет, юнит-тесты — это когда каждый транзистор проверяется на конвеере на фабрике еще до того, как ты поставишь его в схему

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

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

L>>>При правильном подходе к организации кода и покрытию сценариев его использования прогаммист может протестировать все сценарии использования юнита. Абсолютно все.
__>>но это же неправда — даже для обычной foo(uint32_t x, uint32_t y) практически невозможно проверить абсолютно все комбинации аргументов/

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

вот этого я и не понимаю. если вы проверили sqrt(uint32_t x) для валидного данного x = 2, то это не значит, что для x = 101 все будет работать, ведь у вас может, например, из-за округлений, или ошибки в программе, которая не проявляет себя на четных числах, перестать работать. скорее уж нужно использовать случайное тестирование (случайным образом выбирается точка в пространтсве аргументов и производится тест для нее)

L>>>Обычно. Как правило. Чем опытнее TDD-программист, тем сильнее его "обычно" стремится к "всегда". Иногда это не так, иногда это и правда дорого (привет, Erop), иногда просто лень, иногда тупо непонятно, что нужно делать в случае определенных входных данных, которых никогда быть не должно.

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

L>Не требуют они затрат. Пишутся на автомате.

можете накидать на автомате для sqrt(uint32_t x) с итерационным алгоритмом?

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

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

L>>>Многопоточные, наверное? Они, родимые.
__>>не, их в рассмотрение не включаем

это отдельная головная боль

L>А вот надо включать, чтобы головную боль как можно раньше отгильотинить

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

L>Ну тут уже упоминали такую приятную вещь, как стрельбу по памяти, например.

а можно на пальцах, для тех, кто далек от "стрельбы по памяти"?

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

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

__>>>>да спокойно. возьму и отдельно повызываю его методы на прогонных значениях (ведь прогон же не считается юнит-тестом?)
L>>>Таак, уже теплее. Вот это "возьму отдельно и повызываю методы" ты как делаешь? Вот новый проект, ничего запускаемого еще нет. Какие действия?
__>>например, CA A; A.foo(0); A.foo(1); A.foo(0.5)// для крайних значений 0, -1 и обычного 0.5

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

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

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

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

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

Ну так "косяки" могут начать проявляться не с первой итерации...

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

__>во-первых, что такое "границы" ?

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

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

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

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

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

__>>во-первых, что такое "границы" ? граничные точки области определения функции? и почему именно в них нужно, а в других точках — не нужно?

L>Экстремумы, точки перегиба, границы применимости алгоритма. Или тупо все if или switch..case.

почему именно они? почему не другие точки? и что такое "экстремум", "точка перегиба" например, для алгоритма обращения списка?

__>>а во-вторых, таких граничных точек может быть тоже неподъемно много для обычных вычислений

L>Не может, иначе реализация такого алгоритма займет бесконечное время.

да легко может, если вы про обычные граничные точки в математическом понимании. например:
вычисления комплексного значения z по итерационной формуле z_n = z_{n-1} ^2 + c, где с = — 0.74543 + 0.11301i

точки, в которых алгоритм не расходится — так называемое множество жюлиа:

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

L>Нет, юнит-тесты — это когда каждый транзистор проверяется на конвеере на фабрике еще до того, как ты поставишь его в схему

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

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

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

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

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

E>Ну так "косяки" могут начать проявляться не с первой итерации...

это уже другой вопрос — как локализовать область появления расхождения ожидаемого от реального

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

__>это уже другой вопрос — как локализовать область появления расхождения ожидаемого от реального

Ну лучше, конечно, автоматизировать поиск и контроль...

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

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

__>>во-первых, что такое "границы" ?

E>Параметры, при которых меняется работа функции. Ветвления иначе происходят, переполнения и т. д...

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

__>>а во-вторых, таких граничных точек может быть тоже неподъемно много для обычных вычислений
E>Ну тут от функции зависит.
E>Обычно у нормальных функций это не так...

это слишком громкое заявление

__>>если проводить аналогию, то юнит-тесты позволят при компоновке электронных блоков отследить перегрузки на входах и выходах.
E>Скорее гарантируют соответствие блоков номиналам

по сути не очень отличается

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

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

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

P.S. тест даже на трех отбалдовых значениях уже на световые года убежал из каменного века.

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

__>вот этого я и не понимаю. если вы проверили sqrt(uint32_t x) для валидного данного x = 2, то это не значит, что для x = 101 все будет работать, ведь у вас может, например, из-за округлений, или ошибки в программе, которая не проявляет себя на четных числах, перестать работать. скорее уж нужно использовать случайное тестирование (случайным образом выбирается точка в пространтсве аргументов и производится тест для нее)

Окей. Автор алгоритма подозревает, что в нем может быть баг, стреляющий только на четных числах. Пишет тест для четных. Потом возникает подозрение, что чем больше аргумент функции, тем более относительная ошибка из-за накопления неточности в преставлении чисел с плавающей точкой. Пишем на этот случай тест.

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

L>>Не требуют они затрат. Пишутся на автомате.

__>

можете накидать на автомате для sqrt(uint32_t x)

ASSERT_EQ_WITHIN_E(0, sqrt(0), e);
ASSERT_EQ_WITHIN_E(1, sqrt(1), e);
ASSERT_EQ_WITHIN_E(2, sqrt(4), e);

ASSERT_EQ_WITHIN_E(A, sqrt(MAX_UINT32), e);

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

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

__>>вот этого я и не понимаю. если вы проверили sqrt(uint32_t x) для валидного данного x = 2, то это не значит, что для x = 101 все будет работать, ведь у вас может, например, из-за округлений, или ошибки в программе, которая не проявляет себя на четных числах, перестать работать. скорее уж нужно использовать случайное тестирование (случайным образом выбирается точка в пространтсве аргументов и производится тест для нее)

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

ну, так это же "пальцем в небо". и если достижение только в том, чтобы оформить такое тыкание пальцем в небо в виде отдельного программного компонента, то вроде ничего революционного

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

L>>>Не требуют они затрат. Пишутся на автомате.

__>>

можете накидать на автомате для sqrt(uint32_t x)

L>

L>ASSERT_EQ_WITHIN_E(0, sqrt(0), e);
L>ASSERT_EQ_WITHIN_E(1, sqrt(1), e);
L>ASSERT_EQ_WITHIN_E(2, sqrt(4), e);

L>ASSERT_EQ_WITHIN_E(A, sqrt(MAX_UINT32), e);
L>

понятно. а то, что при x = 0xfffffff1 могут начаться сказываться эффекты переполнения, это, конечно, должен дописать тот, кто в этом разбирается

а если такого нет, ну и фиг с ним. будем рапортовать, что функция оттестирована, и что все работает ок

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

__>ну, так это же "пальцем в небо". и если достижение только в том, чтобы оформить такое тыкание пальцем в небо в виде отдельного программного компонента, то вроде ничего революционного

Нет, не пальцем в небо. Программист пишет код. Он видит, какие могут быть сценарии выполнения. Пишет тесты для них. Я ж не зря неоднократно упоминал whie-box тестирование.

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

L>>>>Не требуют они затрат. Пишутся на автомате.

__>>>

можете накидать на автомате для sqrt(uint32_t x)

L>>

L>>ASSERT_EQ_WITHIN_E(0, sqrt(0), e);
L>>ASSERT_EQ_WITHIN_E(1, sqrt(1), e);
L>>ASSERT_EQ_WITHIN_E(2, sqrt(4), e);

L>>ASSERT_EQ_WITHIN_E(A, sqrt(MAX_UINT32), e);
L>>

__>понятно. а то, что при x = 0xfffffff1 могут начаться сказываться эффекты переполнения, это, конечно, должен дописать тот, кто в этом разбирается

Если эффекты есть, то выделенный тест их должен показать.

__>а если такого нет, ну и фиг с ним. будем рапортовать, что функция оттестирована, и что все работает ок

Рапортовать не надо. У вас есть набор юнит-тестов, которые в некотором смысле являются документацией к функции.

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

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

__>>ну, так это же "пальцем в небо". и если достижение только в том, чтобы оформить такое тыкание пальцем в небо в виде отдельного программного компонента, то вроде ничего революционного

L>Нет, не пальцем в небо. Программист пишет код. Он видит, какие могут быть сценарии выполнения. Пишет тесты для них. Я ж не зря неоднократно упоминал whie-box тестирование.

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

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

L>>>>>Не требуют они затрат. Пишутся на автомате.

__>>>>

можете накидать на автомате для sqrt(uint32_t x)

L>>>

L>>>ASSERT_EQ_WITHIN_E(0, sqrt(0), e);
L>>>ASSERT_EQ_WITHIN_E(1, sqrt(1), e);
L>>>ASSERT_EQ_WITHIN_E(2, sqrt(4), e);

L>>>ASSERT_EQ_WITHIN_E(A, sqrt(MAX_UINT32), e);
L>>>

__>>понятно. а то, что при x = 0xfffffff1 могут начаться сказываться эффекты переполнения, это, конечно, должен дописать тот, кто в этом разбирается

L>Если эффекты есть, то выделенный тест их должен показать.

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

__>>а если такого нет, ну и фиг с ним. будем рапортовать, что функция оттестирована, и что все работает ок

L>Рапортовать не надо. У вас есть набор юнит-тестов, которые в некотором смысле являются документацией к функции.

меня смущает, что все как-то нестрого, на усмотрение разработчика

нет системы...

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

__>>>ну, так это же "пальцем в небо". и если достижение только в том, чтобы оформить такое тыкание пальцем в небо в виде отдельного программного компонента, то вроде ничего революционного
L>>Нет, не пальцем в небо. Программист пишет код. Он видит, какие могут быть сценарии выполнения. Пишет тесты для них. Я ж не зря неоднократно упоминал whie-box тестирование.
__>понятно. но тогда, получается, тест может написать только автор кода. и если кто-то другой решит код переписать, то все тесты пойдут на смарку.

Э, нет. Что значит "переписать"? Имеющиеся тесты покажут, если вносимые изменения ломают поведение кода. Как раз при рефакторинге полезность тестов зачастую неоценима.

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

Отсутствие ошибок не гарантируют. Но гарантируют то, что в определенных условиях код выполняет именно то, что от него просят.

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

Добавь еще один в приграничную зону. Это бесплатно.

__>>>а если такого нет, ну и фиг с ним. будем рапортовать, что функция оттестирована, и что все работает ок

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

нет системы...

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

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

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

__>>>>ну, так это же "пальцем в небо". и если достижение только в том, чтобы оформить такое тыкание пальцем в небо в виде отдельного программного компонента, то вроде ничего революционного
L>>>Нет, не пальцем в небо. Программист пишет код. Он видит, какие могут быть сценарии выполнения. Пишет тесты для них. Я ж не зря неоднократно упоминал whie-box тестирование.
__>>понятно. но тогда, получается, тест может написать только автор кода. и если кто-то другой решит код переписать, то все тесты пойдут на смарку.

L>Э, нет. Что значит "переписать"? Имеющиеся тесты покажут, если вносимые изменения ломают поведение кода. Как раз при рефакторинге полезность тестов зачастую неоценима.

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

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

L>Отсутствие ошибок не гарантируют. Но гарантируют то, что в определенных условиях код выполняет именно то, что от него просят.

да, гарантируют, что
sqrt(0) = 0
sqrt(1) = 1
sqrt(4) = 2
sqrt(MAX_UINT32) = A;

и все...

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

L>Добавь еще один в приграничную зону. Это бесплатно.

для этого нужно додуматься, что такие эффекты могут быть, а это не тривиальная задача .

__>>>>а если такого нет, ну и фиг с ним. будем рапортовать, что функция оттестирована, и что все работает ок

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

нет системы...

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

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

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

__>ну, если я вместо итерационного алгоритма решил написать метод подбора корня квадратного, то все предыдущие тесты как бы становятся бесполезны, и нужны другие, которые специфичны именно для нового алгоритма.

Почему? Как раз нет, замена алгоритма не должна менять наблюдаемое поведение. Поэтому юнит-тесты незаменимы при рефакторинге.

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

__>да, гарантируют, что
__>sqrt(0) = 0
__>sqrt(1) = 1
__>sqrt(4) = 2
__>sqrt(MAX_UINT32) = A;

__>и все...

А что еще? Больше ничего не нужно. Реализация алгоритма должна обеспечивать, что если F(X_n) соответствует ожиданиям, то и F(X_n+1) им соответствует тоже. Индукция.

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

Что значит додуматься? Кто код-то пишет? Программист обязан понимать, какие могут быть граничные случаи применимости его конкретной реализации. Если это не так, то весь этот разговор смысла не имеет.

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

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

Что значит "можно"? Нужно. Так и делают. И прогоняют всегда, при каждой сборке.
Не нужны никакие метрики. Даже кое-как написанные тесты в 100500 раз лучше отсутствия тестов. Единственный разумный критерий для тестов — их поддержка не должна ничего стоить. А это обеспечивается соблюдением критериев тестируемости самого тестируемого года.

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

L>Что значит "можно"? Нужно. Так и делают. И прогоняют всегда, при каждой сборке.
Особенно забавно про это читать в теме, посвящённой тому, что даже билд без тестов слишком долог...

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

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

L>>>Рапортовать не надо. У вас есть набор юнит-тестов, которые в некотором смысле являются документацией к функции.

__>>меня смущает, что все как-то нестрого, на усмотрение разработчика

нет системы...

PM>Хм, похоже вы ищете серебряную пулю.

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

После того как начнете пользоваться юнит-тестами, почитайте про property-based testing: https://www.google.ru/search?q=quickcheck+c%2B%2B

PM>Например, https://github.com/thejohnfreeman/autocheck/wiki/Tutorial

спасибо, это уже ближе к моему представлению

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

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

__>>ну, если я вместо итерационного алгоритма решил написать метод подбора корня квадратного, то все предыдущие тесты как бы становятся бесполезны, и нужны другие, которые специфичны именно для нового алгоритма.

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

да, наверное так. согласен.

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

__>>да, гарантируют, что
__>>sqrt(0) = 0
__>>sqrt(1) = 1
__>>sqrt(4) = 2
__>>sqrt(MAX_UINT32) = A;

__>>и все...

L>А что еще? Больше ничего не нужно. Реализация алгоритма должна обеспечивать, что если F(X_n) соответствует ожиданиям, то и F(X_n+1) им соответствует тоже. Индукция.

про индукцию вы не говорили. это все меняет — появляется какой-то систематизированный подход к тестированию, наподобие — введите на области определения тестируемой функции частичный порядок, такой, что для каждой подцепи и некоторого свойства P(x) выполняется: если P(x) == true, то и P(next(x)) == true; если P(x) == false, то и P(next(x)) == false; тогда свойство P может выступать в качестве основы для построения теста по правилу P(x_0), где P(x_0) — минимальный элемент подцепи (база индукции).
так? а где про это написано и можно посмотнреть конкретные примерны такого подхода?

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

L>Что значит додуматься? Кто код-то пишет? Программист обязан понимать, какие могут быть граничные случаи применимости его конкретной реализации. Если это не так, то весь этот разговор смысла не имеет.

нет, я же уже приводил цитату:

Unit tests created in a test-driven development environment are typically created by the developer who is writing the code being tested. Therefore, the tests may share blind spots with the code: if, for example, a developer does not realize that certain input parameters must be checked, most likely neither the test nor the code will verify those parameters. Another example: if the developer misinterprets the requirements for the module he is developing, the code and the unit tests he writes will both be wrong in the same way

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

кстати, а что делать, если тип аргумента меняется (функцию переписали с uint32_t на double)? пересматривать тесты?

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

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

L>Что значит "можно"? Нужно. Так и делают. И прогоняют всегда, при каждой сборке.

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

L>Не нужны никакие метрики. Даже кое-как написанные тесты в 100500 раз лучше отсутствия тестов. Единственный разумный критерий для тестов — их поддержка не должна ничего стоить. А это обеспечивается соблюдением критериев тестируемости самого тестируемого года.

Unit_testing_limitations
в частности оттуда:

For example, every boolean decision statement requires at least two tests: one with an outcome of "true" and one with an outcome of "false". As a result, for every line of code written, programmers often need 3 to 5 lines of test code.[6] This obviously takes time and its investment may not be worth the effort.
[...]
In addition, code for a unit test is likely to be at least as buggy as the code it is testing. Fred Brooks in The Mythical Man-Month quotes: "Never go to sea with two chronometers; take one or three."[7] Meaning, if two chronometers contradict, how do you know which one is correct?

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

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

L>>>Что значит "можно"? Нужно. Так и делают. И прогоняют всегда, при каждой сборке.
E>>Особенно забавно про это читать в теме, посвящённой тому, что даже билд без тестов слишком долог...

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

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

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

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

L>>А что еще? Больше ничего не нужно. Реализация алгоритма должна обеспечивать, что если F(X_n) соответствует ожиданиям, то и F(X_n+1) им соответствует тоже. Индукция.

__>про индукцию вы не говорили. это все меняет — появляется какой-то систематизированный подход к тестированию,

Юнит-тесты — это не тестирование. Это подход к разработке. У них есть еще пара полезных побочных эффектов, о которых мы пока не говорили.

__>наподобие — введите на области определения тестируемой функции частичный порядок, такой, что для каждой подцепи и некоторого свойства P(x) выполняется: если P(x) == true, то и P(next(x)) == true; если P(x) == false, то и P(next(x)) == false; тогда свойство P может выступать в качестве основы для построения теста по правилу P(x_0), где P(x_0) — минимальный элемент подцепи (база индукции).
__>так? а где про это написано и можно посмотнреть конкретные примерны такого подхода?

Эээ... вот самый обычный пример

some_type sometihg_to_test(some_other_type data)
{
    if (check1(data))
    {
        // do some calculations
        return result;
    }
    else if (check2(data))
    {
        // do some other calculations
        return result;
    }
    else return do_nothing(data);
}

Вам нужно проверить поведение функции при условии попадания data в check1, check2 и когда ни в одно условие данные не попадают. При этом крайне желательно, чтобы код внутри ветвлений реализовывал некий монтонный алгоритм, без экстремумов, перегибов и прочих ветвлений. В таком случае индуктивное доказательство каждого ветвления тривиально.
Это, кстати, объясняет, почему юниты должны быть как можно более мелкими — дополнительные ветвление внутри каждого ветвления означает комбинаторный взрыв

__>нет, я же уже приводил цитату:
__>

__>Unit tests created in a test-driven development environment are typically created by the developer who is writing the code being tested. Therefore, the tests may share blind spots with the code: if, for example, a developer does not realize that certain input parameters must be checked, most likely neither the test nor the code will verify those parameters. Another example: if the developer misinterprets the requirements for the module he is developing, the code and the unit tests he writes will both be wrong in the same way

Тем не менее в случае с юнит-тестами это гораздо легче исправить, нежели в процессе, полагающемся только на полное фукнциональное тестирование. Во время код ревью достаточно указать, что некоторые условия не протестированы

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

Зависит от задачи. Может, клиенты юнита гарантируют, что MAX_UINT32 там никогда не будет подан на вход?
А вообще — все граничные условия должны тестироваться.

__>кстати, а что делать, если тип аргумента меняется (функцию переписали с uint32_t на double)? пересматривать тесты?

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

L>>Что значит "можно"? Нужно. Так и делают. И прогоняют всегда, при каждой сборке.

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

Серебряной пули нет. Метрики для тестов реализации логики зависят от собствено реализации.

L>>Не нужны никакие метрики. Даже кое-как написанные тесты в 100500 раз лучше отсутствия тестов. Единственный разумный критерий для тестов — их поддержка не должна ничего стоить. А это обеспечивается соблюдением критериев тестируемости самого тестируемого года.

__>Unit_testing_limitations
__>в частности оттуда:
__>

__>For example, every boolean decision statement requires at least two tests: one with an outcome of "true" and one with an outcome of "false". As a result, for every line of code written, programmers often need 3 to 5 lines of test code.[6] This obviously takes time and its investment may not be worth the effort.

При юнит-тестировании для каждого ветвления нужно всего 3-5 тестов. Всего.
Для того, чтобы покрыть все возможные ветвления функциональным тестом для системы, состоящей из N юнитов, в общем случае тестов понадобится N^3-N^5

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

L>Юнит-тесты — это не тестирование. Это подход к разработке. У них есть еще пара полезных побочных эффектов, о которых мы пока не говорили.

Юнит-тесты — это все-таки тестирование. А подход к разработке — это TDD.

Но это терминологический вопрос.

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

BFE>>>>Ну как "прекрасно". Может оказаться, что для этого надо затратить труд превосходящий по времени написание приложения.
L>>>Вот у нас, почему-то, не оказалось. Мы, наверное, что-то делаем неправильно.
BFE>>Наверное у вас датчики только одного (стандартизованного) типа.

L>Как ты думаешь, сколько типов датчиков поддерживает одна наиболее используемых в мире SCADA систем в мире?
Думаю, что сколько бы не поддерживали у них у вех унифицированный протокол обмена. А что?

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

L>>Как ты думаешь, сколько типов датчиков поддерживает одна наиболее используемых в мире SCADA систем в мире?
BFE>Думаю, что сколько бы не поддерживали у них у вех унифицированный протокол обмена. А что?

В общем, да. Только этих протоколов одних несколько сотен, если говорить о сколько-нибудь унифицированных хотя бы их производителем. Не говоря уже о вариантах каждого из них.
Даже industry standard протоколы существуют в нескольких вариантах, и при этом каждый производитель умудряется по-своему понять определенные пункты стандарта

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

L>>>Как ты думаешь, сколько типов датчиков поддерживает одна наиболее используемых в мире SCADA систем в мире?
BFE>>Думаю, что сколько бы не поддерживали у них у вех унифицированный протокол обмена. А что?
L>В общем, да. Только этих протоколов одних несколько сотен, если говорить о сколько-нибудь унифицированных хотя бы их производителем. Не говоря уже о вариантах каждого из них.
L>Даже industry standard протоколы существуют в нескольких вариантах, и при этом каждый производитель умудряется по-своему понять определенные пункты стандарта

Ok. И вы хотите сказать, что написание тестов перегрузки входными данными для всех комбинаций этого зоопарка заняли меньше времени, чем написание самого кода? Или у вас всё поверх IP написано?

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

BFE>Ok. И вы хотите сказать, что написание тестов перегрузки входными данными для всех комбинаций этого зоопарка заняли меньше времени, чем написание самого кода? Или у вас всё поверх IP написано?

Нам не нужно весь зоопарк тестировать. Только тот, который имеет возможность вызвать перегрузку. Для железа, до сих пор работющего по RS485, да на низком рейте, это почти нереально.
А вот для IP-based протоколов таки да. Там, где симуляторы были доступны (или написаны нами) симуляция перегрузки тривиальна. Там, где нет, ее можно эмулировать наиболее удобным для нас способом.

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

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

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

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

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

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

И как вообще тесты могут его заменить? И почему вообще тесты должны заменять дебагер? Тесты и дебагер выполняют разные функции:

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

Одно другому никак не мешает.

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

BFE>Никакое это не бинго. Речь о том, что даже ясную, простую и достаточно формальную задачу о тексте внутри кнопки невозможно протестировать, так как размер текста зависит от внешнего ресурса — шрифта, который может быть произвольным. Речь не идёт о прилагательных "хорошая", "удачная", "лучшая"...

UI с юнит-тестами вообще не особо дружит. Чисто идеологически.

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

BFE>>Никакое это не бинго. Речь о том, что даже ясную, простую и достаточно формальную задачу о тексте внутри кнопки невозможно протестировать, так как размер текста зависит от внешнего ресурса — шрифта, который может быть произвольным. Речь не идёт о прилагательных "хорошая", "удачная", "лучшая"...

E>UI с юнит-тестами вообще не особо дружит. Чисто идеологически.

Равно как "произвольный шрифт" к "хорошему UI" тоже особо не относится.

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

L>Равно как "произвольный шрифт" к "хорошему UI" тоже особо не относится.

Это ещё почему? Ровно наоборот: у людей разные вкусы, разные мониторы, разные предпочтения цветовой гаммы и разное зрение. Кто-то не может без clear type, а кто-то его ненавидит. Поэтому хороший UI должен быть подстраиваться под конкретного пользователя. А это, в числе прочего, предполагает и выбор подходящего шрифта.

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

BFE>Это заблуждение. Я думаю, что мне даже понятна психологическая составляющая неприятия разнообразия UI. Это неприятие отражено, например в этой вашей фразе:
BFE>

BFE>Даже industry standard протоколы существуют в нескольких вариантах, и при этом каждый производитель умудряется по-своему понять определенные пункты стандарта

BFE>Употребление слова "умудряется" свидетельствует о негативном отношении к разнообразию,

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

А вот нифига. Покажи мне пограммиста, которому было бы удобно работать с кодом, отображающимся не-моноширинным шрифтом.

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

Дизайнеры размещают кнопки и обеспечивают читаемость и понятность текста на них. Это не задача программиста.

	От:	landerhigh
	Дата:	28.04.16 12:34
	Оценка:	-3

От:	Pzz	https://github.com/alexpevzner
Дата:	28.04.16 12:38
Оценка:	1 (1) +2 -1

	От:	tdiff
	Дата:	29.04.16 11:17
	Оценка:	+6

	От:	tdiff
	Дата:	29.04.16 12:42
	Оценка:	6 (1) +3

	От:	Мёртвый Даун
	Дата:	04.05.16 04:15
	Оценка:	1 (1)

	От:	__kot2
	Дата:	29.04.16 12:05
	Оценка:	10 (2) -1

От:	jazzer	Skype: enerjazzer
Дата:	28.04.16 12:05
Оценка:	2 (1) +1

От:	Kernan	https://rsdn.ru/forum/flame.politics/
Дата:	28.04.16 11:23
Оценка:	+2

	От:	Stanislav V. Zudin
	Дата:	29.04.16 09:18
	Оценка:	+2

От:	Basil2	https://starostin.msk.ru
Дата:	29.04.16 14:01
Оценка:	+1

От:	Carc	http://www.amlpages.com/home.php
Дата:	28.04.16 12:25
Оценка:

От:	Andrew.W Worobow	https://github.com/Worobow
Дата:	28.04.16 13:15
Оценка:

От:	c-smile	http://terrainformatica.com
Дата:	28.04.16 14:51
Оценка:

	От:	B0FEE664
	Дата:	10.05.16 10:02
	Оценка:	+2