Heim >Java >javaLernprogramm >Dev/Prod-Parität: Spring Boot Testcontainer

Dev/Prod-Parität: Spring Boot Testcontainer

DDD
DDDOriginal
2025-01-10 11:03:43517Durchsuche

Einführung

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?

Dev/prod parity : Spring Boot Testcontainers

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.


Testen Sie alles, was Sie containerisieren können: Datenbank, Message Broker und mehr

„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:

  • Starten Sie die erforderlichen Dienste und bereiten Sie die Infrastruktur vor, indem Sie Docker-Container einrichten und Ihre Anwendung so konfigurieren, dass sie dieses Setup als Testinfrastruktur verwendet.
  • Führen Sie Ihre Tests auf der Docker-Infrastruktur aus.
  • Bereinigen Sie die Docker-Infrastruktur automatisch, sobald die Tests abgeschlossen sind

Dokumentation der Testcontainers-Bibliothek


Implementierung von Spring Boot Testcontainern

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.

  • Als statische Felder deklarierte Container werden von den Testmethoden gemeinsam genutzt. Sie werden nur einmal gestartet, bevor eine Testmethode ausgeführt wird, und gestoppt, nachdem die letzte Testmethode ausgeführt wurde.
  • Als Instanzfelder deklarierte Container werden für jede Testmethode gestartet und gestoppt.

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!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Vorheriger Artikel:Java FoundationNächster Artikel:Java Foundation