Clean Architecture & Design Patterns in Practice · บทเรียน

กลยุทธ์การทดสอบแบบแบ่งเลเยอร์

พัฒนากลยุทธ์การทดสอบที่ครอบคลุมการทดสอบหน่วย การทดสอบการผสานรวม และการทดสอบตั้งแต่ต้นจนจบในทุกเลเยอร์ของสถาปัตยกรรมสะอาด

กลยุทธ์การทดสอบแบบแบ่งเลเยอร์ เป็นบทเรียน Clean Architecture & Design Patterns in Practice ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Clean Architecture & Design Patterns in Practice และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Clean Architecture & Design Patterns in Practice มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

Intro to Layered Testing

Welcome to Layered Testing Strategy! In Clean Architecture, separating concerns allows for a highly effective testing approach.

This lesson explores how to build a comprehensive testing strategy, covering unit, integration, and end-to-end tests across different architectural layers.

The Test Pyramid

A common visualization for testing strategies is the Test Pyramid. It suggests:

Many small, fast Unit Tests at the base.
Fewer Integration Tests in the middle.
Very few, slow End-to-End Tests at the top.

This structure ensures quick feedback and high confidence where it matters most, aligning perfectly with Clean Architecture's decoupled nature.

Unit Tests: Entities

Unit tests are the foundation. In Clean Architecture, we start by testing our Entities. These contain core business rules and should be completely independent of any frameworks or databases.

Focus on testing the pure logic of your entities. They should be fast and deterministic.

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());
    }
  }
}

Unit Tests: Use Cases

Next, we unit test our Use Cases (Interactors). These encapsulate application-specific business rules. They orchestrate entities and interact with ports (interfaces) to external layers.

When testing use cases, we mock or stub any external dependencies (like repositories or gateways) to isolate the use case's logic.

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.");
    }
  }
}

Integration Tests: Adapters

Integration tests verify the interactions between different components and layers. In Clean Architecture, this often means testing the concrete implementations of our Interface Adapters (e.g., a database repository, an external API gateway) with the actual external systems.

We check if the adapter correctly translates data and interacts with the external service as expected.

Integration Tests: Data Persistence

This type of integration test focuses on the Repository implementations. We ensure they correctly save and retrieve data from the actual database (or an in-memory substitute like H2 for faster tests).

It verifies that your data mapping (e.g., from Entity to DTO) and database queries work as intended.

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.");
    }
  }
}

Integration Tests: Presentation Layer

Testing the Presentation Layer (e.g., Controllers, Presenters) involves ensuring they correctly receive requests, call the appropriate use cases, and format responses. We can use mocks for the underlying use cases.

This confirms the API contract and data flow from the external world into your application's use cases.

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.");
    }
  }
}

End-to-End (E2E) Tests

End-to-End tests simulate a complete user journey through the entire system, from the UI (or API client) to the database and back. They cover all layers and external services.

While slow and expensive, E2E tests provide the highest confidence that the whole system works together as intended. They are crucial for critical business flows.

Benefits of Layered Testing

Implementing a layered testing strategy in Clean Architecture brings significant benefits:

Faster Feedback: Unit tests give immediate results.
Easier Debugging: Failures are isolated to specific layers.
Robust Architecture: Ensures each component and interaction works.
Confidence in Changes: Allows safe refactoring and new feature development.
CI/CD Ready: Supports automated pipelines effectively.

Check Your Knowledge

Let's check your understanding of layered testing in Clean Architecture.

Recap: Testing Clean Systems

You've learned how to develop a comprehensive layered testing strategy for Clean Architecture. We covered:

The Test Pyramid and its levels: Unit, Integration, and E2E.
Unit testing Entities and Use Cases, often using mocks.
Integration testing adapters like Repositories and Controllers.
The role of End-to-End tests for full system validation.

By applying these strategies, you ensure your Clean Architecture codebase is robust, maintainable, and reliable.

คำถามที่พบบ่อย

บทเรียน “กลยุทธ์การทดสอบแบบแบ่งเลเยอร์” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “กลยุทธ์การทดสอบแบบแบ่งเลเยอร์” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Clean Architecture & Design Patterns in Practice ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Clean Architecture & Design Patterns in Practice มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “กลยุทธ์การทดสอบแบบแบ่งเลเยอร์”

พัฒนากลยุทธ์การทดสอบที่ครอบคลุมการทดสอบหน่วย การทดสอบการผสานรวม และการทดสอบตั้งแต่ต้นจนจบในทุกเลเยอร์ของสถาปัตยกรรมสะอาด คุณปฏิบัติ Clean Architecture & Design Patterns in Practice ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Clean Architecture & Design Patterns in Practice หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Clean Architecture & Design Patterns in Practice บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน

บทเรียน “กลยุทธ์การทดสอบแบบแบ่งเลเยอร์” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Clean Architecture & Design Patterns in Practice นี้ได้ไหม

ได้ บทเรียน Clean Architecture & Design Patterns in Practice ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

กลยุทธ์การทดสอบแบบแบ่งเลเยอร์
ข้อควรพิจารณาด้านการนำสถาปัตยกรรมสะอาดไปใช้งาน
การพัฒนาและบำรุงรักษาระบบสะอาด
ฟังก์ชันวัดความเหมาะสมของสถาปัตยกรรมและการทดสอบขอบเขต

← กลับไปที่ Clean Architecture & Design Patterns in Practice