Каким образом методы обновления таблиц базы данных должны подвергаться модульному тестированию?

Question

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

Что я должен тестировать в своих модульных тестах? Должен ли я ...

1. Проверка, что каждый метод завершается без исключения -or-
2. Проверяйте данные в базе данных после каждого теста, чтобы убедиться, что состояние данных соответствует ожидаемому

Моя первоначальная мысль - №2, но меня беспокоит то, что я бы написал кучу каркасного кода , чтобы выполнить мои модульные тесты. Я читал, что вы не должны писать кучу фреймворк-кода для модульного тестирования.

Мысли

РЕДАКТИРОВАТЬ: Под структурой я подразумеваю написание тонны другого кода, который служит библиотекой для кода модульного тестирования ... а не сторонней платформы. *

Answer 1

Я делаю номер 2, т. Е. Проверяю обновление, обновляя запись, а затем считывая ее обратно и проверяя, совпадают ли значения с теми, которые вы ввели. Выполните как обновление, так и чтение в транзакции, а затем откатить его назад, чтобы избежать постоянного воздействия на базу данных. Я не думаю об этом как о тестировании кода Framework, так же как и о тестировании кода ОС или сетевого кода ... Каркас (если вы имеете в виду не относящийся к приложению компонент уровня доступа к базе данных) должен быть протестирован и проверен независимо друг от друга.

Answer 2

Существует третий вариант, который заключается в использовании фиктивного объекта доступа к базе данных, который знает, как реагировать на обновление, как если бы он был подключен к действующей базе данных, но в действительности он не выполняет запрос к базе данных.

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

Answer 3

Они не должны быть проверены на единицу ! Весь смысл этих методов в том, чтобы интегрировать с внешним миром (т.е. базой данных). Поэтому убедитесь, что ваши интеграционные тесты превзошли все, что вы знаете из этих методов, и просто забудьте о модульных тестах.

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

Помните: цель - 100% тест * охват 1012 *, а не 100% модульный тест * охват 1014 *; все ваших тестов: юнит, интеграция, функционал, система, приемка и руководство.

Answer 4

Если вы не пишете в базу данных вручную и используете вместо этого фреймворк (jvm, .net framework, ...), вы можете смело предположить, что фреймворк правильно пишет в базу данных. Что вы должны проверить, так это то, правильно ли вы используете фреймворк.

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

Answer 5

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

Это - это сложный тестовый код базы данных, который выполняет вставки, обновления или удаления (DML), поскольку тест изменяет среду, в которой он выполняется, то есть базу данных. Запуск одной и той же процедуры несколько раз подряд может (и, вероятно, должен) каждый раз приводить к разным результатам. Это очень отличается от модульного тестирования «чистого кода», который вы можете запускать тысячи раз и всегда получать один и тот же результат - т. Е. «Чистый код» равен детерминирован , а код базы данных, выполняющий DML, - нет.

По этой причине вам часто требуется создать «каркас» для поддержки модульных тестов базы данных - то есть сценарии для установки некоторых тестовых данных в нужное состояние и очистки после запуска теста.

Answer 6

Я использую DBUnit , чтобы загрузить базу данных данными, выполнить логику обновления и, наконец, прочитать обновленные данные из базы данных и проверить их. В основном # 2.

Answer 7

Если логика обновления сложна, тогда вы должны сделать # 2.

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