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

_>Я не подменяю понятия. Если гнаться только за покрытие кода тестами, то понятно, почему юнит-тесты ничего не проверяют. UT должно быть легко выкинуть, переписать, написать с нуля и запустить. Покрытие — это очень косвенный показатель. Юнит тесты необходимо проверять так же, как и остальной код, чтобы не было написания тестов ради самих тестов. По сути, это спасательные якоря скалолаза (самого разработчика), если образно. Их может быть не много, но там где надо.
Тогда возникает резонный вопрос — стоят ли юнит-тесты затрачиваемых на них усилий?
И следом второй вопрос — надо ла обязательно обвешивать программу абстракциями для UT, если затраты на UT превышают пользу?

G>>Ты предлагаешь покрыть GetXsByXXX интеграционным тестом, что не имеет смысла, там примитивный запрос. Покрыть SaveChanges интеграционным тестом, что тоже не имеет смылса и написать юнит-тест для F, что не дает фактически проверки.

_>Тут чтобы правильно ответить надо еще вопросов позадовать. Если интересно, то расскажите, в чем главная цель этого метода F (от этого зависит как он должен быть написан и какие тесты для него писать)? А так же интересно, ваш реп должен хранить состояние и беферизировать данные, или просто явлется прослойкой между ORM (EF, например) и BO?
Очень интересный вопрос, учитывая, что разговор начался с того, что репозиторий создается для изоляции программы от "деталей" работы с хранилищем. А тут получается что эти "детали" выходят на первое место.
Пусть является прослойкой к EF.

_>Для проверки чего? Хранимки, динамического стейтмента, условий проверки? Описание не достаточно, чтобы нормально ответить вопрос.
Для проверки метода.
Псевдокод такой:

bool F(Event evt)
{
    string query = buildQuery(evt);
    ResultSet rs = db.query(query);
    if(rs.Count>0) 
    {
        return false; 
    } 
    else 
    {
        db.addEvent(evt);
        return true;
    }
}

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

Зеленый UT должен показывать что код отработает корректно в продакшене, если база будет доступна.

G>>Я этой задачей троллю апологетов юнит-тестов.
_>Можем попробовать по разбираться. Кому-то точно в + итоги будут. Если без попыток убедить и навязать свое мнение