создавать модульные тесты (полу) автоматически?

Question

Существует ли инфраструктура, которая поддерживает генерацию некоторых стандартных модульных тестов из аннотаций? Примером того, что я имею в виду, будет:

@HasPublicDefaultConstructor
public class Foo {

}

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

РЕДАКТИРОВАТЬ: В ответ на ответ С. Лотта, позвольте мне уточнить:

Я пытаюсь проверить, есть ли у класса конструктор по умолчанию. (Конечно, это всего лишь пример.) Я мог бы просто сделать это, написав тест, но я нахожу это довольно утомительным. Поэтому я ищу инструмент, который бы обрабатывал аннотации во время компиляции (через APT) и генерировал для меня тест. Существует ли что-то подобное? Если нет, как вы думаете, это хорошая идея?

Answer 1

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

Answer 2

tl; dr: Вместо этого используйте инструменты проверки кода. Они могут делать то, что вы хотите, не загрязнять ваш код и могут быть легко встроены в процесс автоматической сборки.

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

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

Наиболее критическая точка: Это позволит вам реализовать нужные функции без загрязнения базы кода дополнительными аннотациями. Для меня это главная отправная точка, когда я рассматриваю эту идею: вы создали огромную проблему управления программным обеспечением.

Просто представьте, что ситуация модификации класса с конструктором по умолчанию является неизменной (таким образом, требуется, чтобы объекты были полностью настроены во время построения). Помните ли вы обновить все эти аннотации в этом классе? Вы помните, чтобы изменить связанные аннотации в других классах, которые вызывают методы в этом? И так далее.

Answer 3

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

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

Answer 4

"обработать аннотации ... и сгенерировать для меня тест"

Для ограниченного числа случаев это может быть сделано для работы. В целом, однако, это не может работать.

@StandardTestForClassHierarchy1
@StandardTestForClassHierarchy2
@StandardTestForClassHierarchy3
@StandardTestForSomeOtherFeature4
@AspectFeature5
@AspectFeature6
@HasPublicDefaultConstructor
@AspectX
@AspectY
class SomeClass extends SomeClassHierarchy implements SomeOtherFeature {
}

Я не могу отличить мои аннотации для юнит-тестов от моих реальных аннотаций.

Описывают ли аннотации тестирования поведение моего приложения во время выполнения?

• Если они do описывают поведение во время выполнения, то это настоящие аннотации AOP, а не описания тестов, а реальные аннотации, которые действительно генерируют код во время выполнения. И у аннотации есть свой собственный тест на ложных классах.

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

Answer 5

Примерно так же, как вы описали для тестирования наличия конструктора по умолчанию, я использовал TestUtil для автоматического тестирования геттеров и сеттеров. Вы можете использовать либо файл XML, либо теги JavaDoc для настройки параметров тестирования. К сожалению, в настоящее время нет возможности для аннотаций.

Answer 6

Agitar имеет [коммерческий] продукт , AgitarOne , который генерирует тесты JUnit. Я не уверен, что он в настоящее время поддерживает аннотации, он не сделал в 2005 .

Jtest - это еще один Java-ориентированный генератор модульных тестеров, и Parasoft также предлагает C ++ Test для генерации модульных тестов C ++.

Я никогда не проверял ни одного из них; Я прочитал статью C ++ Test несколько лет назад, но не убедился.

Answer 7

Я думаю, вы вряд ли что-либо себе спасете. Но вы добавите сложность.

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

Foo foo = new Foo();

Answer 8

Вы можете обнаружить это во время компиляции с помощью APT.

http://www.javaspecialists.eu/archive/Issue167.html

Answer 9

Для вашего конкретного примера может быть лучше использовать java APT (обработку аннотаций времени компиляции), чтобы обнаруживать такие проблемы намного раньше, во время компиляции.

Answer 10

EiffelStudio CDD имеет интересный подход. При работе в режиме отладки среда IDE собирает информацию о вызываемых методах и помещает контекст и вызовы в модульные тесты. Сбои обнаруживаются с помощью Проектирования по контракту. Я знаю, что есть некоторые варианты расширений контрактов поверх Java, так что это может быть хорошим способом.