Стоит ли тестировать методы бизнес-логики, состоящие в основном из запроса?

Question

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

Что такое лучшая практика здесь? Что вы на самом деле делаете - в отличие от того, что вы хотели бы сказать, что в идеале вы бы сделали?

Answer 1

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

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

В любой ситуации я бы по-прежнему проводил модульное тестирование метода. Есть несколько причин:

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

2. Если вообще существует какая-либо логика (например, определение, какие записи соответствуют бизнес-критериям), вам все равно придется проверить эту логику.

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

Answer 2

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