Здравствуйте, _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>При чём может и не на один порядок...

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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?

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

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

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

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

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

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

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

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

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

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

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

Это, скорее всего, must have, но это уже вопрос проектирования. И все эти запчасти, скорее всего есть уже готовые вообще.
Дальше нужна компоновка, проект UI, и т. д...

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

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

L>Возможно, только не в ту сторону, о которой ты подумал.. Тем более, что имхо сканирует не фотошоп, а драйвер сканера.
Фотошоп управляет драйвером.
Так скока типов датчиков? Сканеров тысяч 5 есть, если не больше...

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

L>>Отладчик — это самое крайнее средство. Как тот самый доктор, который все знает, все умеет, но приходит слишком поздно.
__>кхм.. а __kot2 говорил, что это скрипучая телега в век,к огда все ездят на машинах

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

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

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

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

__>тоже, можно примеры, когда он лишний?

Ну вычматы, например...