/*
 * Copyright 2015-2019 the original author or authors.
 *
 * All rights reserved. This program and the accompanying materials are
 * made available under the terms of the Eclipse Public License v2.0 which
 * accompanies this distribution and is available at
 *
 * http://www.eclipse.org/legal/epl-v20.html
 */

package org.junit.jupiter.api;

import static org.apiguardian.api.API.Status.STABLE;

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

import org.apiguardian.api.API;

/**
 * {@code @BeforeAll} is used to signal that the annotated method should be
 * executed <em>before</em> <strong>all</strong> tests in the current test class.
 *
 * <p>In contrast to {@link BeforeEach @BeforeEach} methods, {@code @BeforeAll}
 * methods are only executed once for a given test class.
 *
 * <h3>Method Signatures</h3>
 *
 * <p>{@code @BeforeAll} methods must have a {@code void} return type,
 * must not be {@code private}, and must be {@code static} by default.
 * Consequently, {@code @BeforeAll} methods are not
 * supported in {@link Nested @Nested} test classes or as <em>interface default
 * methods</em> unless the test class is annotated with
 * {@link TestInstance @TestInstance(Lifecycle.PER_CLASS)}. {@code @BeforeAll}
 * methods may optionally declare parameters to be resolved by
 * {@link org.junit.jupiter.api.extension.ParameterResolver ParameterResolvers}.
 *
 * <h3>Inheritance</h3>
 *
 * <p>{@code @BeforeAll} methods are inherited from superclasses as long as
 * they are not <em>hidden</em> or <em>overridden</em>. Furthermore,
 * {@code @BeforeAll} methods from superclasses will be executed before
 * {@code @BeforeAll} methods in subclasses.
 *
 * <p>Similarly, {@code @BeforeAll} methods declared in an interface are
 * inherited as long as they are not <em>hidden</em> or <em>overridden</em>,
 * and {@code @BeforeAll} methods from an interface will be executed before
 * {@code @BeforeAll} methods in the class that implements the interface.
 *
 * <h3>Composition</h3>
 *
 * <p>{@code @BeforeAll} may be used as a meta-annotation in order to create
 * a custom <em>composed annotation</em> that inherits the semantics of
 * {@code @BeforeAll}.
 *
 * @since 5.0
 * @see AfterAll
 * @see BeforeEach
 * @see AfterEach
 * @see Test
 * @see TestFactory
 * @see TestInstance
 */
@Target({ ElementType.ANNOTATION_TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Documented
@API(status = STABLE, since = "5.0")
public @interface BeforeAll {
}

@@ -1541,16 +1541,36 @@
 eritance
+ and Execution Order
 %3C/h3%3E%0A *
@@ -2134,24 +2134,1221 @@
 terface.%0A *%0A
+ * %3Cp%3EJUnit Jupiter does not guarantee the execution order of multiple%0A * %7B@code @BeforeAll%7D methods that are declared within a single test class or%0A * test interface. While it may at times appear that these methods are invoked%0A * in alphabetical order, they are in fact sorted using an algorithm that is%0A * deterministic but intentionally non-obvious.%0A *%0A * %3Cp%3EIn addition, %7B@code @BeforeAll%7D methods are in no way linked to%0A * %7B@code @AfterAll%7D methods, i.e. there are no guarantees with regard to their%0A * wrapping behavior. For example, given two %7B@code @BeforeAll%7D methods%0A * %7B@code createA()%7D and %7B@code createB()%7D as well as two %7B@code @AfterAll%7D%0A * methods %7B@code destroyA()%7D and %7B@code destroyB()%7D, the order in which the%0A * %7B@code @BeforeAll%7D methods are executed (e.g. %7B@code createA()%7D before%0A * %7B@code createB()%7D) does not imply any order for the seemingly corresponding%0A * %7B@code @AfterAll%7D methods: (e.g. %7B@code destroyA()%7D might be called before%0A * %3Cem%3Eor%3C/em%3E after %7B@code destroyB()%7D). Thus, the JUnit Team recommends that%0A * developers declare at most one %7B@code @BeforeAll%7D/%7B@code @AfterAll%7D method%0A * per test class/interface unless there are no dependencies between them.%0A *%0A
  * %3Ch3%3ECompo

Document execution order and wrapping behavior