Вопросы о TDD - PullRequest
Новая
       36

Вопросы о TDD

2 голосов
/ 08 октября 2011

Среда

В моем решении у меня есть три проекта:

  1. Web (Asp.net MVC4)
  2. Модель (библиотека классов)
  3. Тест (Тестовый проект)

В Модельный проект имеет:

Couple = Класс

IRepository =Репозиторий на основе интерфейса

ICoupleRepository = Пара репозитория интерфейса

Implementation Репозиторий = Пара Пара репозитория

В Тестовый проект имеет:

Fake / CoupleRepository = Поддельная реализация пары Repository (внутри папки Fake).CoupleTest pair class = Test

Behavior

При добавлении пары под необходимо изменить некоторые свойства, а также добавить объект пары и добавить другие объекты в базу данных.

Я поместил эту логику в CoupleRepository (не фальшивый) репозиторий в методе Add, я установил эти свойства, добавил пару объектов и два других объекта. 

public class CoupleRepository : ICoupleRepository
{
    public void Add(Couple couple)
    {
        couple.Bride.Gender = Gender.Female;
        couple.Groom.Gender = Gender.Male;
        db.Couples.Add(couple);

        db.Users.Add(new User{ CoupleID = couple.Bride.ID });
        db.Users.Add(new User{ CoupleID = couple.Groom.ID });
        db.SaveChanges();

    }
}

Вопрос

В моем тестовом классе, CoupleTest, нужно также проверить добавление этих пользователей и модификацию свойств.

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

Что за подсказку вы мне дадите ?

Откуда Насмешки и заглушки входят во все это?1059 * Где могла бы эта логика спасти пару?

Мне нужно тестировать репозитории?Возможно, идеальным было бы проверить контроллеры?

Многие вопросы, я знаю =)

Я новичок в TDD и не знаю, если ядвижется в правильном направлении.

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

1 Ответ

0 голосов
/ 04 ноября 2011

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

Как правило, ваша сущность должна быть полностью построена до сохранения. Репозиторий должен только сохранять его (возможно, вызывая метод Validate, если вам это нужно).

Этот код: 

couple.Bride.Gender = Gender.Female;
couple.Groom.Gender = Gender.Male;

следует переместить в бизнес-логику Pair (например, конструктор).

С более глобальной точки зрения, с помощью TDD вы делаете вокруг функциональность, которую хотите протестировать. При вашем текущем подходе вы, вероятно, получите что-то вроде IView -> Couple class -> IRepository цепочки Это означает, что путем проверки этих интерфейсов вы намереваетесь протестировать класс Pair (или бизнес-логику в целом).

Чтобы протестировать хранилище, вам нужна структура, подобная последовательности Couple class -> CoupleRepository -> IDatabaseDriver. Путем насмешки IDatabaseDriver вы сможете проверить SqlCommands или Queries, сгенерированные реальной реализацией CoupleRepository.

В этом случае вы напишете такие тесты (очень упрощенный пример): 

var driver = new  MockDatabaseDriver();
var repo = CoupleRepository(MockDatabaseDriver);
repo.Add(new Couple());
Assert.AreEquals("Insert into COUPLES values ('bride', groom')", driver.SqlQueryText);

Здесь MockDatabaseDriver не выполняет запросы, просто указывает действия, выполняемые хранилищем.

...