testing - сделать - отличие debug и release c++

В моей компании у нас есть как Debug, так и Release. - Разработчики используют отладочную версию для правильного поиска и исправления ошибок. - Мы используем TDD, поэтому у нас есть большой набор тестов, который мы запускаем на нашем сервере, который тестирует как конфигурацию отладки, так и выпуск, а также сборки 64/32, которые у нас есть.

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

Когда я разрабатываю Java, я ненавижу не-отладочные версии. Когда генерируется исключение, вы не получаете никакой информации о линии, что затрудняет или даже невозможно отслеживать ошибки. Кроме того, разница между временем отладки и отладки составляет около 5% при использовании Java 5 или более поздней версии, поэтому на самом деле это не проблема, а с сегодняшними жесткими дисками размер больше не имеет значения.

На стороне плюса с использованием отладочных версий:

• Трассировка стека содержит всю необходимую информацию.
• Переменные можно исследовать
• Если у вас возникли проблемы с производством, вы можете просто подключиться к выполняемому процессу, не останавливая сервер сначала для установки отладочной версии.
• Вы не поймаете умные ошибки оптимизации
• Сборка проще (всего один артефакт)

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

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

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

Наша политика заключается в том, чтобы разработчики работали над сборками Debug, но EVERYONE else (QA, BAs, продажи и т. Д.) Запускает версию. Вчера мне пришлось исправить ошибку, которая появилась только в релизе, она была очевидна, что происходило просто ПОТОМУ ЧТО это только появилось в выпуске

Это первый в этом магазине, и я здесь уже 18 месяцев.

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

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

По моему мнению, в этой дискуссии отсутствует очень важный момент:

Это действительно зависит от того, какой проект это!

Если вы создаете собственный (C / C ++) проект, вы будете вынуждены создавать отладочные сборки просто потому, что оптимизация компилятора может сделать отладку почти невозможной в некоторых случаях.

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

Хотя собственный проект на C ++ и веб-приложение PHP, очевидно, не все виды проектов, которые существуют, я надеюсь, что мой вопрос перевернулся.

PS: При разработке для C # вы сталкиваетесь с пограничным случаем, поскольку, хотя использование отладочной сборки отключает оптимизацию компилятора, по моему опыту вы не столкнетесь с почти такими же различиями, как с C ++

Смотрите это Что ваше самый противоречивое мнение программирования?

цитата:

Мнение: никогда не бывает другого кода между сборками «debug» и «release»

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

Согласно моему ответу в связанном потоке, мы также используем ту же самую сборку для отладки и выпуска по очень похожим причинам. Прирост 10% -20% от оптимизатора, как правило, очень незначительный по сравнению с ручными оптимизациями на уровне алгоритма. Одна сборка удаляет множество потенциальных ошибок. В частности,

• Неинициализированные переменные и небольшие переполнения буфера могут привести к совершенно другим результатам в отладочных и оптимизированных версиях.

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

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

Это компромисс. Учитывая, что циклы CPU дешевы и дешевле, а человеческие циклы остаются дорогостоящими, имеет смысл поддерживать только одну версию большой сложной программы - отладочной (gable) версии.

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

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

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

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

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

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

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

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

здесь мы развиваемся в режиме отладки и выполняем все модульные тесты в режиме выпуска. мы являемся небольшим магазином с несколькими (до 12) приложений для поддержки от классических ASP, ASP.Net, VB.Net и C #. У нас также есть преданный человек для обработки всех тестов, отлаженные проблемы отбрасываются разработчикам.