Считается ли «плохой практикой» проверка содержимого / кодировки файла в модульных тестах?

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

• По какой-то причине файл ASCII был закодирован в UTF-16 (коллега прислал мне по электронной почте файл, который мог его вызвать).
• В сценарии отсутствовали начальные SETоператоры (это требовалось из-за некоторых драйверов при работе, но не при локальной установке).

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

Однако, когда я нажал этот код, ко мне подошел другой коллега (который также является руководителем нашей команды) и сказал, что я не должен делать эти вещи снова, потому что:

«Эти вещи не входят в юнит-тесты»

«Модульные тесты должны использоваться только для проверки потока вашего кода»

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

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

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

Технически, это не юнит-тест, а скорее этап валидации. Правильный подход действительно зависит от того, каким должен быть ваш рабочий процесс. Ваш руководитель команды правильно определил цель юнит-тестов. Я чувствую, что это случай использования неправильного инструмента для работы, которая все еще должна быть сделана. Итак, начнем с этого:

Какую проблему я пытаюсь решить?

По описанию необходимо подтвердить, что любые сценарии базы данных соответствуют некоторым стандартам.

Какие инструменты / процессы доступны для решения проблемы?

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

Если вы сделаете эту часть своей инфраструктуры сборки, например, включите ее в Jenkins или что-то в этом роде, ее можно будет применить ко всем файлам SQL в вашем проекте.

Модульные тесты решают проблему только для вашего текущего файла.

Как мне сообщить о необходимости инструмента?

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

Руководитель вашей команды может иметь некоторые идеи, которые вы (или я) не учли, которые могут решить проблему более правильно.

Неправильно называть тесты, обращающиеся к файлам, «Модульными тестами».

Он: «Эти вещи не относятся к юнит-тестам»

Вы: «Имеет смысл, но я не мог найти лучшего места, чтобы положить их. Где они принадлежат?»

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

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

Майкл Фезерс говорит об этом в своей книге «Эффективная работа с устаревшим кодом»:

В отрасли люди часто спрашивают, являются ли конкретные тесты юнит-тестами. [...] Я возвращаюсь к двум качествам: тест проходит быстро? Может ли это помочь нам быстро локализовать ошибки?

Поможет ли ваш тест локализовать ошибки быстро и быстро? Если да, то сделай это! Если нет, то не надо! Это так просто!

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

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

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

Мой собственный термин для них - ресурсные тесты . ИМХО, они полностью оправданы, если выполняются ночью на CI-сервере: затраты минимальны и при разумном использовании явно повышают ценность. Одно из разумных определений : если тест проверяет проблему, вызвавшую проблему (например, кодировку, которую вы упоминаете).

Модульный тест - это тестирование метода или «модуля» кода. Вы тестируете наименьшую группу логики и кода в своем программном обеспечении.

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

Я надеюсь, что руководитель вашей команды поддержал вашу инициативу и должен был предложить альтернативные предложения. У вас определенно есть правильная идея.

Ваш SQL является кодом, как любой другой язык более низкого поколения, такой как C # или Java, и должен быть протестирован как таковой. А верификация и валидация относятся ко всем уровням тестирования. Таким образом, операторы кодирования и SET включены, но не обязательно проверяются исключительно. Обычные вещи, такие как окончания строк или огибающие, вы можете просто использовать ловушку SCM или функцию.

Лучшая практика состоит в том, чтобы иметь регрессионные тесты, чтобы гарантировать, что прошлые ошибки не будут повторно введены. Как правило, тесты создаются вместе с любым исправлением ошибки. Если эти ошибки не охватываются регрессионными тестами на уровне модуля / интеграции или системы, а затем вновь вводятся, то это проблема коллектива, проблема процесса, а не отдельная проблема.

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

Возвращаясь к отсутствующим инструкциям SET - они помогают проинформировать о множестве возможностей ввода и вывода для проверки. Какой тест вы бы написали, если бы вы потеряли какой-либо выбранный SET, если бы он пропустил?

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

Но вы, вероятно, не просто имеете файлы, у вас также есть некоторый код, который читает файлы. Вы можете написать модульный тест для этого кода. В приведенном выше примере функция чтения одного из шести изображений возвращает изображение 1024 x 1024 в память (или что бы оно ни предполагалось).

В любом случае, это может быть не модульный тест, но это полезный тест. И если вы используете платформу модульного тестирования, которая позволяет вам провести полезный тест (который не является модульным тестом), почему бы не использовать платформу модульного теста?

Возможно, я неправильно понимаю вашу проблему, но для меня это звучит как проблема, которая не должна быть захвачена каким-либо специальным тестом, а просто системой контроля версий . Любые изменения в кодовой базе должны проверяться на основе исправлений до внесения изменений. Простой способ сделать это в git - добавить изменения

git add -p

При каждом изменении текстового файла рабочий каталог спросит вас, действительно ли вы хотите его сохранить. Это позволит вам увидеть, например, удаление этих «начальных SETутверждений».

В случае изменения кодировки всего файла произойдет нечто иное: алгоритм не сможет различить старый и новый файл и, следовательно git add -p, вообще ничего не добавит. Затем это будет видно в другой команде, которую я буду делать перед любым коммитом, а именно

git status

Здесь вы увидите файл выделен красным цветом, указывая , что есть изменения. Изучение причин, по которым они этого не сделали git add -p, быстро выявило бы проблему.

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

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

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

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

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

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

Таким образом, вопрос на самом деле (должен быть в вашем контексте) больше о том, когда и как эти тесты выполняются, чем они являются.

В прошлом я широко использовал подобные тесты - они спасли нас от боли.

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

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

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

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