TDD: методы «только тест»

Question

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

Мы используем методологию BDD / TDD sytle для построения нашего программного обеспечения (довольно большое / сложное приложение). Конечный результат.. поведенческие спецификации (заданный / когда / затем стиль), основанные на бизнес-требованиях, модульных тестах, отражающих их, и коде, который отражает требования тестов.

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

Проблема в том, что в некоторых хранилищах сущностей нет методов удаления, поскольку для них еще не было заявлено никаких бизнес-требований.У многих есть архив / восстановление / резервное копирование и т. Д. (И, возможно, удаление отложено в очереди).

Так что теперь у нас есть тестовый отдел.требование удаления (но противоречащее истории бизнес-пользователей)

Итак ... У меня вопрос ... если бы мне пришлось добавлять методы специально для тестового отдела ... что не лучший способсправиться с этим.Я понимаю, что это обычно считается плохой практикой в ​​"TDD Utopia", но на самом деле, как вы справились с такого рода конфликтами?

Первые мысли, которые у меня были, - это использовать именование ...

void TestOnly_Delete(Guid id){} 

... атрибуты ...

[TestOnly]
void Delete(Guid id){}

... или директивы компилятора ...

#if TESTBUILD
void Delete(Guid id){}
#endif

Таким образом, как минимум, разработчики могут знать, что не вызыватьМетоды TestOnly и, как максимум, методы тестирования не развертываются в производственных сборках.

... или просто читы и добавьте пользовательскую историю для управления этим способом; -)

Любой опыт илиСовет с благодарностью приветствуем?

Заранее спасибо.

Answer 1

Ваше первое беспокойство должно быть: улучшает или ухудшает добавление этой функциональности текущий API? Типичный сценарий в TDD состоит в том, что член класса (изначально) требуется только по причине тестируемости, но он соответствует всем нормальные правила разработки API, поэтому он не причиняет вреда (и часто впоследствии оказывается ценным дополнением и в рабочем коде).

Если это так, то непременно добавьте его , если вы можете сделать это легко .

Иногда, однако, происходит обратное. В этом случае вы должны сопротивляться желанию добавить участника. Однако часто вы можете следовать принципу Open / Closed и открывать свой API, чтобы другие могли добавить желаемую функциональность. Тестируемость - это на самом деле просто еще одно слово для Открытого / Закрытого Принципа .

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

Answer 2

Я обычно получаю проект / библиотеку "только для тестирования", в которой хранятся все классы mock / helper, которые мне нужны для моих тестов.Добавление необходимых классов / методов в эту фиктивную библиотеку - которая не включена в производственный код - кажется естественным соответствием этому требованию.Если у вас еще нет такой библиотеки, и вы не хотите ее создавать, я бы пометил - если возможно - методы внутренние и предоставил их только для среды тестирования.Вы не указываете платформу, но я знаю, что это возможно с C # /. NET, и я часто использую эту возможность, чтобы дать моим тестам доступ к методам, которые в противном случае были бы недоступны за пределами библиотеки.

С другой стороныЯ бы сказал, что тестеры являются такой же частью анализа ваших требований, как и реальные клиенты.Так же, как у нас есть некоторые требования, которые предназначены исключительно для наших потребностей в разработке, у нас также есть некоторые требования к тестированию.Как выяснилось, хитрость заключается в том, чтобы разработать код таким образом, чтобы все потребности заинтересованных сторон были максимально удовлетворены.Когда потребности конфликтуют, мы стараемся найти наилучший возможный компромисс.IMO, позволяющий удалять из библиотек только для тестирования, является разумным компромиссом с потребностью клиента в защите данных (без удаления).

Answer 3

В моем коде я создаю подкласс: например, если у меня есть класс DataLayer, который имеет все открытые методы для доступа к слою данных, то я мог бы создать его подкласс с подклассом Test_DataLayer, который наследует методы из DataLayer и который, кроме того, реализует любые дополнительные методы, которые вам могут понадобиться, например Delete, и чья реализация может обращаться к внутренним или защищенным методам базового класса.

Answer 4

Я никогда не добавлю удаление или другие методы очистки в свой код только для поддержки автоматического тестирования.

Существует множество альтернатив - от интеллектуального управления транзакциями до автоматического восстановления баз данных.

Answer 5

Это интересный вопрос.У меня есть некоторые мысли, но я не уверен, что это ответ на вашу проблему.

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

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