Является поблочное тестирование Вашим TDD взятия SQL Слишком далеко?

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

В нескольких случаях я бы предложил протестировать базу данных:

• Таблицы и представления. Проверьте таблицы и представления, которые, как вы ожидаете, существуют. Убедитесь, что эти таблицы и представления содержат ожидаемые столбцы. Вы также можете проверить, что таблицы, представления или столбцы, которые вы пропустили на этом этапе, на самом деле отсутствуют.

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

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

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

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

• Запросы: код приложения связан с запросами SQL. Проверьте их на предмет работоспособности, а также на производительность. Особенно производительность - потому что один и тот же запрос может работать хорошо в один день и стать узким местом на следующий день, так как объем данных изменяется, индексы растут несбалансированными и т. Д.

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

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

Ваш SQL содержит логику. Например, логическое условие проверяет условие WHERE. Можете ли вы придумать, каким образом SQL может быть неправильным? Если да, имеет ли смысл тестировать SQL, чтобы убедиться, что этих ошибок нет?

(Например, какой-нибудь глупый программист, такой как я, мог случайно напечатать «WHILE» вместо «WHERE» в моем комментарии выше ! ... как и я. Но позже я это исправил. Так где же мои тесты переполнения стека?!?; -)

Различают модульные тесты / спецификации и интеграционные тесты / спецификации.

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

Ваши тесты должны быть четко определены между юнит-тестами для тестирования постоянных невежественных модулей POCO / POJO, таких как сущности, услуги и интеграционные тесты. Которые для тестирования, где ваше приложение попадает в металл.

Интеграционные тесты должны проверять постоянство, такое как хранилища и единицы реализации работы для вашего механизма персистентности (RBDMS), Active Directory, Exchange, файловой системы, электронной почты и т. Д.

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

Эта проблема горячо обсуждается. Если вы спросите администратора базы данных, он сочтет лучшим в мире, чтобы все ваши приложения использовали предопределенные хранимые процедуры. Хотя эти дни подходят к концу, с ростом популярности Hibernate и LINQ, вы действительно МОЖЕТЕ использовать базу данных в качестве хранилища информации, и ваш уровень доступа к данным обрабатывает все запросы. Я думаю, что LINQ может сделать все для вас в MS SQL, кроме полнотекстового поиска. Что касается разницы в производительности между SPROC и LINQ, то она незначительна. Мой голос - это не код в базе данных, а весь код на уровне доступа к данным, и я тестирую его.

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

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

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

I don't do TDD directly on my database, but there are plenty of opportunities where it is valid to put "logic" into the database. Constraints, default values (yeah, I know it's a constraint, too), triggers, etc. Often these are the best way to implement some business logic AND ensure database consistency. Most of the time I'm able to convince myself of the correctness with some manual testing and leave it at that, but I could see where someone might want to do TDD with this.

EDIT:

For example, I will use a default value on insert and a trigger on update to set the "last updated time" fields on insert/update. In LINQ I'll set the column up as an autogenerated value and make it read-only. This is simpler, to me, than adding a PropertyChanged event handler to make sure that whenever a field on the entity is changed, the last updated time is changed as well. Do I test it? Sure, but manually and after the fact even though I strongly prefer TDD for most things.

Я не знаю, почему, когда мы попадаем на слой db, вся хорошая практика должна уходить в окно. Если в этом слое есть логика, это вдвойне важно. Существует отличный инструмент, построенный поверх Fitnesse , называемый dbfit , который, кажется, снимает с себя все трудности при модульном тестировании dblayer. Если вы заинтересованы, вы должны взглянуть.

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

Здесь мы используем NHibernate Критерии API для запроса базы данных. Тем не менее, мы поставили простые модульные тесты для защиты уровня доступа к данным. Подумайте об этом:

public IList<Book> GetBorrowedBooks(User user);

Во-первых, это может выглядеть глупо. Но для такой простой ситуации мы имеем дело как минимум с 3 модельными объектами: Book, User, Borrow и, возможно, Return. Любая попытка изменить любой из 3 (или более) классов может нарушить код.

Какова стоимость? Думаю, написание тестов в этом примере займет не более 20 минут. С помощью Category в NUnit модульные тесты доступа к данным могут быть настроены для запуска ночью, в то время как другие тесты запускаются при каждой фиксации. Медленные юнит-тесты доступа к данным не наносят вреда и спасают жизнь.

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