Юнит 5 Государство Союз

Точки расширения

Для большинства этапов жизненного цикла теста существует точка расширения:

• Постпроцессор тестового экземпляра
• BeforeAll Обратный звонок
• Тест и условие выполнения контейнера
• BeforeEach Callback
• Разрешение параметра
• Перед выполнением теста
• После выполнения теста
• Обработка исключений
• AfterEach Callback
• AfterAll Callback

Для каждой из этих точек расширения существует интерфейс, и, поскольку точки очень сфокусированы, интерфейсы довольно просты. Вот тот, для обратного вызова «Перед каждым»:

 public interface BeforeEachCallback extends Extension { void beforeEach(TestExtensionContext context) throws Exception; } 

Я уже отмечал, что тесты могут иметь параметры. Поскольку JUnit не знает, как создать экземпляр MyCoolClass , расширения должны предоставить их. Вот эта точка расширения:

 public interface ParameterResolver extends Extension { boolean supports( ParameterContext parameterContext, ExtensionContext extensionContext) throws ParameterResolutionException; Object resolve( ParameterContext parameterContext, ExtensionContext extensionContext) throws ParameterResolutionException; } 

Для каждого параметра JUnit будет вызывать support для каждого зарегистрированного расширения, генерировать исключение, если не одно из них возвращает true , и в противном случае запрашивать одно расширение для разрешения параметра.

В качестве подтверждения концепции команда написала расширение Mockito, которое @Mock параметры, помеченные @Mock . Может использоваться следующим образом:

 void myCoolClassTest(@Mock MyCoolClass instance) { // ... } 

Написание расширений

Чтобы создать расширение, вы просто реализуете интерфейсы, соответствующие точкам расширения, с которыми хотите взаимодействовать, и регистрируете свой класс в JUnit. Во время выполнения теста JUnit будет приостанавливать работу в каждой точке расширения, собирать всю соответствующую информацию в экземпляр ExtensionContext и вызывать все расширения, зарегистрированные в этой точке.

Контекст расширения предоставляет доступ ко многим интересным вещам, например, к тестовому классу или методу в виде AnnotatedElement , поэтому расширение может отражать их. Тогда есть ExtensionStore . Поскольку JUnit не заинтересован в отслеживании экземпляров расширений, он не дает никаких гарантий относительно их жизненного цикла. Следовательно, классы расширения должны быть без сохранения состояния и могут использовать хранилище для сохранения информации. Другим интересным аспектом является TestReporter , который позволяет расширениям (и тестам в этом отношении) публиковать сообщения таким образом, чтобы их можно было легко найти с помощью внешних инструментов.

В совокупности тестовое расширение, которое просто сообщает о времени выполнения теста, выглядит следующим образом:

 class SimpleBenchmarkExtension implements BeforeTestExecutionCallback, AfterTestExecutionCallback { // we need a namespace to access the store and a key to persist information private static final Namespace NAMESPACE = Namespace .create("com", "sitepoint", "SimpleBenchmarkExtension"); private static final String LAUNCH_TIME_KEY = "LaunchTime"; @Override public void beforeTestExecution(TestExtensionContext context) { storeNowAsLaunchTime(context); } @Override public void afterTestExecution(TestExtensionContext context) { long launchTime = loadLaunchTime(context); long elapsedTime = currentTimeMillis() - launchTime; report(context, elapsedTime); } private static void storeNowAsLaunchTime(ExtensionContext context) { context.getStore(NAMESPACE).put(LAUNCH_TIME_KEY, currentTimeMillis()); } private static long loadLaunchTime(ExtensionContext context) { return context.getStore(NAMESPACE).get(LAUNCH_TIME_KEY, long.class); } private static void report(ExtensionContext context, long elapsedTime) { String message = String .format("Test '%s' took %d ms.", context.getDisplayName(), elapsedTime); // 'publishReportEntry' pipes key-value pairs into the test reporter context.publishReportEntry(singletonMap("Benchmark", message)); } } 

Регистрация расширений

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

 @Benchmark @Test void test() { // ... } 

Архитектура

Быстрое погружение в архитектуру, что действительно интересно. Чтобы разделить заботу тестировщиков, разработчиков расширений и инструментов, а также позволить другим инфраструктурам тестирования воспользоваться преимуществами великолепной поддержки инструментов JUnit (ну, пока она еще не готова, но будет), JUnit 5 разделен на три подпроекта:

• JUnit Jupiter предоставляет API, о котором мы говорили ранее, и механизм, который обнаруживает и запускает тесты.
• JUnit Vintage адаптирует JUnit 3/4 для работы в новой архитектуре JUnit 5, что означает, что он также предоставляет движок.
• Платформа JUnit — это место, где происходит волшебство. Он предоставляет API для инструментов, чтобы инструктировать выполнение теста, и когда он вызывается, он находит механизмы тестирования (как два вышеупомянутых), передает инструкцию им и позволяет им делать свое дело.

С одной стороны, это облегчает запуск тестов JUnit 3, 4 и 5 в рамках одного механизма. Но разделение между платформой, которая содержит API движка, и реализациями движка также позволяет интегрировать все виды тестовых сред в механизм JUnit. Предполагая, что механизм TestNG будет существовать, вот как это получится:

Это большое дело! Создание новой среды тестирования — непростая битва, потому что принятие зависит от поддержки инструментов, а поддержка инструментов зависит от принятия. Теперь рамки могут вырваться из этого порочного круга! Они могут реализовать движок JUnit и получить полную поддержку во многих инструментах с первого дня.