Currently we provide a wild mix of possibilities to configure and fine tune the behavior of the snapshot test engine
Some aspects are configured via annotations only (see @SnapshotTestOptions annotation)
Some aspects can be configured via annotation but can be overridden in the DSL (i.e. @SnapshotTestDirectory)
Some annotations work on class level only, some work on class level and test method level (the latter taking precedence)
Some aspects can only be configured via DSL (i.e. snapshot naming)
Having stuff configured via annotations has the advantage that those information are static and its easier to use them for orphan detection (especially regarding the snapshot directory). Also it allows to easily share the configuration for all tests within the same class, which makes each test clearer and less cluttered.
On the other hand, those many annotations and their inconsistent semantics make the framework more complicated and the public API less discoverable.
The DSL as single entry point to all the functionality is pretty appealing in that regards.
Currently we provide a wild mix of possibilities to configure and fine tune the behavior of the snapshot test engine
@SnapshotTestOptionsannotation)@SnapshotTestDirectory)Having stuff configured via annotations has the advantage that those information are static and its easier to use them for orphan detection (especially regarding the snapshot directory). Also it allows to easily share the configuration for all tests within the same class, which makes each test clearer and less cluttered.
On the other hand, those many annotations and their inconsistent semantics make the framework more complicated and the public API less discoverable. The DSL as single entry point to all the functionality is pretty appealing in that regards.