Testing сохранение слоя в приложении/TDD DDD

Question

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

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); 
} 

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

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

Есть ли какие-либо инструменты для автоматического создания таких тестов в .NET? Или это «плохо»?

Answer 1

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

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

Answer 2

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

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

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

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