Тестирование персистентного уровня в приложении DDD / TDD - PullRequest
Новая
       13

Тестирование персистентного уровня в приложении DDD / TDD

2 голосов
/ 01 апреля 2009

Если у меня есть следующий объект домена: 

public class Customer
{
    public virtual Guid Id { get; set; }
    public virtual string Name { get; set; }
    public virtual ISet<Order> Orders { get; set; }

    public Customer()
    {
        Orders = new HashedSet<Order>();
    }

    public virtual void AddOrder(Order order)
    {
        order.Customer = this;
        Orders.Add(order);
    }
}

со следующим отображением NHibernate: 

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" namespace="Examples" assembly="Examples">
  <class name="Customer">
      <id name="Id">
        <generator class="guid.comb" />
      </id>
      <property name="Name" length="50"/>
      <set name="Orders" table="CustomerOrder" cascade="all-delete-orphan" lazy="true">
        <key column="CustomerId"/>
        <many-to-many class="Order" column="OrderId"/>
      </set>
  </class>
</hibernate-mapping>

Есть ли какое-либо значение в этом тесте? 

[Test]
public Save_NameWritten_SameNameIsReadback()
{
    var expected = new Customer { Name = "Fred Quimby" };
    _repo.Save(c);
    var actual = _repo.Find(expected.Id);
    Assert.AreEqual(expected.Name, actual.Name);
}

Люди обычно проверяют свой уровень устойчивости таким образом? Убедиться, что каждое поле сохраняется индивидуально? Я, честно говоря, не уверен, что лучше всего делать что-то подобное. Я вижу тестирование чего-то с длинными строками и отношениями родитель / потомок - но как насчет целых чисел и дат? Это перебор?

Я просто говорю о слое постоянства, а не о бизнес-логике на уровне домена. Для этого я бы посмеялся над хранилищем, тогда как здесь я проверяю, что хранилище действительно сохранило то, что я сказал сохранить. Что если кто-то забудет отобразить поле или у него есть фиктивная длина строки в отображении?

Существуют ли какие-либо инструменты для автоматической генерации таких тестов в .NET? Или это "плохо"?

Ответы [ 2 ]

3 голосов
/ 01 апреля 2009

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

лучшее для этого было бы использовать в базе данных памяти и что-то вроде PersistenceSpecification (здесь сообщение об этом) из беглого NHibernate, который может вставлять и выбирать данные для вас в разных сеансах. *

0 голосов
/ 09 апреля 2009

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

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

Как мало вещей, которые вы можете проверить, используя эти тесты проводной базы данных:

  • Длина границ для строк
  • Ленивая загрузка. Вы можете использовать отдельные сеансы, чтобы убедиться, что вы получаете исключение отложенной загрузки для подключенного объекта, который вы не хотите загружать с нетерпением, и наоборот. Это важно для более сложных иерархий доменов, когда кто-то непреднамеренно добавляет навигационный путь по графу объектов, что приводит к загрузке всей базы данных.
  • Внешние ключи и уникальные ограничения.
  • Эффективность поисковых вызовов в хранилище с большими наборами данных.
...