```
@Retention(RUNTIME)
@Target(TYPE)
@ExtendWith(LegacyJUnit5SnapshotExtension.class)
@API(status=DEPRECATED,
     since="1.7.0")
@Deprecated(since="1.7.0",
            forRemoval=true)
public @interface EnableSnapshotTests
```
Deprecated, for removal: This API element is subject to removal in a future version.
Since 1.7.0 - This class is deprecated in favor of the EnableSnapshotTests class within the junit5 package. Note that the variant in the junit5 package already comes with all the deprecated methods removed and replaced with their respective alternatives. For details, inspect the deprecation notes on the attributes within this class.
Enabling snapshot tests

Enables the snapshot-test capabilities. When you mark a class with this annotation, you can use snapshot assertions by declaring a parameter of type SnapshotDsl.Snapshot in your test case like this:
```
 @EnableSnapshotTests
 class MyTestClass {

     @Test
     void testSomething(Snapshot snapshot) throws Exception {
         Object actual = ...
         snapshot.assertThat(actual).asText().matchesSnapshotText();
     }
 }
 
```
asText() will 'serialize' actual test results using Object.toString(). There are additional StructuredDataProvider implementations that allow to serialize snapshots as json, xml or html. To use them, you need to declare their respective maven modules as dependency.
```
     @Test
     void testSomething(Snapshot snapshot) throws Exception {
         Object actual = ...
         snapshot.assertThat(actual).as(TextSnapshot.text).matchesSnapshotText();
         snapshot.assertThat(actual).as(JsonSnapshot.json).matchesSnapshotText();
         snapshot.assertThat(actual).as(XmlSnapshot.xml).matchesSnapshotText();
     }
 
```
When providing a structured data format like json/xml (or in general: an implementation of StructuredDataProvider) you can make use of structural assertions to compare snapshots. Depending on the implementation, those might provide better error messages than plain text comparison.
```
     @Test
     void testSomething(Snapshot snapshot) throws Exception {
         Object actual = ...
         snapshot.assertThat(actual).as(JsonSnapshot.json).matchesSnapshotStructure();
         snapshot.assertThat(actual).as(XmlSnapshot.xml).matchesSnapshotStructure();
     }
 
```
Parameterized tests

Snapshot tests can be combined with JUnit5's parameterized tests, but only when you provide an explicit name for each snapshot assertion. With the default automatic snapshot naming scheme, snapshots would otherwise be overridden for each parameterized execution.
```
     @ParameterizedTest
     @Values(strings = { "string1", "string2" })
     void testSomething(String parameter, Snapshot snapshot) throws Exception {
         Object actual = ...

         // BAD: would choose the same snapshot file name 'testSomething_0.snapshot' disregarding the parameter
         // (Note: this could be desired if you expect the same output for all parameters)
         snapshot.assertThat(actual).as...;

         // GOOD: Append the parameter's value to the snapshot name to have separate snapshots per execution
         // This will create snapshots named 'testSomething_0_string1.snapshot' and 'testSomething_0_string2.snapshot'
         snapshot.namedAccordingTo(SnapshotNaming.withParameters(parameter))
                 .assertThat(actual).as...;
 
```
Updating snapshots

Snapshots can become outdated when your code under test changes on purpose. In that case you can advice the framework to override existing snapshots with your code under test's actual result by placing the annotation ForceUpdateSnapshots on either the whole snapshot test class or on a single test method.
Orphaned snapshots

Snapshot files can become orphans if, for example you rename a test class/method or you change the snapshot assertions within a test. This framework comes with a sophisticated approach for detecting those orphaned files. By default, we will log a warning with the found orphan. You can temporarily place the DeleteOrphanedSnapshots annotation on a snapshot test class to have those files deleted automatically.
See Also:

SnapshotDsl.Snapshot, SnapshotNaming, SnapshotDirectory, SnapshotTestOptions, DeleteOrphanedSnapshots, ForceUpdateSnapshots

Optional Element Summary

Optional Elements
Modifier and Type	Optional Element	Description
`boolean`	`forceUpdateSnapshots`	Deprecated, for removal: This API element is subject to removal in a future version. Since 1.1.0 - Use the `ForceUpdateSnapshots` annotation instead.
`java.lang.String`	`snapshotDirectory`	Deprecated, for removal: This API element is subject to removal in a future version. Since 1.7.0 - Use `SnapshotDirectory` annotation instead.
`boolean`	`softAssertions`	Deprecated, for removal: This API element is subject to removal in a future version. Since 1.7.0 - Soft assertions will no longer be supported from version 2.0 on.

- Element Detail
  - snapshotDirectory
```
@Deprecated(since="1.7.0",
            forRemoval=true)
@API(status=DEPRECATED,
     since="1.7.0")
java.lang.String snapshotDirectory
```
    Deprecated, for removal: This API element is subject to removal in a future version.
    Since 1.7.0 - Use SnapshotDirectory annotation instead.
    
    Define the snapshot directory relative to src/test/resources. If this is not defined, snapshots will be stored in a directory structure according to the package name of the test class.
    
    Returns:
    
    The relative directory to store the snapshots.
    
    Default:
    
    ""
- - forceUpdateSnapshots
```
@API(status=DEPRECATED,
     since="1.1.0")
@Deprecated(since="1.1.0",
            forRemoval=true)
boolean forceUpdateSnapshots
```
    Deprecated, for removal: This API element is subject to removal in a future version.
    Since 1.1.0 - Use the ForceUpdateSnapshots annotation instead.
    
    Can be set to true temporarily in order to force to update the persisted snapshots with the current test results.
    Warning: While this is attribute is set to true, all tests containing snapshot assertions will fail with an error. This is to prevent accidentally checking in disabled assertions.
    After snapshots have been updated, you should reset this flag to false and run the tests again before checking your code into any SCM.
    
    Returns:
    
    Whether to update the stored snapshots.
    
    See Also:
    
    SnapshotDsl.ChooseAssertions.justUpdateSnapshot(), ForceUpdateSnapshots
    
    Default:
    
    false
- - softAssertions
```
@Deprecated(since="1.7.0",
            forRemoval=true)
@API(status=DEPRECATED,
     since="1.7.0")
boolean softAssertions
```
    Deprecated, for removal: This API element is subject to removal in a future version.
    Since 1.7.0 - Soft assertions will no longer be supported from version 2.0 on. You could use AssertJ's SoftAssertions as a replacement.
    
    When enabled, a test method using snapshot assertions will continue to execute, even if a snapshot assertion failed. This allows to collect multiple failing snapshots with a single test execution.
    The failures from all snapshot comparisons within the single test methods will be collected and reported after the test method completed.
    
    Returns:
    
    Whether to enable soft assertions. Defaults to false.
    
    Default:
    
    false

Annotation Type EnableSnapshotTests

Enabling snapshot tests

Parameterized tests

Updating snapshots

Orphaned snapshots

Optional Element Summary

Element Detail

snapshotDirectory

forceUpdateSnapshots

softAssertions