= Disabling Tests

Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
annotation, via one of the annotations discussed in
xref:writing-tests/conditional-test-execution.adoc[], or via a custom xref:extensions/conditional-test-execution.adoc[`ExecutionCondition`].

When `@Disabled` is applied at the class level, all test methods within that class are
automatically disabled as well.

If a test method is disabled via `@Disabled`, that prevents execution of the test method
and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
and corresponding extension APIs. However, that does not prevent the test class from being
instantiated, and it does not prevent the execution of class-level lifecycle callbacks
such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.

Here's a `@Disabled` test class.

[source,java,indent=0]
----
include::example$java/example/DisabledClassDemo.java[tags=user_guide]
----

And here's a test class that contains a `@Disabled` test method.

[source,java,indent=0]
----
include::example$java/example/DisabledTestsDemo.java[tags=user_guide]
----

[TIP]
====
`@Disabled` may be declared without providing a _reason_; however, the JUnit team
recommends that developers provide a short explanation for why a test class or test
method has been disabled. Consequently, the above examples both show the use of a reason
-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
teams even require the presence of issue tracking numbers in the _reason_ for automated
traceability, etc.
====

[NOTE]
====
`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
====
