Был удивлён, что при всём обилии возможностей Scala и нарицательном названии "better Java", всё ещё встречаются случаи, когда в полноценный Scala проект приходится-таки вносить HorribleClass.java
. Один из таких случаев - написание runtime-аннотаций.
Scala поддерживает аннотации с помощью абстрактного класса Annotation
. Используется этот механизм не очень часто, но встретить можно - например, как инструмент для (де)сериализации JSON. До времени исполнения такие аннотации не доживают и стираются компилятором.
Зачем вообще может понадобиться доступ к аннотациям во время работы программы? К примеру, в тестах: допустим, вы используете модную библиотеку, основанную на JUnit
. При этом вы хотите пометить определённые тестовые пакеты (которые представляются в виде классов) как интеграционные, чтобы запускать их отдельно от юнит-тестов. Для этого необходимо использовать аннотации, которые JUnit
проанализирует уже после запуска тестов.
Поскольку аннотации Scala после запуска видны не будут, необходимо создавать Java-аналог. Выглядеть он будет примерно так:
@org.scalatest.TagAnnotationСамое печальное, что это сделано намеренно - в документации отдельно описывается разметка тестовых пакетов Java-аннотациями. Разметку же отдельных тестов можно делать средствами Scala, но при большом их количестве это становится крайне утомительно.
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD, ElementType.TYPE})
public @interface IntegrationTest {}
В противовес этому досадному недоразумению в библиотеке
specs2
в этом плане всё гораздо более положительно - можно задавать произвольную иерархию тестов, которая к тому же не обязательно должна быть древовидной. Тем не менее (возможно по причинам исторического характера) используется эта библиотека в 7 раз реже (согласно mvnrepository.com).
>>Click here to continue<<
