Здравствуйте, landerhigh, Вы писали:
L>Легко. Формулируй критерий валидности отрисовки кнопки и задача сводится к предыдущей. L>Критерий "нравится дизайнеру" не катит, как ты понимаешь.
А критерий "пользователь испытывает дикий восторг от красивого и удобного интерфейса" катит?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[29]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>Как ты думаешь, сколько типов датчиков поддерживает одна наиболее используемых в мире SCADA систем в мире?
Думаю, что меньше, чем число моделей сканеров, которым хорошо умеет сканировать фотошоп...
При чём может и не на один порядок...
А теперь задачка попроще, мы хотим сделать небольшую дешевую прогу, которая сканирует ЛЮБЫМ сканером фотку без вопросов и публикует её в альбоме.
Как будем тестировать совместимость со всем зоопарком сканеров?
L>Конечно. Это системная проблема, пусть у ответственных за систему голова об этом болит для начала.
Обычно хочется в конце продаваемый, или, хотя бы внедряемый результат иметь, а не идеальную систему поиска виноватого в срыве разработки...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[31]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>Юнит тесты должны проверять четко формализованные критерии.
Бинго! Есть КУЧА ПО, критерии на который плохо поддаются формализации
Например, "Хорошая игрушка", "удачная стиральная машина", "лучшая в мире система ПВО" и т. д...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[29]: Долгая компиляция на с++ - смерть для больших проект
L>Нужно просто помнить, что юнит-тесты верифицируют поведение отдельных юнитов в контролируемых условиях. То, что шасси самолета были протестированы на посдочных нагрузках и двигатели на стенде выдают обещанные ньютоны тяги, вовсе не гарантируют, что самолет полетит. С другой стороны, никто не строит самолет из копмонентов, которые не были протестированы по отдельности.
Тут +100500
L>Юнит-тесты — не инструмент тестирования. Это инструмент разработки.
Тут вопрос в том, какая часть всей разработки может быть сделана в TDD стиле...
Есть задачи, где под 100%, а есть где и 10% может не набраться...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[29]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, 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>Впрочем, называть отладчик инструментом тестирования... можно, конечно....
и использовать совместно с юнит-тестами
Re[25]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, _hum_, Вы писали:
L>>>И еще немаловажная вещь — программист должен очень хорошо понимать, что именно он делает, для того, чтобы написать хороший код и тесты к нему.
__>>ну, раз так (если тес ты — не для поиска ошибок, а для проверки соответствия функциональным требованиям), тогда зачем же вы тут дружно с __kot2 пытаетесь нас заставить отказаться от дебагера?
L>Потому что вы используете отладчик не по назначению. И очень часто последствия этого приходится разгребать в том числе и нам.
ммм... а где я успел рассказать, как я его использую?
и потом, хотелось бы услышать, что значит в вашем понимании использовать по назначению (просто из обсуждения как бы сложилось впечатление, что вы с __kot2 вообще его отвергаете)
Re[25]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, _hum_, Вы писали:
__>>ну, раз так (если тес ты — не для поиска ошибок, а для проверки соответствия функциональным требованиям), тогда зачем же вы тут дружно с __kot2 пытаетесь нас заставить отказаться от дебагера?
E>Ну дебагер часто и правда лишний...
тоже, можно примеры, когда он лишний?
Re[4]: Долгая компиляция на с++ - смерть для больших проектов?
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, _hum_, Вы писали:
__>>ну так, это же "ужас-ужас-ужас" — превращать подготовку к компиляции в отдельную инженерную задачу. эдак со временем стоит ожидать появления "специалиста по предкомпиляционной подготовке с++ проекта".
SaZ>Когда работал в Варгейминге (проект wot blitz), да и не только там, у нас в команде была позиция, которая так и называлась — build engineer. Собственно сейчас, средствами CMake, танчики собираются под всё (ios/win/android + все десктопы). У всех стоит IncrediBuild. 20 минут — полная пересборка проекта (без конвертации ресурсов).
и вы считаете это естественным? а что будет через пару лет, когда объем проектов во много раз возрастет?
SaZ>Если у вас в одиночку получился столь большой проект, что вас парит время комипляции — то что-то тут не то. Или плохо накодили или не туда двигаетесь. Где-то тут, несколько лет назад, пробегал этюд товарища Nikov (правда для C#). Как обычным дженериком на 5 аргументов нагенерить 25 метров кода и ждать компиляции более 7 минут. Жаль не могу найти.
ну и? что в таком случае делать?
да и вообще, почему программиста должны заботить проблемы компилятора, и он должен знать все эти нюансы с тем, где он как-то там проходит, что подключает и проч., чтобы не дай бог не ввести его в глубокую рекурсию.
Здравствуйте, _hum_, Вы писали: __>У меня он пока средний — около 2 Mb в архиве, и уже сейчас время перекомпиляции — около 20 минут
Как правильно делать написали уже много, а я напишу как сделать быстро.
1) Создаем и добавлем в проект 2 файла
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
Re[24]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
L>>И еще немаловажная вещь — программист должен очень хорошо понимать, что именно он делает, для того, чтобы написать хороший код и тесты к нему.
E>Это +100500! E>Тока начиная с некоторого уровня попытка это сделать без юнит-тестов означает проф. непригодность...
fixed.
Re[26]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, _hum_, Вы писали:
__>>>ну, раз так (если тес ты — не для поиска ошибок, а для проверки соответствия функциональным требованиям), тогда зачем же вы тут дружно с __kot2 пытаетесь нас заставить отказаться от дебагера? L>>Потому что вы используете отладчик не по назначению. И очень часто последствия этого приходится разгребать в том числе и нам. __>ммм... а где я успел рассказать, как я его использую?
В самом первом сообщении в этой теме.
Re[24]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
L>>На практике это означает, что достаточно того, что написаны тесты, которые проверяют поведение вокруг всех ветвлений, переполнения и т.п., и на некоем ограниченном наборе валидных данных. E>Ну вот расскажи, например, как обеспечить работу спам-фильтра таким образом?
Спам-фильтр у нас как выглядит? void filter_spam()?
Или все же состоит из мелких тестируемых модулей? Вот их-то и надо тестировать.
Не надо думать, что спам-фильтры принадлежат какому-то особенному домену. Они так же строятся из модулей, каждый из которых имеет некоторе наблюдаемое и, как правило, четко формализуемое поведение.
E>Или, например, фильтра, который вылавливает в трафике письма арабских террористов и стучит в ЦРУ и ФБР...
То же самое.
E>Юнит-тесты -- это обратная сторона отказа от assert's в релизной версии кода. В каком-то смысле одно заменяет другое. E>Это может гарантировать какой-то уровень стабильности и очень простой функционал. Ну, вроде того, что функция сортировки таки сортирует.
Если функция сортировки не сортирует, спам-фильр тестировать несколько рановато.
Re[26]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
L>>Время, кстати, тоже тестируется, если выбраны правильные уровни абстракции. E>от железа зависит... E>Если пишешь управление чем-то таким быстрым, да ещё и с ограничением по скорости эффекторов и самого проца, ну, например, ПО для С-400, скажем, то увы, точную модель сделать может быть дороже,
А может и не стоить.
Всегда можно выбрать подход и базис для тестирования, даже если полноценное тестирование на макете провести по каким-то причинам нельзя.
Re[28]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
L>>Критерий "нравится дизайнеру" не катит, как ты понимаешь. E>А критерий "пользователь испытывает дикий восторг от красивого и удобного интерфейса" катит?..
Катит. Если пользователя можно подключить электродами к компьютеру и залить в репозиторий.
Re[27]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, _hum_, Вы писали:
__>>>>ну, раз так (если тес ты — не для поиска ошибок, а для проверки соответствия функциональным требованиям), тогда зачем же вы тут дружно с __kot2 пытаетесь нас заставить отказаться от дебагера? L>>>Потому что вы используете отладчик не по назначению. И очень часто последствия этого приходится разгребать в том числе и нам. __>>ммм... а где я успел рассказать, как я его использую?
L>В самом первом сообщении в этой теме.
там только фраза:
"Все бы ничего, но невозможно же дебаггинг проводить — одно исправление — и опять длительное ожидание перекомпиляции."
кстати, "дебаггинг" не только работа под дебагером, но и просто поиск ошибок в коде.
Re[28]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, _hum_, Вы писали:
__>"Все бы ничего, но невозможно же дебаггинг проводить — одно исправление — и опять длительное ожидание перекомпиляции." __>
Этого достаточно. Свеженаписанному коду дебаггинг не нужен. Ему нужна верификация.
__>кстати, "дебаггинг" не только работа под дебагером, но и просто поиск ошибок в коде.
Если же вести "просто поиск", то зачем тогда ждать компиляции?
Re[29]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, 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>Если же вести "просто поиск", то зачем тогда ждать компиляции?
потому что их надо исправить и проверить, что после исправления все заработало, как надо
Re[30]: Долгая компиляция на с++ - смерть для больших проект
L>>Юнит-тесты — не инструмент тестирования. Это инструмент разработки. E>Тут вопрос в том, какая часть всей разработки может быть сделана в TDD стиле... E>Есть задачи, где под 100%, а есть где и 10% может не набраться...
Скорее, где поленились остальные 90% хоть как-то формализовать
