Ren arkitektur og designmønstre i praksis · Lektion

Lagdelt teststrategi

Udvikl en omfattende teststrategi, der dækker unit-, integrations- og end-to-end-tests på tværs af alle lag i Clean Architecture.

Lektion 1 af 411 trin

Lagdelt teststrategi er en gratis Ren arkitektur og designmønstre i praksis-lektion på CoddyKit. Dette er lektion 1 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i Ren arkitektur og designmønstre i praksis, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Ren arkitektur og designmønstre i praksis-kurset indeholder 4 lektioner i alt.

Introduktion til lagdelt testning

Velkommen til en lagdelt teststrategi! I Clean Architecture gør adskillelsen af ansvar det muligt at anvende en meget effektiv tilgang til testning.

I denne lektion undersøger vi, hvordan du opbygger en omfattende teststrategi, der dækker enheds-, integrations- og ende-til-ende-test på tværs af forskellige arkitekturlag.

Testpyramiden

En almindelig visualisering af teststrategier er testpyramiden. Den foreslår:

Mange små, hurtige enhedstest i bunden.
Færre integrationstest i midten.
Meget få, langsomme ende-til-ende-test øverst.

Denne struktur sikrer hurtig feedback og høj sikkerhed dér, hvor det betyder mest, og passer perfekt til Clean Architectures afkoblede natur.

Enhedstest: Entiteter

Enhedstest er fundamentet. I Clean Architecture begynder vi med at teste vores entiteter. De indeholder centrale forretningsregler og bør være helt uafhængige af frameworks og databaser.

Fokuser på at teste den rene logik i dine entiteter. De bør være hurtige og deterministiske.

public class Product {
  private String name;
  private double price;

  public Product(String name, double price) {
    if (name == null || name.trim().isEmpty()) {
      throw new IllegalArgumentException("Name invalid.");
    }
    if (price <= 0) {
      throw new IllegalArgumentException("Price must be positive.");
    }
    this.name = name;
    this.price = price;
  }

  public String getName() { return name; }
  public double getPrice() { return price; }
}

public class Main {
  public static void main(String[] args) {
    try {
      Product p = new Product("Book", 25.00);
      System.out.println("Product OK: " + p.getName());
    } catch (IllegalArgumentException e) {
      System.out.println("Error: " + e.getMessage());
    }

    try {
      new Product("Pen", -5.00);
    } catch (IllegalArgumentException e) {
      System.out.println("Test Failed (expected): " + e.getMessage());
    }
  }
}

Enhedstest: Anvendelsestilfælde

Derefter enhedstester vi vores anvendelsestilfælde (interactors). De indkapsler applikationsspecifikke forretningsregler. De orkestrerer entiteter og interagerer med porte (grænseflader) til ydre lag.

Når vi tester anvendelsestilfælde, simulerer eller stub'er vi alle eksterne afhængigheder (som repositories eller gateways) for at isolere anvendelsestilfældets logik.

interface ProductRepository {
  void save(String name, double price);
}

class MockProductRepository implements ProductRepository {
  private boolean saved = false;
  @Override
  public void save(String name, double price) {
    System.out.println("Mock: Saving " + name + "...");
    saved = true;
  }
  public boolean isSaved() { return saved; }
}

class CreateProductUseCase {
  private final ProductRepository repo;
  public CreateProductUseCase(ProductRepository repo) {
    this.repo = repo;
  }
  public void execute(String name, double price) {
    // Entity validation here in a real app, or trust entity's constructor
    repo.save(name, price);
    System.out.println("Product creation requested.");
  }
}

public class Main {
  public static void main(String[] args) {
    MockProductRepository mockRepo = new MockProductRepository();
    CreateProductUseCase useCase = new CreateProductUseCase(mockRepo);

    useCase.execute("Coffee Mug", 15.00);

    if (mockRepo.isSaved()) {
      System.out.println("Test PASSED: Product saved via mock.");
    } else {
      System.out.println("Test FAILED: Product not saved.");
    }
  }
}

Integrationstest: Adaptere

Integrationstest kontrollerer interaktionerne mellem forskellige komponenter og lag. I Clean Architecture betyder det ofte, at vi tester de konkrete implementeringer af vores grænsefladeadaptere (f.eks. et databaserepository eller en gateway til en ekstern API) sammen med de faktiske eksterne systemer.

Vi kontrollerer, om adapteren oversætter data korrekt og interagerer med den eksterne tjeneste som forventet.

Integrationstest: Datalagring

Denne type integrationstest fokuserer på implementeringerne af repositories. Vi sikrer, at de gemmer og henter data korrekt fra den faktiske database (eller en in-memory-erstatning som H2 for hurtigere test).

Den bekræfter, at din datakortlægning (f.eks. fra entitet til DTO) og dine databaseforespørgsler fungerer efter hensigten.

import java.util.HashMap;
import java.util.Map;

interface ProductRepository {
  void save(String id, String name, double price);
  String findNameById(String id);
}

class InMemoryProductRepository implements ProductRepository {
  private final Map<String, String> products = new HashMap<>(); // id -> name
  @Override
  public void save(String id, String name, double price) {
    products.put(id, name);
    System.out.println("In-Memory: Saved " + name + " (ID: " + id + ")");
  }
  @Override
  public String findNameById(String id) {
    return products.get(id);
  }
}

public class Main {
  public static void main(String[] args) {
    InMemoryProductRepository repo = new InMemoryProductRepository();

    repo.save("P001", "Keyboard", 75.00);
    String foundName = repo.findNameById("P001");

    if ("Keyboard".equals(foundName)) {
      System.out.println("Integration Test PASSED: Keyboard found.");
    } else {
      System.out.println("Integration Test FAILED: Keyboard not found.");
    }
  }
}

Integrationstest: Præsentationslaget

Test af præsentationslaget (f.eks. controllere og præsentatorer) indebærer, at vi sikrer, at de modtager forespørgsler korrekt, kalder de relevante anvendelsestilfælde og formaterer svar. Vi kan bruge simuleringer af de underliggende anvendelsestilfælde.

Det bekræfter API-kontrakten og dataflowet fra omverdenen ind i din applikations anvendelsestilfælde.

interface CreateProductUseCase {
  void execute(String name, double price);
}

class MockCreateProductUseCase implements CreateProductUseCase {
  private boolean called = false;
  @Override
  public void execute(String name, double price) {
    System.out.println("Mock Use Case: Executing for " + name);
    called = true;
  }
  public boolean wasCalled() { return called; }
}

class ProductController {
  private final CreateProductUseCase useCase;
  public ProductController(CreateProductUseCase useCase) {
    this.useCase = useCase;
  }
  public String createProductEndpoint(String jsonBody) {
    // Simulate JSON parsing
    String name = jsonBody.contains("name":"Laptop") ? "Laptop" : "Unknown";
    double price = jsonBody.contains("price":1200) ? 1200.00 : 0.0;

    useCase.execute(name, price);
    return "Product creation request received.";
  }
}

public class Main {
  public static void main(String[] args) {
    MockCreateProductUseCase mockUseCase = new MockCreateProductUseCase();
    ProductController controller = new ProductController(mockUseCase);

    String requestBody = "{\"name\":\"Laptop\", \"price\":1200.00}";
    String response = controller.createProductEndpoint(requestBody);

    System.out.println("Controller Response: " + response);
    if (mockUseCase.wasCalled()) {
      System.out.println("Test PASSED: Use Case was invoked.");
    } else {
      System.out.println("Test FAILED: Use Case not invoked.");
    }
  }
}

Ende-til-ende-test (E2E)

Ende-til-ende-test simulerer en komplet brugerrejse gennem hele systemet, fra brugergrænsefladen (eller API-klienten) til databasen og tilbage igen. De dækker alle lag og eksterne tjenester.

Selvom de er langsomme og dyre, giver E2E-test den største sikkerhed for, at hele systemet fungerer sammen som tilsigtet. De er afgørende for kritiske forretningsflows.

Fordele ved lagdelt testning

Implementering af en lagdelt teststrategi i Clean Architecture giver betydelige fordele:

Hurtigere feedback: Enhedstest giver øjeblikkelige resultater.
Lettere fejlfinding: Fejl isoleres til bestemte lag.
Robust arkitektur: Sikrer, at hver komponent og interaktion fungerer.
Sikkerhed ved ændringer: Gør det muligt at refaktorere sikkert og udvikle nye funktioner.
Klar til CI/CD: Understøtter automatiserede pipelines effektivt.

Tjek din viden

Lad os tjekke din forståelse af lagdelt testning i Clean Architecture.

Besvar den i den interaktive lektion

Opsamling: Test af rene systemer

Du har lært at udvikle en omfattende, lagdelt teststrategi til Clean Architecture. Vi har gennemgået:

Testpyramiden og dens niveauer: enhedstest, integrationstest og E2E.
Enhedstest af entiteter og anvendelsestilfælde, ofte ved hjælp af simuleringer.
Integrationstest af adaptere som repositories og controllere.
Rollen for ende-til-ende-test ved validering af hele systemet.

Ved at anvende disse strategier sikrer du, at din Clean Architecture-kodebase er robust, vedligeholdelsesvenlig og pålidelig.

Gratis at komme i gang

Lær Ren arkitektur og designmønstre i praksis med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser: 12
Lektioner: 48

Start gratis Se hele kurset

Ofte stillede spørgsmål

Er lektionen “Lagdelt teststrategi” gratis?

Ja — hele teksten til “Lagdelt teststrategi” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af Ren arkitektur og designmønstre i praksis-kurset, skal du opgradere til CoddyKit PRO. Ren arkitektur og designmønstre i praksis-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Lagdelt teststrategi”?

Udvikl en omfattende teststrategi, der dækker unit-, integrations- og end-to-end-tests på tværs af alle lag i Clean Architecture. Du øver dig i Ren arkitektur og designmønstre i praksis med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på Ren arkitektur og designmønstre i praksis?

Der kræves ingen tidligere erfaring. Ren arkitektur og designmønstre i praksis på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 1 af 4.

Hvor lang tid tager lektionen “Lagdelt teststrategi”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne Ren arkitektur og designmønstre i praksis-lektion?

Ja. Alle Ren arkitektur og designmønstre i praksis-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

← Tilbage til Ren arkitektur og designmønstre i praksis