Уровень доступа к данным TDD - PullRequest
Новая
       5

Уровень доступа к данным TDD

4 голосов
/ 07 сентября 2011

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

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

Может кто-нибудь пролить свет на это, пожалуйста.

Большое спасибо.

Ответы [ 3 ]

2 голосов
/ 07 сентября 2011

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

1 голос
/ 07 сентября 2011

Если вы используете что-то вроде Hibernate, например, и если у вас есть какая-либо логика в DAO, вы можете смоделировать вызовы, например, Session and Query и unit-тест, не затрагивая базу данных.

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

Вот пример типичного метода Java Spring / Hibernate DAO с некоторой логикой, которую вы, возможно, захотите проверить: 

public List<Entity> searchEntities(final String searchText, final int maxResults) {

   String sql = "select * from entity where field like :text";

   Query query = sessionFactory.getCurrentSession().createSQLQuery(sql);

   if (maxResults != 0) {
      query.setMaxResults(maxResults);
   }

   query.setString("searchText", "%"+searchText+"%");

   return query.list();

}

Используя фальшивый фреймворк, вы могли бы имитировать sessionFactory, сеанс и запрос и создать модульный тест, который ожидает, что query.setMaxResults вызывается только в том случае, если он не равен 0, а этот query.setString с правильным значением строки. Вы также можете утверждать, что все, что возвращается из query.list () - это то, что возвращается методом.

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

0 голосов
/ 07 сентября 2011

Вы можете использовать Dev Magic Fake для подделки DAL, чтобы вы могли работать с TDD, как вам нужно, без написания какого-либо кода для Fake DAL, например

Просто добавьте ссылку на DevMagicFake.dll, и вы сможете кодироватьследующее: 

[HttpPost]
public ActionResult Create(VendorForm vendorForm)
{
    var repoistory = new FakeRepository<VendorForm>();
    repoistory.Save(vendorForm);
    return View("Page", repoistory.GetAll());
}

Это сохранит перманент VendorForm в памяти, и вы сможете извлекать его в любое время. Вы также можете генерировать данные для этого объекта или любого другого объекта в вашей модели, не записывая никакихкод для этой операции, так что теперь вы можете сделать TDD, как вы уже закончили свой DAL для получения дополнительной информации о Dev Magic Fake см. следующую ссылку на CodePlex:

http://devmagicfake.codeplex.com

Спасибо

M.Radwan

...