Это плохая практика для модульного тестирования, что класс использует определенный класс проверки для проверки сущности? - PullRequest
Новая
       7

Это плохая практика для модульного тестирования, что класс использует определенный класс проверки для проверки сущности?

3 голосов
/ 22 марта 2011

Я выполняю все свои действия через классы, которые я называю «командами». Чтобы проиллюстрировать это, чтобы создать нового пользователя, я бы назвал следующий код 

new CreateUserCommand(unitOfWork).SetName("Username").SetPassword("Blah").Execute();

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

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

public class NewUserValidation : ValidationFor<User>
{
   public NewUserValidation() 
   {
     // Validation Rules here
   }
}

Одним из преимуществ создания проверки в своем собственном классе является то, что я могу использовать одни и те же правила проверки для нескольких команд (например, при редактировании и создании компаний могут использоваться одни и те же правила проверки).

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

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

Единственный другой вариант, который я вижу, - это открыть открытое свойство в команде, содержащей класс валидации, и тогда я бы проверил юнит-тест, чтобы класс валидации команды был ожидаемым классом валидации. Однако проблема этого метода заключается в том, что мне нужно разработать какой-то способ проверить, что мой метод Execute() действительно выполняет класс проверки (в противном случае невозможно узнать, не выполняется ли проверка).

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

Редактировать : Чтобы ответить на оба ответа ниже, проверка будет использоваться внутри метода Execute() с помощью вызова validator.Validate(entity) в реализации Execute().

Хотя я не хочу нарушать DRY, я не вижу простого способа проверить, что Execute() 1) использует правильный класс проверки по умолчанию и 2) На самом деле вызывает метод .validate(entity) класса проверки ,

Я могу решить # 1, создав экземпляр класса валидации в конструкторе, и выставить его через открытое свойство класса команд, но я не уверен, как правильно выполнить модульное тестирование для 2-й проблемы, не повторяя отдельные юнит-тесты валидации .

Ответы [ 3 ]

2 голосов
/ 22 марта 2011

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

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

РЕДАКТИРОВАТЬ: Из вашегоВ последнее время это выглядит как идеальный кандидат для использования фиктивных объектов.

Чтобы проверить метод Execute, вы можете смоделировать свои валидаторы и убедиться, что их методы validate вызваны.Чтобы проверить конструкцию команды, вы можете смоделировать свой объект команды и убедиться, что ему переданы соответствующие валидаторы.

Возможно, вы захотите проверить этот вопрос (stackoverflow.com).Возможно, вам придется помассировать свой дизайн, чтобы вы могли использовать макет фреймворка.

РЕДАКТИРОВАТЬ: Также взгляните на этот вопрос (stackoverflow.com).Кажется, для удовлетворения ваших требований.Инструмент Microsoft Родинки (microsoft.com) выглядит очень интересно.

1 голос
/ 22 марта 2011

Вы почти никогда не хотите нарушать DRY, поэтому я думаю, что повторять юнит-тесты для каждого класса ссылок абсолютно неправильно.Я не совсем понимаю вашу озабоченность по поводу проверки того, что метод Execute выполняет класс проверки.Разве это не должно быть модульным тестом метода Execute?И после того, как вы проверили это, зачем вам нужно тестировать его специально для каждого типа класса валидации?

Наконец, я не уверен, почему вам нужно "проверить, что класс валидации команды является ожидаемой валидациейучебный класс."Звучит так, как будто вы тестируете фабрику вместо фактического класса Command.

Я бы тестировал только те вещи, за которые непосредственно отвечает класс Command.Если класс Command создает свои собственные классы валидации, на которые он ссылается, то, я полагаю, вы можете выполнить это модульное тестирование.Но на основании предоставленной вами информации это звучит неправильно.

0 голосов
/ 22 марта 2011

Если бы я был вами, я бы создал только один validationFalingTest , где вы выполняете одну команду с недопустимыми данными.

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

...