TG Telegram Group & Channel
Scala bin | United States America (US)
Create: Update:

Был удивлён, что при всём обилии возможностей Scala и нарицательном названии "better Java", всё ещё встречаются случаи, когда в полноценный Scala проект приходится-таки вносить HorribleClass.java. Один из таких случаев - написание runtime-аннотаций.

Scala поддерживает аннотации с помощью абстрактного класса Annotation. Используется этот механизм не очень часто, но встретить можно - например, как инструмент для (де)сериализации JSON. До времени исполнения такие аннотации не доживают и стираются компилятором.

Зачем вообще может понадобиться доступ к аннотациям во время работы программы? К примеру, в тестах: допустим, вы используете модную библиотеку, основанную на JUnit. При этом вы хотите пометить определённые тестовые пакеты (которые представляются в виде классов) как интеграционные, чтобы запускать их отдельно от юнит-тестов. Для этого необходимо использовать аннотации, которые JUnit проанализирует уже после запуска тестов.

Поскольку аннотации Scala после запуска видны не будут, необходимо создавать Java-аналог. Выглядеть он будет примерно так:

@org.scalatest.TagAnnotation
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD, ElementType.TYPE})
public @interface IntegrationTest {}

Самое печальное, что это сделано намеренно - в документации отдельно описывается разметка тестовых пакетов Java-аннотациями. Разметку же отдельных тестов можно делать средствами Scala, но при большом их количестве это становится крайне утомительно.

В противовес этому досадному недоразумению в библиотеке specs2 в этом плане всё гораздо более положительно - можно задавать произвольную иерархию тестов, которая к тому же не обязательно должна быть древовидной. Тем не менее (возможно по причинам исторического характера) используется эта библиотека в 7 раз реже (согласно mvnrepository.com).

Был удивлён, что при всём обилии возможностей Scala и нарицательном названии "better Java", всё ещё встречаются случаи, когда в полноценный Scala проект приходится-таки вносить HorribleClass.java. Один из таких случаев - написание runtime-аннотаций.

Scala поддерживает аннотации с помощью абстрактного класса Annotation. Используется этот механизм не очень часто, но встретить можно - например, как инструмент для (де)сериализации JSON. До времени исполнения такие аннотации не доживают и стираются компилятором.

Зачем вообще может понадобиться доступ к аннотациям во время работы программы? К примеру, в тестах: допустим, вы используете модную библиотеку, основанную на JUnit. При этом вы хотите пометить определённые тестовые пакеты (которые представляются в виде классов) как интеграционные, чтобы запускать их отдельно от юнит-тестов. Для этого необходимо использовать аннотации, которые JUnit проанализирует уже после запуска тестов.

Поскольку аннотации Scala после запуска видны не будут, необходимо создавать Java-аналог. Выглядеть он будет примерно так:

@org.scalatest.TagAnnotation
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD, ElementType.TYPE})
public @interface IntegrationTest {}

Самое печальное, что это сделано намеренно - в документации отдельно описывается разметка тестовых пакетов Java-аннотациями. Разметку же отдельных тестов можно делать средствами Scala, но при большом их количестве это становится крайне утомительно.

В противовес этому досадному недоразумению в библиотеке specs2 в этом плане всё гораздо более положительно - можно задавать произвольную иерархию тестов, которая к тому же не обязательно должна быть древовидной. Тем не менее (возможно по причинам исторического характера) используется эта библиотека в 7 раз реже (согласно mvnrepository.com).


>>Click here to continue<<

Scala bin






Share with your best friend
VIEW MORE

United States America Popular Telegram Group (US)