Всегда ли нормально не тестировать функцию?

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

Чтобы уточнить дальше, ясно, что это всегда безопаснее тестировать. Однако есть ли способ определить, когда риск настолько минимален, что тестирование не стоит затраченных усилий? Другой способ выразить это: когда или когда-либо в профессиональной практике брать на себя взвешенный риск для реализации функции?

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

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

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

Давайте начнем с того, что немного разберемся с этим.

Обновления

У вас есть система, и вы собираетесь обновить ее полностью или частично. Например, обновление экземпляра с SQL Server 2012 до 2014 года. На этом этапе тестирование необходимо. К сожалению, тестирование каждой части даже небольшого приложения, вероятно, не будет возможным. В этот момент я бы сделал то, что я бы назвал «рабочим» тестом. Является ли основная система работоспособной. Выполните ваши общие задачи начала до конца. Не проверяйте каждый вариант, только основной путь.

При обновлении SQL Server также требуется некоторое чтение . По сути, вы хотите прочитать Backward Compatibilityзапись для новой версии ( здесь - 2014 ) и убедиться, что у вас ничего нет ни в одном из списков (критические изменения, изменения поведения и т. Д.).

Код приложения

Здесь мы смотрим на новый / изменяющийся код приложения (потому что, конечно, все существующее уже было проверено, верно?). В этом случае все должно быть проверено. У вас должны быть заранее настроены тестовые наборы, которые должны пройти по крайней мере через большинство ваших уязвимых функций. Желательно, чтобы в этот момент у вас был кто-то другой, чтобы сделать аналогичную проверку. Этот код будет на месте, вероятно, довольно долго, и будет использоваться большим количеством людей. Вы хотите убедиться, что это работает и работает хорошо.

Одна из вещей, которая может действительно помочь с этим, состоит в том, чтобы генерировать набор, unit testsкоторый легко повторяется. Стив Джонс рекомендует использовать tSQLt для тестирования вашего кода TSQL (боюсь, только SQL Server). Но, выполнив это, вы можете быстро выполнить фиксированный набор тестов, и это действительно поможет в регрессионном тестировании (тестирование всего, скажем, перед обновлением).

Особенности / Конфигурации

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

Специальные запросы, которые ссылаются / влияют на данные пользователя

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

Например, вам нужно удалять одну или несколько объявлений из таблицы AdList каждый квартал.

DELETE FROM AdList WHERE AdName IN ('January 2015 Ads','February 2015 Ads','March 2015 Ads')

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

Один простой способ проверить DELETE, UPDATEили INSERT, чтобы изменить их к SELECT , и запустить их, а затем подтвердить , что количество и тип строк вы ожидаете возвращаются.

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

Специальные запросы, которые ссылаются на системные данные

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

Резюме

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

Автоматизированное модульное тестирование - ваш друг здесь. С появлением DevOpsи Continuous Integrationвы увидите все больше и больше приложений и методов быстрого и простого тестирования вашего кода. Конечно, для этого требуется хорошая тестовая среда и данные, но это совсем другое обсуждение.

Я знаю, что вы чувствуете, я 3 года работаю с MySQL, и в моем случае я всегда тестирую запросы DML, которые могут изменить или сломать любую информацию в каждой таблице / базе данных / подчиненной репликации.

Это всегда самый безопасный способ проверить свой запрос перед его выполнением.

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

На DELETE, UPDATE, INSERTвы всегда должны пытаться использовать SELECTпервый , если вы не уверены , что информация , которую вы собираетесь изменить. При выборе всегда пытайтесь использовать тот же тип данных для условий, что и тип данных столбца, в некоторых случаях использовать EXPLAINдля оптимизации.