Модульное тестирование запроса на выборку

Question

Я возвращаю набор строк, каждая из которых представляет настольный компьютер.

Я нахожусь в тупике при поиске способа юнит-тестирования этого. На самом деле нет никаких крайних случаев или критериев, которые я могу придумать для тестирования. Это не то же самое, что цены на акции, где я мог бы проверить, что я получаю данные, которым действительно 5 месяцев. Это не то же самое, что хранить личные данные, где вы можете проверить, что всегда работает определенная длина, или специальные символы и т. Д. Или валюта и разные валюты (£, $ и т. Д.) В виде строк.

Как бы я протестировал этот набор результатов?

Кроме того, при тестировании returnset-запроса возникает несколько проблем:

1) Тестирование того же количества строк, что и при выполнении запроса на сервере, является хрупким, поскольку кто-то может изменить данные таблицы. Это когда у вас есть тестовый сервер, который никто не меняет, если они не загружают сценарии изменений?

2) Тестируете ли вы, что объект набора данных не равен нулю? Поэтому, если он создан как ноль, но не после выполнения запроса, он содержит значение (это не доказывает, что данные верны, только то, что данные были получены).

Спасибо

Answer 1

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

Answer 2

1 -

a) Никогда не проводите тестирование на рабочем сервере, по любой причине.

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

Что касается тестовых случаев, начните с базового теста функциональности - вставьте «нормальную» строку и убедитесь, что вы ее вернули.Вы по достоинству оцените этот тест, если позже будете проводить рефакторинг.Убедитесь, что программа правильно реагирует на пустые или пустые столбцы.Поместите максимальные и минимальные значения во все поля БД и убедитесь, что поля объектов, в которых вы их храните, могут соответствовать этому разрешению.Проверьте дубликаты записей в БД или пропущенные записи.Если у вас есть производственные данные, возьмите их снимок, чтобы поместить в тестовую базу данных, и убедитесь, что они загружаются правильно.Есть ли значение, которое хронически вызывает трудности в других частях программы?Проверьте это и здесь.И как только вы выпустите код, добавьте в список тестов любые значения, которые вы обнаружите в производственной среде, которые нарушают работу системы (регрессионное тестирование).