The key difference from our previous test is the absence of the @SpringBootTest annotation, which has been replaced with the @DataJpaTest annotation. The apparent simplicity of the test class itself is possible thanks to the @DataJpaTest annotation doing the bulk of the declarations and workload to configure the test environment. If we look inside the annotation definition, we will see a myriad of different internal annotations configuring all the necessary components. The important ones are the @AutoConfigure* annotations, such as @AutoConfigureDataJpa or @AutoConfigureTestDatabase. Those annotations essentially instruct Spring Boot to import the necessary component configurations when bootstrapping the test. For example, in @DataJpaTest, only Cache, DataJpa, TestDatabase, and TestEntityManager components would be configured and made available, which significantly reduces the test footprint, both memory-wise as well as startup and execution times. The specific configuration classes are then loaded, as we've seen before, from the META-INF/spring.factories descriptors provided by various artifacts.

With the right components initialized, we can take advantage of some preconfigured beans, such as TestEntityManager, which gives us the ability to interact with the test instance of the database, pre-initialize the desired state of its content, and manipulate test data. This gives us the guarantee that after each test suite is done executing, we will get a clean slate for the next set without the need of an explicit cleanup. This makes it easier to write tests, without having to worry about the order of execution and potential over stepping of changes from test suite to test suite, avoiding the inadvertent dirty state that makes tests inconsistent.