Entwickler-/Produktparität zielt darauf ab, die Kluft zwischen Entwicklungs- und Produktionsumgebungen zu verringern. Dieser Artikel befasst sich mit der Lücke in den Tools, insbesondere beim Integrationstest mit Spring Testcontainern, um Entwicklung und Produktion so ähnlich wie möglich zu gestalten.
Bei der Durchführung von Integrationstests mit Datenbanken müssen wir alle CRUD-Vorgänge sorgfältig verwalten. Dies ist in einer zentralisierten Datenbankumgebung von entscheidender Bedeutung, in der ein Test wie TestDeleteUserByID_ShouldReturnOk() „versehentlich“ beschließen könnte, das Konto unseres treuesten Kunden zu löschen, der seit 2015 bei uns ist ?♂️
Um solche Risiken zu mindern, können wir Lösungen wie Datenbanktransaktionen zur Isolierung von Testdaten in Betracht ziehen. Beispielsweise könnte ein Test eine Transaktion starten, um Daten zu ändern, und dann am Ende ein Rollback durchführen, wodurch die Datenbank in ihrem ursprünglichen Zustand verbleibt.
Dies wirft jedoch eine kritische Frage auf: WAS TESTET DER TEST?
Was passiert, wenn die Isolierung fehlschlägt und der Code Änderungen ausführt, die irgendwie nicht rückgängig gemacht werden können, was zu Datenlecks in der Produktionsumgebung führt? Der potenzielle Schaden in solchen Szenarien ist erheblich.
Alternativ stellen eigenständige Tests mit einer In-Memory-Datenbank wie H2DB auch einige Herausforderungen dar. Auch wenn es einfach einzurichten ist, unterscheidet sich H2DB von RDBMS, sodass die Wahrscheinlichkeit hoch ist, dass Tests zwischen Entwicklungs- und Produktionsumgebungen unterschiedliche Ergebnisse liefern, sodass wir diesen Ergebnissen nicht vertrauen können.
https://stackoverflow.com/questions/62778900/syntax-error-h2-database-in-postgresql-compatibility
Die nächst weniger problematische Lösung besteht darin, die Datenbank zu klonen, was einen weniger riskanten Ansatz mit einer produktionsähnlichen Umgebung bietet. Allerdings hat diese Methode ihre Grenzen. Da ORMs die Erstellung und Einrichtung des Produktionsdatenbankschemas automatisieren, müssen wir darüber nachdenken, wie wir die geklonte Entwicklungsdatenbank synchron halten können.
„Testcontainers ist eine Java-Bibliothek, die JUnit-Tests unterstützt und einfache, wegwerfbare Instanzen gängiger Datenbanken, Selenium-Webbrowser oder alles andere bereitstellt, das in einem Docker-Container ausgeführt werden kann.“
Ursprünglich für Java entwickelt, wurde es inzwischen erweitert, um andere Sprachen wie Go, Rust und .NET zu unterstützen.
Die Hauptidee von Testcontainers besteht darin, eine On-Demand-Infrastruktur bereitzustellen, die von der IDE aus ausgeführt werden kann und in der Tests durchgeführt werden können, ohne dass Mock- oder In-Memory-Dienste erforderlich sind, und mit automatischer Bereinigung.
Dies können wir in drei Schritten erreichen:
Dokumentation der Testcontainers-Bibliothek
In ApplicationIntegrationTests, der Basisklasse für Integrationstests, definieren wir einen statischen PostgreSQLContainer. Dieser Container wird in allen von dieser Klasse abgeleiteten Testinstanzen verwendet.
Die @Testcontainers-Annotation ermöglicht die Erkennung aller mit @Container annotierten Felder, die Verwaltung ihrer Container-Lebenszyklusmethoden und das Starten der Container.
Die Annotation @DynamicPropertySource ermöglicht es uns, Eigenschaften dynamisch in unsere Testumgebung einzufügen.
@Testcontainers @ActiveProfiles("test") public abstract class ApplicationIntegrationTests { @Container protected static PostgreSQLContainer<?> postgres=new PostgreSQLContainer<>("postgres:17.2-alpine") .withDatabaseName("testcontainersproject") .withUsername("root") .withPassword("root"); @DynamicPropertySource static void initialize(DynamicPropertyRegistry registry) { registry.add("spring.datasource.url",postgres::getJdbcUrl); registry.add("spring.datasource.username",postgres::getUsername); registry.add("spring.datasource.password",postgres::getPassword); } }
Alternativ können wir auf die Verwendung von @Testcontainers und @Container verzichten und stattdessen den Containerlebenszyklus direkt mit @BeforeAll und @AfterAll verwalten. Dieser Ansatz ermöglicht eine bessere Kontrolle darüber, wann und wie Container gestartet und gestoppt werden
@BeforeAll public static void runContainer(){ postgres.start(); } @AfterAll static void stopContainers() { postgres.stop(); }
In der Rückrufmethode @AfterAll stoppen wir explizit den Postgres-Container. Selbst wenn wir den Container jedoch nicht explizit stoppen, bereinigt Testcontainers die Container automatisch und fährt sie am Ende des Testlaufs herunter.
Jetzt können wir Integrationstests erstellen, indem wir ApplicationIntegrationTests wie folgt erweitern.
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) @AutoConfigureMockMvc public class CategoryControllerTest extends ApplicationIntegrationTests { private static final String CATEGORY_ENDPOINT="/categories"; @Autowired private MockMvc mockMvc; @Autowired private CategoryRepository categoryRepository; @Test void TestGetAllCategories_ShouldReturnOk() throws Exception { List<Category> categories = List.of( new Category("Electronics", "All kinds of electronic gadgets from smartphones to laptops"), new Category("Books", "A wide range of books from novels to educational textbooks") ); categoryRepository.saveAll(categories); MvcResult mvcResult=mockMvc.perform( get(CATEGORY_ENDPOINT). contentType(MediaType.APPLICATION_JSON) ) .andExpect(status().isOk()) .andReturn(); var response=mvcResult.getResponse().getContentAsString(); assertNotNull(response); assertFalse(response.isEmpty()); } }
Das obige ist der detaillierte Inhalt vonDev/Prod-Parität: Spring Boot Testcontainer. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!