Я переместился вверх по этому последнему абзацу, потому что это похоже на X вашей XY проблемы . Я предлагаю прочитать все остальные параграфы, потому что вы, похоже, неправильно понимаете, что такое модульный тест и для чего он предназначен.
Модульные тесты не тестируют несколько кодовых баз!
Я только что заметил это в комментарии, который вы написали:
Поэтому, если разработчик одного проекта меняет схему базы данных, мы хотим предупредить их, что это изменение схемы должно быть отражено и в другом проекте.
Модульные тесты не должны использоваться в качестве способа синхронизации двух полностью не связанных друг с другом кодовых баз.
Это простое приложение DRY против WET: если эти приложения используют одну и ту же схему базы данных, схема базы данных (и связанные с ней объекты EF) должны находиться в одном источнике, от которого зависят оба приложения.
Не развивайте одну и ту же вещь дважды, потому что вам приходится постоянно синхронизировать одну, когда другая меняется (и это то, с чем вы сейчас работаете).
Например, вы можете разместить проект «общих данных» на сервере Nuget, и оба приложения будут ссылаться на эти собственные пакеты Nuget. При правильном подтверждении, при создании приложения оно будет извлекать последнюю версию проекта «общих данных», таким образом гарантируя, что оба приложения всегда работают с последней версией схемы базы данных.
Второй способ сделать это (если вы не хотите создавать разделяемую зависимость) - это заставить вашу подрывную систему наблюдать определенные файлы (например, папку класса сущностей) и предупреждать вас, если в этих файлах будут внесены какие-либо изменения. Когда вы получите предупреждение, вы узнаете, чтобы проверить, влияет ли это изменение на кодовую базу другого приложения.
И если я вас правильно понимаю, вы действительно просто пытаетесь получить предупреждение, верно?
Есть и другие способы решения этой проблемы, и решение зависит от вашей инфраструктуры и от того, какие технологии использует ваша команда. Но это определенно не должно выполняться вручную при помощи сценариев / фальсификаций сбоев модульного теста.
Не забудьте про "unit" в "unit test"
Я хочу, чтобы некоторые модульные тесты не были выполнены при изменении схемы и сущности базы данных
Юнит-тесты одна вещь (отсюда и "юнит"). Кажется, вы пишете тесты, которые проверяют две вещи: бизнес-логику и базу данных. Это интеграционный тест. Как правило:
- Модульные испытания один компонент.
- Интеграционные тесты проверяют взаимодействие между несколькими компонентами.
Не проверять внешние зависимости
Если бы вы специально написали модульный тест для EF (чего не следует, но об этом позже), вы бы фактически не включили в тест действительную базу данных. В лучшем случае вы бы утверждали SQL, сгенерированный EF, без выполнения этого запроса к базе данных.
Повторяя мою точку зрения, модульные тесты один компонент. Entity Framework и сервер базы данных - это две разные вещи.
При использовании внешних компонентов (таких как сервер базы данных) вы снова погружаетесь в область интеграционных тестов.
Только тестируйте свой собственный код
Как упоминалось ранее, вам не следует тестировать Entity Framework. Модульное тестирование библиотеки в основном выполняет работу разработчика библиотеки. Вы не должны заниматься тем, как работает библиотека. Во всяком случае, вы используете библиотеку именно потому, что вы не хотите знать, как она работает внутри.
Рассмотрим этот тест:
public void TestForAddition()
{
var expectedValue = 2;
var testValue = 1 + 1;
Assert.AreEqual(testValue,expectedValue);
}
Здесь вы тестируете оператор +, предоставляемый платформой C # .Net. Это не является частью вашего кода, и поэтому вам не следует его тестировать. Идея та же, что и в аргументе EF: это не ваш код, и вам не нужно тестировать. Вы должны доверять зависимостям, которые вы используете.
Однако, если вы перегрузили оператор +, вы должны проверить это (потому что это ваш код)
public static Person operator+ (Person a, Person b)
{
return new Person() { Name = a.Name + " " + b.Name };
}
public void TestForPersonAddition()
{
var expectedValue = "Billie Jean";
var billie = new Person() { Name = "Billie" };
var jean = new Person() { Name = "Jean" };
Assert.AreEqual(billie + jean,expectedValue);
}
Что это означает для вашего EF-ориентированного примерачто вы не должны проходить модульное тестирование Entity Framework .У вас должны быть только модульные тесты для вашего кода, а не EF.
Однако вы можете написать интеграционные тесты для этого.И это может достичь того, что вы хотите: вы запускаете интеграционные тесты для существующей базы данных.Если интеграционные тесты пройдут, вы будете знать, что новая кодовая база совместима с существующей базой данных.Если это не так, значит, вы знаете, что возникла проблема, требующая внимания разработчика.
Модульные тесты поведения при тестировании!
Однако я хочу, чтобы некоторые юнит-тестысбой при изменении схемы и объекта базы данных, но модульные тесты не изменились.Это значит, Я хочу, чтобы разработчики исправляли модульные тесты , когда они изменяют схему и сущность базы данных.
Таким образом, вы хотите, чтобы ваши разработчики исправляли модульные тесты, которые никогда не нарушались в первомместо?
Ваше намерение не имеет смысла для меня.Вы изменили некоторый код, и модульные тесты не дают ошибок.Это хорошая вещь.Но вы хотите заставить их потерпеть неудачу, поэтому ваши разработчики будут вынуждены «исправить» модульные тесты (которые не были разбиты в первую очередь).
Еслимодульные тесты пройдены, и все же вы утверждаете, что в поведении приложения что-то не так, тогда ваши модульные тесты не выполняют работу, которую они должны выполнять .
Вы неправильно используете модультесты.Проблема не в том, чтобы понять, как заставить модульные тесты провалиться;проблема заключается в том, что вы ожидаете от результатов модульного теста.
Модульные тесты не должны использоваться для проверки того, изменилась ли внутренняя система. Модульные тесты проверяют, продолжает ли приложение вести себя так же (даже если часть кода изменилась).
Если я переписываю вашу кодовую базу с нуля, а затем запускаю ее (нетронутой)модульные тесты на моей новой кодовой базе, и все модульные тесты проходят, это означает, что мой код ведет себя так же, как ваш , и наши кодовые базы являются функциональными эквивалентами друг другу (по крайней мере, в отношении поведения, которое выve письменные тесты для)