Здравствуйте, another_coder, Вы писали:

_>1) необходимо иметь возможность мокать:
_>db.query(query)
_>db.addEvent(evt)
_>Не знаю что из себя представляет db. Это интерфейс? Как создается/инжектится?
Неважно, говорю же мокать можно все.



_>2) buildQuery(evt) необходимо передать другой сущности, которая занимается его построением. Тогда:
_>- можно будет отдельно протестировать
_>- как следствие, можно будет замокать в тестах
_>Например, вынесем в другой class QueryBuilder : IQueryBuilder {}
Зачем? Это чистая функция, её протестировать можно и так. Но тест этот ничего не дает без отправки запроса в базу.


_>3) В этом случае на метод F можно написать такие юнит тесты (проверяем ветви алгоритма):
_>- должен возвращать false, если rs.Count>0
_>- должен возвращать true, если rs.Count<=0
_>- должен вызвать addEvent с переданным evt, если rs.Count<=0
Тестировать if — это сильно.

_>4) Отдельно можно протестировать генерацию запросов в методе buildQuery класса QueryBuilder. Не знаю деталей, но девелопер же написал алгоритм генерации, значит может, подавая на вход разные evt, проверить построение соответствующих для них строк. Получится несколько юнит тестов.
Само по себе это тестирование ничего не дает. Запросто может просто название поля поменяться.

_>5) Я полагаю, что в db.query только сам механизм вызова БД. Поэтому, в интеграционном тесте проверяем, что переданный запрос в db.query вернул то, что требовалось запросом. Этот тест покажет, что этот метод получает данные из базы и адекватно выполняет запросы, что и требуется.
db — внешний код его тестировать не надо.

_>В итоге получилось UT 3+ и IT 1 = 4 или более тестов.
Из которых один не нужен, один тестирует очевидные вещи, остальные не дают гарантий.