Меня недавно наняли в моей команде, которая занимается написанием приемочных тестов для программного обеспечения 3D-моделирования нашей компании. Для их написания и запуска мы используем собственную инфраструктуру C#, которая по существу сводится к созданию подкласса класса TestBase и переопределению метода Test (), где обычно выполняется вся настройка, тестирование и разборка.
Во время написания моих тестов я заметил, что большая часть моего кода оказывается стандартным кодом, который я часто переписываю. Я был заинтересован в попытке извлечь этот код для повторного использования и сделать мой код СУХИМЫМ, но я изо всех сил пытался найти способ сделать это, не переоценивая мои тесты, когда они должны быть в значительной степени автономными. Я испробовал несколько подходов, но они столкнулись с проблемами:
- Использование наследования: самое наивное решение, сначала оно работает хорошо и позволяет мне писать тесты быстро, но натолкнулся на обычные атрибуты, то есть тестовые классы стали слишком жесткими и неспособными делиться своим кодом между подклассами двоюродного брата, а logi c запутался в дереве наследования. Например, у меня есть абстрактные классы RotateVolumeTest и TranslateVolumeTest, которые оба наследуют от ModifyVolumeTest, но я знаю, что относительно скоро мне захочется повернуть и для перевода тома, поэтому это будет проблемой.
- Использование композиции через интерфейсы: это решает множество проблем с предыдущим подходом, позволяя мне гибко использовать код для моих тестов, но это приводит к большой абстракции и кажущемуся "раздутию классов" '- теперь у меня есть IVolumeModifier, ISetsUp и др. c., которые делают код менее понятным в том, что он фактически делает в тесте.
- Вспомогательные методы в состоянии c служебный класс: это было очень полезно, особенно для использования шаблона Factory для быстрой генерации сложных объектов, которые мне нужны для тестов. Тем не менее, кажется «неприличным», чтобы поместить некоторые методы, которые, я знаю, на самом деле не очень общие, вместо этого они используются для небольшого подмножества тестов, которые должны иметь очень специфический c код.
- Использование инфраструктуры тестирования, такой как xUnit. net или аналогичной, для совместного использования кода с помощью методов [SetUp] и [TearDown] в наборе тестов, как правило, все в одном классе: Я настоятельно предпочел этот подход, так как он предлагает возможность повторного использования, которую я хотел, не отвлекаясь от тестового кода, но моя команда не заинтересована в этом; Я пытался показать потенциальные преимущества принятия подобной инфраструктуры для наших тестов, но, похоже, все согласны с тем, что не стоит усилий по рефакторингу при переписывании существующих классов тестов. Это верное замечание, и я думаю, что вряд ли я смогу убедить их в этом, особенно в качестве относительно нового найма, поэтому, если я не хочу сделать свои тестовые классы сильно отличающимися от остальной части кодовой базы, этот не обсуждается .
- Скопируйте и вставьте код там, где это необходимо: это текущий подход, который мы используем, наряду с # 3 и добавлением методов в TestBase. Я знаю, что мнения расходятся о том, приемлемо ли копирование / вставка кода для тестового кода, если это, конечно, не для производства, но я чувствую, что использование этого подхода значительно усложнит поддержание или изменение моих тестов в долгосрочной перспективе, так как Теперь у меня есть N мест, в которых мне нужно исправить логи c, если обнаруживается ошибка (которой уже достаточно и нужно исправить только в одном).
На данный момент я действительно не Я уверен, что у меня есть другие варианты, кроме как выбрать №5, поскольку это замедляет мою способность быстро и надежно писать тесты, чтобы оставаться в соответствии с текущей базой кода. Любые мысли или отзывы очень ценятся.