Методы принудительного тестирования Реализация для всех методов, определенных в интерфейсе базы данных

Question

Я разрабатываю решения, способные изменять DataSource от SQL до Oracle и SQLite.

Для этого я использую Unity Framework для реализации Lazy Binding.

Я создал интерфейс и написал в него всю подпись методов базы данных.

Теперь я пишу отдельные классы (проекты) для каждого источника данных и реализуя этот интерфейс.

То, что я хочу сейчас, чтобы создать тестовый проект, который должен гарантировать, что все методы, определенные в интерфейсе, должны быть приняты в проекте испытаний, этот проект Тест имеет отдельную базу данных Test

Есть ли структура/модель доступна автоматически создайте методы тестирования.

Если кто-то предоставляет запись атрибута [TestMethod] по методу (при реализации интерфейса) и меняет тип возврата на Void, я думаю, этого будет достаточно.

На самом деле я хочу реализовать тестовый проект, который должен применяться для создания методов тестирования для всей сигнатуры, определенной в интерфейсе уровня данных базы данных.

Я использую VS 2012 как среду разработки.

Если я не получаю готовые решения, как я могу использовать Reflection Реализовать методы тестирования проекта и изменить свою подпись во время разработки. (Это странное требование?)

Позвольте мне знать, если требуется более подробно.

Предложения приветствуются.

Answer 1

Я не знаю, о какой-либо определенной схеме здесь, но то, что я делаю для этого сценария заключается в следующем:

1. Ссылка проект, где интерфейс для тестового проекта
2. Реализовать интерфейс в CRUDProviderMock .cs или нечто подобное
3. Используйте фиктивный класс для испытаний

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

Проект образец здесь: https://databaselayertesting.codeplex.com/

Пример проекта использует Repository Pattern и NUnit framework для тестирования, где:

1. IRepository является CRUD интерфейс для базы данных
2. EntityOne является выборка объект базы данных
3. EntityOneRepositoryMock - это mock реализация IRepository, которая использует списки

Вы можете использовать базу данных примеров вместо списков для имитации реального поведения базы данных.

Answer 2

Я действительно понимаю, что эта проблема старая, и мое решение не нацелено на VS2012 или ограничения более ранних версий NUnit. Тем не менее, я считаю вашу проблему иначе такой же, как в современной среде. Я также наткнулся на это и нашел подходящее решение, я думаю, мог бы соответствовать другим, или мое будущее себя, отвечая на ваши требования:

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

Есть ли какой-либо каркас/шаблон, который может автоматически заставлять создавать методы тестирования.

При использовании TestCaseSource в сочетании с шаблоном адаптера я был в состоянии обеспечивать, что любое последующее изменение интерфейса сделает программист необходимости обновлять тесты, а также. Красота от рефлексии заключается в том, что это даст вам ранние ошибки времени компиляции и что тестовые ошибки легче отслеживать путем запуска определенных тестов.

Код, приведенный ниже, очень схематичен. Мое собственное использование заключалось в том, чтобы объединить его с макетом определенных данных в testObject и убедиться, что какое-то конкретное исключение всегда было выбрано. Ограничение заключается в том, что настройка testObject является общей и, следовательно, наиболее подходящей для более простых сценариев.

Тестирование Код:

[TestFixture()] 
public class SpecificDatabaseTest : IDatabase 
{ 
    private SpecificDatabase testObject = new SpecificDatabase(); 
    private object TestObject = new object(); 
    private SomeObject TestSomeObject1 = new SomeObject(); 
    private SomeObject TestSomeObject2 = new SomeObject(); 

    public IEnumerable<TestCaseData> SomeMethodData 
    { 
     get 
     { 
      yield return new TestCaseData(TestObject).Returns(TestObject);  
     } 
    } 

    public IEnumerable<TestCaseData> SomeOtherMethodData 
    { 
     get 
     { 
      yield return new TestCaseData(TestSomeObject1, TestSomeObject2).Returns(TestSomeObject2); 
      yield return new TestCaseData(TestSomeObject2, TestSomeObject1).Returns(TestSomeObject1); 
     } 
    } 

    [Test, TestCaseSource(nameof(SomeMethodData))] 
    public object SomeMethod(object data) 
    { 
     return testObject.SomeMethod(data); 
    } 

    [Test, TestCaseSource(nameof(SomeOtherMethodData))] 
    public SomeObject SomeOtherMethod(SomeObject data1, SomeObject data2) 
    { 
     return testObject.SomeOtherMethod(data1, data2); 
    } 
} 

Другой код:

public interface IDatabase 
{ 
    object SomeMethod(object data); 

    SomeObject SomeOtherMethod(SomeObject data1, SomeObject data2); 
} 

public class SpecificDatabase : IDatabase 
{ 
    public object SomeMethod(object data) 
    { 
     return data; 
    } 

    public SomeObject SomeOtherMethod(SomeObject data1, SomeObject data2) 
    { 
     return data2; 
    } 
} 

public class SomeObject { }