Как лучше всего создать тестовую БД при выполнении TDD?

Ответ 1

Предполагая, что вы используете шаблон хранилища из Rob Conery MVC Store Front:

http://blog.wekeroad.com/mvc-storefront/mvc-storefront-part-1/

Я последовал за учебником Роба Конери, но столкнулся с тем же, что и вы. Лучше всего переместить созданные вами Mock Repositories в отдельный проект под названием Mocks, после чего вы сможете легко их заменять реальными, когда вы создаете экземпляр своего сервиса. Если вы чувствуете себя авантюристом, вы можете создать factory, который берет значение из файла конфигурации, чтобы создать экземпляр какого-либо макета или реального репозитория,

например.

public static ICatalogRepository GetCatalogRepository(bool useMock)
{
     if(useMock)
          return new FakeCatalogRepository();
     else
          return new SqlCatalogRepository();
}

или использовать инфраструктуру инъекции зависимостей:)

container.Resolve<ICatalogRepository>();

Удачи!

EDIT:. В ответ на ваши комментарии звучит так, будто вы хотите использовать список и LINQ для эмуляции операций db, например. GetProducts, StoreProduct. Я сделал это раньше. Вот пример:

public class Product
{
     public int Identity { get; set; }
     public string Name { get; set; }
     public string Description { get; set; }
     //etc
}

public class FakeCatalogRepository()
{
     private List<Product> _fakes;

     public FakeCatalogCatalogRepository()
     {
          _fakes = new List<Product>();

          //Set up some initial fake data
          for(int i=0; i < 5; i++)
          {
              Product p = new Product
              {
                 Identity = i,
                 Name = "product"+i,
                 Description = "description of product"+i
              };

              _fakes.Add(p);
          }
     }

     public void StoreProduct(Product p)
     {
         //Emulate insert/update functionality

         _fakes.Add(p);
     }

     public Product GetProductByIdentity(int id)
     {
          //emulate "SELECT * FROM products WHERE id = 1234
          var aProduct = (from p in _fakes.AsQueryable()
                         where p.Identity = id
                         select p).SingleOrDefault();

          return aProduct;
     }
}

Означает ли это немного больше смысла?

Ответ 2

Скучно или нет, я думаю, ты на правильном пути. Я предполагаю, что вы создаете fakeRepository, который представляет собой конкретную реализацию вашего IRepository, который, в свою очередь, вводится в ваш уровень обслуживания. Это приятно, потому что в какой-то момент в будущем, когда вы будете довольны формой ваших сущностей и поведением ваших сервисов, контроллеров и представлений, вы можете затем протестировать ваш реальный репозиторий, который будет использовать базу данных для сохранения этих объектов, Конечно, характер этих тестов будет интеграционными тестами, но так же важно, если не более того.

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

Например, у меня есть следующий метод, который вызывается моей SetUpFixture для генерации моей схемы db:

public class SchemaBuilder
{
   public static void ExportSchema()
    {
        Configuration configuration = new Configuration();
        configuration.Configure();
        new SchemaExport(configuration).Create(true, true);
    }
}

и мой SetUpFixture выглядит следующим образом:

[SetUpFixture]
public class SetUpFixture
{
    [SetUp]
    public void SetUp()
    {
        SchemaBuilder.ExportSchema();
        DataLoader.LoadData();
    }
}

где DataLoader отвечает за создание всех моих исходных данных и тестовых данных с использованием реального средства управления.

Это, вероятно, не отвечает на ваши вопросы, но я надеюсь, что это поможет вам успокоить вас в вашем подходе.

Грег

Ответ 3

Я пошел по пути создания таблиц и данных во время метода установки в классе unit test, запуская тесты, а затем выполнял очистку во время разрыва. Да, этот метод работает, но если вы действительно используете свои модульные тесты для целей отладки, вы всегда будете запускать настройку, отлаживать что-то, а затем останавливаться посередине, не делая разрыва. Он очень хрупкий, и вы, вероятно, окажетесь (в конечном счете) с плохими данными в тестовой базе данных и/или непригодными модульными тестами. Я лично считаю, что лучше всего издеваться над слоем базы данных, используя насмешливую структуру. Я понимаю, что иногда лучше всего делать логику в базе данных. Для этих случаев вы можете использовать инструмент, например DBFit для записи тестов для вашего уровня базы данных.

Ответ 4

Хотя я не использую Asp.Net или MVC-структуру, у меня есть необходимость тестировать службы без попадания в базу данных. Ваш вопрос вызвал составление короткого (хорошо, может быть, не столь короткого) резюме того, как я это делаю. Не утверждая, что это лучшее или что-то еще, но оно работает для нас. Мы получаем доступ к данным через репозиторий, и при необходимости мы подключаем репозиторий в памяти, как описано в сообщении.

http://blogs.microsoft.co.il/blogs/kim/archive/2008/11/14/testable-data-access-with-the-repository-pattern.aspx

Ответ 5

Я использую полную базу данных памяти с SQLite и ActiveRecord. В основном мы удаляем и воссоздаваем базу данных до того, как запускается каждый тест интеграции, чтобы данные всегда находились в известном состоянии. Содержимое базы данных вставляется через код. Итак, пример будет таким:

ActiveRecord.Initalize(lots of parameters)
ActiveRecord.DropSchema();
ActiveRecord.CreateSchema();

а затем мы просто добавим много клиентов или что-то еще, стиль DDD:

customerRepository.Save(customer);

Другим способом решения этой проблемы может быть использование NDbUnit для поддержания состояния базы данных.

Ответ 6

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

Во-первых, используйте RavenDb (Embedded). Он является частью базы данных документов RavenDb. Его полностью в базе данных памяти и отлично работает с модульными тестами:) Я сделал это с MSTest, NUnit и xUnit.

Во-вторых, вы можете использовать NHibernate с SqlLite, если вы не хотите использовать RavenDb. У Айенде есть сообщение об использовании этого.