Здравствуйте, B0FEE664, Вы писали:
L>>Только это уже не юнит-тесты. BFE>Ну как "прекрасно". Может оказаться, что для этого надо затратить труд превосходящий по времени написание приложения.
Вот у нас, почему-то, не оказалось. Мы, наверное, что-то делаем неправильно.
L>>Время, кстати, тоже тестируется, если выбраны правильные уровни абстракции. BFE>Не совсем понятно, как вам помогут уровни абстракции и причём они тут. Багов связанных со временем очень много, они весьма разнообразны и встречаются во всех системах. Apple, MS и Unix страдают ими перманентно. Думаете многие готовы к проблеме 2038-ого года или хотя бы задумываются/знают о ней? А ведь осталось каких-нибудь 22 года.
Мы говорим о юнит-тестах для вновь написанного кода, а не системной ошибке.
Re[28]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, B0FEE664, Вы писали:
L>>Такой код может и должен быть протестирован. BFE>Может и должен. Что не отменяет того факта, что за всё время эксплуатации он никогда не будет вызван.
Только когда он будет вызван тот самый единственный и последний раз, протестированный код с бОльшей вероятностью поведет себя так, как вы ожидали.
BFE>Кстати, можете предложить не инвазивный способ тестирования?
Код рефакторится так, чтобы это можно было сделать не инвазивным способом. Ваш К.О.
BFE>>>Тесты, как средство управления проектом — ok, а вот как средство разработки — подходит не для всех задач. L>>Не подходит для крайне малого домена задач. BFE>Да ладно! Есть большие классы задач, которые сложно или крайне сложно протестировать. Давайте, предложите тест для проверки отрисовки, скажем, кнопки.
Легко. Формулируй критерий валидности отрисовки кнопки и задача сводится к предыдущей.
Критерий "нравится дизайнеру" не катит, как ты понимаешь.
Re[25]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, __kot2, Вы писали:
__>почти все сильные программисты, с которыми я когда-то работал по разны причинах, в разные компании, свалили из России. и вот остались по всей видимости те, кто остает от общего мирового тренда в разработке, лет, уже получается, на 10. это меня, конечно, удивило очень сильно, прямо мега-открытие. когда люди в 2016ом году говорят про девелоперов и тестеров, размышляют о преимуществах дебагера или о невозможности написания тестов — это сильно! это сильная заявка в мировые аутсайдеры разработки
Ух ты! Адепт использует приём "я модный и успешный". Оно, конечно, хорошо — быть д'Артаньяном, только вот Россию приплели не к месту. Я, например, давно уехал.
И каждый день — без права на ошибку...
Re[27]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>>>Только это уже не юнит-тесты. BFE>>Ну как "прекрасно". Может оказаться, что для этого надо затратить труд превосходящий по времени написание приложения. L>Вот у нас, почему-то, не оказалось. Мы, наверное, что-то делаем неправильно.
Наверное у вас датчики только одного (стандартизованного) типа.
L>>>Время, кстати, тоже тестируется, если выбраны правильные уровни абстракции. BFE>>Не совсем понятно, как вам помогут уровни абстракции и причём они тут. Багов связанных со временем очень много, они весьма разнообразны и встречаются во всех системах. Apple, MS и Unix страдают ими перманентно. Думаете многие готовы к проблеме 2038-ого года или хотя бы задумываются/знают о ней? А ведь осталось каких-нибудь 22 года. L>Мы говорим о юнит-тестах для вновь написанного кода, а не системной ошибке.
Не, ну с таким подходом конечно всё просто.
И каждый день — без права на ошибку...
Re[29]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>>>Такой код может и должен быть протестирован. BFE>>Может и должен. Что не отменяет того факта, что за всё время эксплуатации он никогда не будет вызван. L>Только когда он будет вызван тот самый единственный и последний раз, протестированный код с бОльшей вероятностью поведет себя так, как вы ожидали.
Значит удалять его не надо? Обнадёжили.
BFE>>Кстати, можете предложить не инвазивный способ тестирования? L>Код рефакторится так, чтобы это можно было сделать не инвазивным способом. Ваш К.О.
И получаем усложнение кода, что потенциально чревато новыми ошибками.
BFE>>Да ладно! Есть большие классы задач, которые сложно или крайне сложно протестировать. Давайте, предложите тест для проверки отрисовки, скажем, кнопки. L>Легко. Формулируй критерий валидности отрисовки кнопки и задача сводится к предыдущей.
К предыдущей — это которой?
L>Критерий "нравится дизайнеру" не катит, как ты понимаешь.
Критерий такой — текст кнопки не должен обрезаться или выходить за пределы кнопки с учётом всех таргет платформ и стилей.
И каждый день — без права на ошибку...
Re[28]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Ну как "прекрасно". Может оказаться, что для этого надо затратить труд превосходящий по времени написание приложения. L>>Вот у нас, почему-то, не оказалось. Мы, наверное, что-то делаем неправильно. BFE>Наверное у вас датчики только одного (стандартизованного) типа.
Как ты думаешь, сколько типов датчиков поддерживает одна наиболее используемых в мире SCADA систем в мире?
L>>Мы говорим о юнит-тестах для вновь написанного кода, а не системной ошибке. BFE>Не, ну с таким подходом конечно всё просто.
Конечно. Это системная проблема, пусть у ответственных за систему голова об этом болит для начала.
Re[30]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Может и должен. Что не отменяет того факта, что за всё время эксплуатации он никогда не будет вызван. L>>Только когда он будет вызван тот самый единственный и последний раз, протестированный код с бОльшей вероятностью поведет себя так, как вы ожидали. BFE>Значит удалять его не надо? Обнадёжили.
Если он протестирован — не надо.
BFE>>>Кстати, можете предложить не инвазивный способ тестирования? L>>Код рефакторится так, чтобы это можно было сделать не инвазивным способом. Ваш К.О. BFE>И получаем усложнение кода, что потенциально чревато новыми ошибками.
И получаем упрощение кода.
(Анекдот про стеклянный буй как нельзя к месту)
L>>Критерий "нравится дизайнеру" не катит, как ты понимаешь. BFE>Критерий такой — текст кнопки не должен обрезаться или выходить за пределы кнопки с учётом всех таргет платформ и стилей.
И при этом размер кнопки менять нельзя, да? Это и есть "нравится дизайнеру". Это не задача юнит-тестов, это задача для дизайнера.
Юнит тесты должны проверять четко формализованные критерии.
Re[26]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, B0FEE664, Вы писали: BFE>Ух ты! Адепт использует приём "я модный и успешный". Оно, конечно, хорошо — быть д'Артаньяном, только вот Россию приплели не к месту. Я, например, давно уехал.
а вы тут вообще причем?
Re[28]: Долгая компиляция на с++ - смерть для больших проект
__>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:
Юнит-тесты — не инструмент тестирования. Это инструмент разработки.
Впрочем, называть отладчик инструментом тестирования... можно, конечно....
Re[3]: Долгая компиляция на с++ - смерть для больших проектов?
__>ну так, это же "ужас-ужас-ужас" — превращать подготовку к компиляции в отдельную инженерную задачу. эдак со временем стоит ожидать появления "специалиста по предкомпиляционной подготовке с++ проекта".
Когда работал в Варгейминге (проект wot blitz), да и не только там, у нас в команде была позиция, которая так и называлась — build engineer. Собственно сейчас, средствами CMake, танчики собираются под всё (ios/win/android + все десктопы). У всех стоит IncrediBuild. 20 минут — полная пересборка проекта (без конвертации ресурсов).
Если у вас в одиночку получился столь большой проект, что вас парит время комипляции — то что-то тут не то. Или плохо накодили или не туда двигаетесь. Где-то тут, несколько лет назад, пробегал этюд товарища Nikov (правда для C#). Как обычным дженериком на 5 аргументов нагенерить 25 метров кода и ждать компиляции более 7 минут. Жаль не могу найти.
SD>>Настоящие неудобства большие/сложные проекты приносят, когда надо туда заливать большие изменения а не при компиляции =) __>по-моему, эти проблемы ортогональны
Это у вас просто мало опыта коммерческой разработки на больших проектах.
Re[31]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
BFE>>>>Кстати, можете предложить не инвазивный способ тестирования? L>>>Код рефакторится так, чтобы это можно было сделать не инвазивным способом. Ваш К.О. BFE>>И получаем усложнение кода, что потенциально чревато новыми ошибками.
L>И получаем упрощение кода.
Каким образом поменяв вызов обычной функции ввода вывода насложную конструкцию мы получим упрощение кода?
L>(Анекдот про стеклянный буй как нельзя к месту)
Вот-вот. Сначала применим неподходящий материал, а потом будем обращатся с нежностью. Умно!
L>>>Критерий "нравится дизайнеру" не катит, как ты понимаешь. BFE>>Критерий такой — текст кнопки не должен обрезаться или выходить за пределы кнопки с учётом всех таргет платформ и стилей.
L>И при этом размер кнопки менять нельзя, да?
Можно. L>Юнит тесты должны проверять четко формализованные критерии.
И?
И каждый день — без права на ошибку...
Re[25]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, __kot2, Вы писали:
BFE>>Бывает так, что в сложных, развитых проектах некоторые части кода не вызываются никогда за время эксплуатации (даже при массовом использовании). __>и этот код должен быть удален
Значит ли это, что обработка ошибок из стабильной программы должна быть удалена?
__>когда у вас не только Вася и Петя, а команда человек 20, вносящая хаотичные правки, то вам уже на самом деле без разницы на демагогию про что можно, а что нельзя, для вас написание юнит тестов будет единственным способом релизить проект во вменяемом состоянии. а по интересному стечению обстоятельств именно именитые говнокодеры будут ныть, что тесты писать долго и д-но будут выдавать очень запутанные невероятно гигантские тесты, которые еще и ничего не тестируют. потому что тестировать говнокод очень сложно.
Можно просто регрессивные тесты по подсистемам...
__>я же пишу это не просто из своих фантазий, это правда жизни. если вы говнокодер, то вы будете писать огромные невменяемые тесты к своему коду. только за это я бы уже увольнял людей. профнепригодность. так как говнокодеры люди не глупые, сами понимают обьем работ, то увольнять уже можно за нытье о том, что это сделать невозможно или очень сложно и непонятно зачем.
От задач зависит. Есть такие, где юнит-тесты хорошо работают, а есть такие, где почти бесполезны...
Если поведение очень сложное, то юнит-тестирвание всех запчастей даст процентов 10 надёжности, а функциональное тестирование всего в сборе — сложное.
Это мы не говорим ещё о таких вещах, как data-driven AI.
Вот пишешь ты AI, которое рожи на фейсбучке ищет и отождествляет, и надо гарантировать, что бы негров на обезьян не матчили и т. п.
И как ты это юнит-тестами обеспечишь?
__>кстати, никогда нельзя давать написание тестов другим людям. говнокодер сам должен писать тест на свой код. а то он будет перекладывать проблемы с больной головы на здоровую.
С другой стороны, разным людям можно разные KPI выставить. Одному платить за релизы, а второму -- за выявленные ошибки
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[25]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, __kot2, Вы писали:
__>почти все сильные программисты, с которыми я когда-то работал по разны причинах, в разные компании, свалили из России. и вот остались по всей видимости те, кто остает от общего мирового тренда в разработке, лет, уже получается, на 10. это меня, конечно, удивило очень сильно, прямо мега-открытие. когда люди в 2016ом году говорят про девелоперов и тестеров, размышляют о преимуществах дебагера или о невозможности написания тестов — это сильно! это сильная заявка в мировые аутсайдеры разработки
ЧСВ атакует, однако...
1) Есть задачи, где юнит-тесты, аджайл и прочее итерактивное программирование рулят. Обычно это код не особо наукоёмкий, но зато много работы для программиста. А есть задачи, где главные затраты — НИР. И там юнит-тесты, обычно, малополезны...
Вот надо тебе сделать ПО к коробасу или роботу в машину, в те же деньги, что раньше, но плавнее и ресурс что бы зря не жечь. Что-то в железе надо делать, что-то в ПО, и чего?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[23]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>На практике это означает, что достаточно того, что написаны тесты, которые проверяют поведение вокруг всех ветвлений, переполнения и т.п., и на некоем ограниченном наборе валидных данных.
Ну вот расскажи, например, как обеспечить работу спам-фильтра таким образом? Или, например, фильтра, который вылавливает в трафике письма арабских террористов и стучит в ЦРУ и ФБР...
Юнит-тесты -- это обратная сторона отказа от assert's в релизной версии кода. В каком-то смысле одно заменяет другое.
Это может гарантировать какой-то уровень стабильности и очень простой функционал. Ну, вроде того, что функция сортировки таки сортирует.
Если поведение сложное, скажем какой-то генетический алгоритм, то обеспечения общей стабильности и функционала базовых примитивов недостаточно
Бывают проблемы сложнее, "ошибка в ветвлении". Ну, например, выбрали не ту условно-устойчивую конечно-разностную схему и в каком-то РЕАЛЬНОМ режиме, утратили аппроксимацию. И привет, реактор пошёл в разнос или МБР полетела не туда...
L>И еще немаловажная вещь — программист должен очень хорошо понимать, что именно он делает, для того, чтобы написать хороший код и тесты к нему.
Это +100500!
Тока начиная с некоторого уровня неспособность это сделать без юнит-тестов означает проф. непригодность...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[25]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>Время, кстати, тоже тестируется, если выбраны правильные уровни абстракции.
от железа зависит...
Если пишешь управление чем-то таким быстрым, да ещё и с ограничением по скорости эффекторов и самого проца, ну, например, ПО для С-400, скажем, то увы, точную модель сделать может быть дороже, чем время от времени осуществлять "прогон" путём отстрела тестовой ракеты по мишени
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[27]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>Не подходит для крайне малого домена задач.
Как измеряешь мощность доменов?
Весь AI и UI, как минимум, юнит-тестами покрываются плохо...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, _hum_, Вы писали:
__>ну, раз так (если тес ты — не для поиска ошибок, а для проверки соответствия функциональным требованиям), тогда зачем же вы тут дружно с __kot2 пытаетесь нас заставить отказаться от дебагера?
Ну дебагер часто и правда лишний...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[25]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, __kot2, Вы писали:
__>смотрите сериал "физрук"? там есть такой персонаж — Усач. ух, извращенец, меня аж всего передергивает когда он там начинает то с баяном, то еще с чем красоваться. но персонаж яркий! мне он нравится, крассный актер, офигенная находка. за людьми, которые сидят в дебагере, прикольно наблюдать, но работать с ними — нет, не сложно, а, если точнее, невыносимо
__>вспоминая еще одного персонажа — как говорил Гомер Симпсон — "это противоествественно. и должно быть противозаконно!"
Тоже от задач зависит...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[28]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, B0FEE664, Вы писали:
BFE>Кстати, можете предложить не инвазивный способ тестирования?
RAM-диск с драйвером, позволяющим эмулировать проблемы...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[27]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>Вот у нас, почему-то, не оказалось. Мы, наверное, что-то делаем неправильно.
От задачи зависит.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
это сильная заявка в мировые аутсайдеры разработки
