Здравствуйте, Nikita Lyapin, Вы писали:
NL>Странный вопрос. Даже очень. Тестировать я хочу бизнес-правила. Например, что при задании определенных пермишенов мне только заданные items отоброжаются.
Ничего странного. Вопрос "а что именно тестируется" очень важен. К примеру, я не думаю, что вы в вашем коде проверяете, что компилятор, стандартная библиотека, и процессор корректно выполняют, скажем, умножение.
Если мы говорим о юнит-тестах, то они тестируют именно конкретный юнит.
Когда вы тестируете SQL, вряд ли вы тестируете, что в результат join ... on ... попадают только те строчки, которые попадают под предикат. Эту работу уже выполнила команда QA-инженеров соответствующей СУБД.

Так и тут — у вас есть некоторые обязанности кода, их вы и проверяете.

NL>И да, Linq2Db мне тестировать ну совсем не хочется. И как это реализовать в вашем примере без теста Linq2Db? С статическими то переменными в коде... выкрутиться можно. Но будет такое себе зрелище. Просто интересно как вы это решаете.

Очевидным способом — проверяем, что при передаче обычного пользователя возвращается результат Join, а при передаче суперпользователя — тот же экземпляр IQueryable.
Можно проверить текст результирующего SQL, но это контрпродуктивно в случае поддержки разных SQL-диалектов.

Интеграционные тесты, как и везде, будут относительно медленными, и ничем не будут отличаться от интеграционных тестов любого Enterprise-приложения.