Я хотел бы отправить тестовый код вместе с продуктом. В частности, предоставьте опцию, чтобы любой, у кого есть копия нашей программы, мог нажать кнопку «самопроверка» или пройти --self-test в командной строке и выполнить полный набор модулей | интеграционные тесты.
В основном я хочу сделать это, чтобы помочь отладить проблемы, обнаруженные в полевых условиях, поэтому, когда конечный пользователь получает отчет об ошибке, есть вероятность, что он будет поддержан «а также, эти три теста не пройдены на моей машине». Я бы хотел, чтобы ручные тестеры могли запустить устройство | интеграционные тесты.
Тем не менее, команда экспертов считает, что тестовый код не является рабочим кодом и, следовательно, не должен быть отправлен. Я не совсем понимаю этот аргумент, так как большинство проектов с открытым исходным кодом поставляют набор тестов. Это кажется необычным в закрытом программном обеспечении.
Я хотел бы поддержать доказательства или анекдоты для любой стороны аргумента. Я решил, какой сайт обмена стека будет наиболее подходящим, но, пожалуйста, дайте мне знать, если это неуместно.
источник
Ответы:
Иногда тестовый код содержит фрагменты кода сторонних разработчиков, как внешних, так и внутренних для вашей компании. Это происходит из-за ошибок в файлах пользователей; ваши тесты (такие как регрессионные тесты) затем включают код, предоставленный ими для воспроизведения. Часто лицензирование таких фрагментов кода для воспроизведения ошибок неясно. Итак, вы должны знать о проблемах интеллектуальной собственности. Вы не хотите отправлять тестовый код, который случайно раскрывает некоторые коммерческие секреты или интеллектуальную собственность другого отдела вашей компании или ваших внешних партнеров.
С другой стороны, тестовый код редко соответствует стандартам производственного кода: обзоры кода не обязательно выполняются; не соблюдаются стандарты кодирования и т. д. Это, к сожалению, обычное явление, и оно не обязательно плохо отражается на группе тестирования, если у них не было этой цели на момент разработки этих тестов.
С другой стороны, многие тесты просто смущают плохо, и даже не проверяют то, что некоторые считают тестом. Это другая проблема ...
В конечном счете, из-за всех этих факторов вы можете классифицировать свои тесты как те, которые могут быть отправлены
с открытым исходным кодом, и те, которые просто не могут. (Возможно, вы захотите написать несколько пользовательских тестов, помня о них, медленно перенося другие в этот набор.)источник
Доставка тестов? Да. Отгрузочные юнит-тесты? Нет.
Как вы говорите в комментарии, проблема, с которой вы можете столкнуться при запуске продукта на клиентском компьютере, будет включать такие проблемы, как связывание с неправильной DLL-библиотекой, как правило, это не то, что выловит юнит-тест (который, несомненно, высмеял dll проверить код).
Теперь, поставляя комплект интеграционных тестов, который вызывает пользовательский интерфейс, который вызывает логику, которая вызывает DLL ..., это будет работать намного лучше. Интеграционные тесты могут показать другие аспекты неудачных установок, которые не будут отображаться в модульных тестах. (Например, мой текущий продукт требует установки кодеков k-lite, которые мы не можем связывать из-за лицензирования. Модульные тесты могут показать, что наш код работает нормально, но все еще не работает для удовлетворения потребностей клиентов. Аналогично, наша конфигурация кодеков может не сработать корректно, модульные тесты также не покажут этого).
Итак, вместо этого поставьте некоторые из ваших интеграционных тестов, которые будут именно тем, что вы хотите для установленного, интегрированного продукта.
источник
Я мог бы четко понять эту проблему в тех областях, где вы охватываете каждый дюйм аппаратного обеспечения, например, многопоточный игровой движок нового поколения AAA, который использует каждое ядро процессора, встроенные SIMD, GPU, GPGPU и т. Д., Обеспечивая при этом кроссплатформенность. продукт.
В этих случаях вашим худшим кошмаром часто будут те случаи, когда ваши тесты (модуль и интеграция) пройдут для первых 5000 протестированных машин / платформ, но не пройдут для 5 001-й из-за ошибки драйвера для малоизвестной модели графического процессора. Просто подумайте это вызывает у меня дрожь - вы не можете проверить или предвидеть это заранее.
Особенно, если вы пишете шейдеры для GPU, вы можете закончить розыгрышем в виде обратной лотереи, когда половина написанного вами кода вызовет неопределенное поведение, поскольку существует мало портативных стандартных гарантий, которые применяются всеми задействованными моделями / драйверами GPU. Хотя в наши дни становится все меньше и меньше, как играть в тральщика, это должно дать людям представление: http://theorangeduck.com/page/writing-portable-opengl . Попытка сделать это в конце 90-х и начале 2000-х была поистине ужасной, и это был тральщик на всем пути.
В таких случаях часто требуются группы из более чем 10 000 тестировщиков с действительно широким спектром оборудования и операционных систем, чтобы действительно укрепить продукт и почувствовать уверенность в нем до стабильной версии. Не все компании могут позволить себе иметь такую широкую базу тестов, и не у всех есть дисциплина, чтобы сделать это правильно (все широко заметные проблемы должны быть решены до того, как столько тестеров будет на какой-то внутренней стадии до альфа / альфа или иначе поток избыточных отчетов может привести разработчиков в паническое состояние.
В этом случае я рекомендую то, что предложили другие, сосредоточиться на распределенном наборе интеграционных тестов. Вы можете связать его с установщиком, требуя, чтобы пользователи проходили базовую диагностическую проверку с внимательным вниманием к предоставлению подробной информации о том, почему установка не удалась, и что они могут передать вам, разработчикам.
Еще одна вещь (если вы можете убедить начальника) - это иметь в наличии широкий спектр оборудования для непрерывной интеграции. Чем больше разнообразия в аппаратных / ОС комбинациях, тем лучше. Вам нужно даже различное дерьмовое оборудование, которое моделирует минимальные требования к оборудованию для ваших CI-серверов: вы никогда не знаете.
Но есть еще одна вещь, которую я бы предложил:
логирование
Если вы имеете дело с чем-то похожим на сценарий, который я описал выше, то часто вы не можете проверить эти вещи, которые, как правило, являются наиболее проблематичными (те худшие возможные ошибки, которые обнаруживаются в наихудшее возможное время и не могут проявиться даже в наиболее исчерпывающий набор тестов, поскольку эта проблема ограничена очень специфической комбинацией оборудования / ОС).
Тем не менее, большинство таких проблем, как неясная несовместимость аппаратного обеспечения или явные сбои драйверов или связывание с неправильным дистрибутивом (я никогда не сталкивался с этой проблемой), не дадут вам далеко пройти запуск программного обеспечения. Грубо говоря, он скоро рухнет и сгорит.
Ради здравого смысла я рекомендую принять неизбежное. Вы ничего не можете сделать с этими вещами, которые вы не можете проверить всесторонне. Не пытайтесь предотвратить ураган (невозможно), но загляните в эти окна.
Как правило, здесь лучшее, что мы можем сделать, - это выяснить проблему как можно скорее, где она возникает как можно более подробно (чтобы сузить наш список подозреваемых), и устранить проблему как можно скорее после ее сообщения.
В этом случае регистрация может быть спасителем. Для таких полей вы можете создавать такие технические журналы спама, которые никто никогда не будет читать. Часто релевантной является только самая последняя строка, записанная в журнале до того, как пользователь столкнулся со сбоем из-за сбоя драйвера, например, Вы можете написать внешний процесс или ловушку, которая отслеживает сбои, а затем показывает последнюю строку журнала, которую пользователи могут скопировать и вставьте вам, например, в дополнение к аварийному дампу.
Поскольку для этого часто требуется детализированная информация, а множество наиболее уязвимых областей кода для решения этих проблем с оборудованием / платформой / драйвером является критически важным для производительности, существует такая неловкая проблема, когда ведение журнала может происходить с такой частой скоростью, что на самом деле оно будет медленным вниз по программному обеспечению.
Полезный трюк в этом случае состоит в том, чтобы полагаться на предположение, что что-то выполненное один раз будет успешно выполнено во второй раз, в третий раз и т. Д. Это не самое правильное предположение, но часто это «достаточно хорошо» (и бесконечно лучше, чем ничего) , При этом вы можете использовать немного внешнего состояния, чтобы отслеживать, когда что-то уже зарегистрировано, и пропустить последующие попытки войти в систему для тех действительно гранулированных случаев, когда код будет вызываться повторно в цикле.
Во всяком случае, я надеюсь, что это поможет. Я сталкивался с подобным искушением в прошлом и испытываю некоторую паранойю вокруг кодирования GPU (GPGPU и шейдеров) в результате некоторого прошлого опыта между мной и моей командой (иногда просто видя, как другие члены команды действительно занимаются этим Позднее и после релиза у меня возникли проблемы, как некоторые ошибки ATI в конкретной модели Radeon, которые приводили к сбою при рендеринге сглаженных линий, позже сообщалось и отмечалось как известная проблема только с доступным обходным решением).
Ведение журнала было тем, что спасло нас от пота, позволяя нам часто видеть проблему на 10,001-м непонятном прототипе машины с встроенным графическим процессором, о котором мы никогда не слышали, а последняя строка кода сразу же позволила нам точно определить, где произошел сбой до 2 или 3 строки кода в качестве подозрительных, например, если он находится внутри сложного шейдера, мы вроде SOL, так как мы не можем вести логирование внутри шейдера GPU, но мы можем, по крайней мере, использовать логирование, чтобы увидеть, какой шейдер имел проблему прямо сейчас начать расследование.
источник