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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

это могло бы быть тем, что Вы ищете: http://developer.spikesource.com/wiki/index.php/Projects:testgen4j. другие, возможно, полезные ссылки в: http://www.opensourcetesting.org/unit_java.php. вот текущая статья: http://www.alexquinn.org/papers/Generating%20Java%20unit%20tests%20with%20AI%20planning%20 (2007) .pdf

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

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

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

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

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

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

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

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

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

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

Foo foo = new Foo();