2015-05-22 3 views
0

Я работаю с TDD, и все идет хорошо. Когда я доберусь до своего реального репозитория, хотя я не знаю, как это проверить.Единичное тестирование репозитория платформы Entity Framework

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

public class UserDb : IUserDb 
{ 
    public void Add(User user) 
    { 
     using (var context = new EfContext()) 
     { 
      context.Users.Add(user); 

      context.SaveChanges(); 
     } 
    } 
} 

Ссылка, представленная forsvarir, является тем, что я хочу поставить в качестве ответа. Как я могу это сделать?

http://romiller.com/2012/02/14/testing-with-a-fake-dbcontext/

+0

Привет Дэйв, мне интересно, если это необходимо, чтобы получить этот код тестируемых ... Вы бы скорее протестировать функции EntityFramework, чем бизнес-логика ... – sebastian87

+0

@ sebastian87 Я думаю, что вы имели в виду наоборот. Вы скорее испытаете свою бизнес-логику, чем функции EF. – sed

+0

Меня нет английский, меня называют картофель. Но ты прав, так я и имел в виду. – sebastian87

ответ

1

Что вы надеетесь достичь путем тестирования инструмента 3-й партии? Вы можете высмеять контекст var fakeContext = A.Fake<IDbContext>();, а затем утверждать, что была сделана попытка записать в базу данных. A.CallTo(() => fakeContext.SaveChanges()).MustHaveHappened();

В приведенном выше примере используется библиотека FakeItEasy.

+0

Я не хочу тестировать сторонний инструмент - просто мой метод Add. То, что вы предлагаете, звучит по правильной линии. Тем не менее, я использую RhinoMocks. IDbContext не существует, поэтому я не уверен, как создать такой интерфейс для контекста Entity Framework. –

+0

В общем случае нет необходимости «проверять сторонний инструмент», но я обнаружил, что EF часто срабатывает неожиданно или просто приводит к сбоям во время выполнения (например, запрос LINQ, который нельзя перевести на SQL). Назовите меня параноидальным или даже недостаточно опытным с EF-, но когда я TDD'ing код доступа к данным, мне нравится знать, будет ли этот код фактически работать с реальной базой данных SQL. – prgmtc

+0

@prgmtc Я абсолютно согласен с вами в отношении паранойи. Я склонен писать ряд интеграционных тестов против EF. Придя в EF из nHibernate, я стараюсь поместить все свои EF-бит в транзакции, и я просто не нашел эффективного способа их издеваться. Тем не менее, мой первый проход тестов - это всегда развязанные модульные тесты, поэтому я могу быть уверен, что логика вытеснена из доступа к данным на бизнес-уровне (я, по крайней мере, так себя вел). – THBBFT

1

Обычный ответ на эти виды вопросов:

  • Изолировать трудно проверить зависимости (контекст EF)
  • Обеспечить поддельную реализацию в ваших тестах, чтобы проверить правильное поведение тестируемой

Это все имеет смысл, когда у вас есть интересная логика для тестирования в тестируемой системе. Для вашего конкретного случая репозиторий выглядит как очень тонкая абстракция между вашим чистым доменом и логикой, поддерживающей EF. Хорошо, держи их так. Это также означает, что это не очень много работает. Я предлагаю вам не докучать отдельные тестовые тесты (обертка EF DbContext кажется дополнительной работой, которая может не потянуть ее вес).

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

Смежные вопросы