0Pricing
Testing Mastery: JUnit, Mockito & Integration Tests · บทเรียน

การปรับโครงสร้างโค้ดเพื่อความสามารถในการทดสอบ

เรียนรู้ว่า TDD นำไปสู่การออกแบบโค้ดที่ดีขึ้นโดยธรรมชาติอย่างไร และปรับโครงสร้างโค้ดอย่างปลอดภัยด้วยความมั่นใจจากการทดสอบของคุณ

การปรับโครงสร้างโค้ดเพื่อความสามารถในการทดสอบ เป็นบทเรียน Testing Mastery: JUnit, Mockito & Integration Tests ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Testing Mastery: JUnit, Mockito & Integration Tests และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Testing Mastery: JUnit, Mockito & Integration Tests มีบทเรียนทั้งหมด 4 บทเรียน

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

Refactoring in TDD: An Intro

In Test-Driven Development (TDD), the "Refactor" step is crucial. After writing a failing test (Red) and making it pass (Green), we enter the Refactor phase.

Refactoring means improving the internal structure of code without changing its external behavior. It's about making your code cleaner, more readable, and easier to maintain.

The Safety Net of Tests

Why is refactoring safe in TDD? Because you have a comprehensive suite of passing tests!

  • Confidence: Your tests act as a safety net, ensuring that any structural changes you make don't introduce new bugs.
  • Feedback: If a test fails after refactoring, you immediately know you've broken something, allowing you to revert or fix it.

This confidence allows developers to continuously improve code quality.

What is Testable Code?

Refactoring naturally leads to more testable code. But what makes code testable?

  • Small & Focused: Units of code (methods, classes) do one thing well.
  • Loose Coupling: Components have minimal dependencies on each other.
  • Clear Responsibilities: Each class or method has a single, well-defined purpose.

These principles make it easier to isolate and test individual parts.

Code Smell: Hidden Dependencies

Consider a class that processes data and also logs messages directly to the console. This introduces a "hidden dependency" on System.out, making it harder to test the processing logic in isolation.

We want to test if processData works, not if System.out.println works!

Example: Poorly Testable Code

Here's a simple ReportGenerator. Notice how it directly uses System.out.println. This makes it hard to test the report generation logic without seeing console output.

public class ReportGenerator {
  public String generateReport(String data) {
    // Simulate some complex processing
    String processedData = "Processed: " + data.toUpperCase();
    System.out.println("Log: Report generated for " + data);
    return processedData;
  }

  public static void main(String[] args) {
    ReportGenerator generator = new ReportGenerator();
    System.out.println(generator.generateReport("sales"));
  }
}

Refactoring: Extract Interface

To improve testability, we can introduce an interface for our logging mechanism. This decouples the ReportGenerator from a specific logging implementation.

An interface defines a contract: what methods a class must implement.

public interface Logger {
  void log(String message);
}

public class ConsoleLogger implements Logger {
  @Override
  public void log(String message) {
    System.out.println("Console: " + message);
  }
}

Refactoring: Dependency Injection

Now, we can inject the Logger dependency into the ReportGenerator's constructor. This is called Dependency Injection.

The ReportGenerator no longer creates its logger; it receives it. This makes it much easier to provide a "mock" logger during testing.

public interface Logger {
  void log(String message);
}

public class ConsoleLogger implements Logger {
  @Override
  public void log(String message) {
    System.out.println("Console: " + message);
  }
}

public class ReportGenerator {
  private final Logger logger;

  public ReportGenerator(Logger logger) {
    this.logger = logger;
  }

  public String generateReport(String data) {
    String processedData = "Processed: " + data.toUpperCase();
    logger.log("Report generated for " + data);
    return processedData;
  }

  public static void main(String[] args) {
    Logger consoleLogger = new ConsoleLogger();
    ReportGenerator generator = new ReportGenerator(consoleLogger);
    System.out.println(generator.generateReport("sales"));
  }
}

The Testability Advantage

With dependency injection, testing becomes much simpler:

  • You can pass a real ConsoleLogger for production.
  • For unit tests, you can pass a test double (like a mock) that records calls without actual console output. This allows you to verify that logger.log() was called as expected, without interfering with test output.

This makes your ReportGenerator's logic truly isolated and testable.

Continuous Improvement

Refactoring isn't a one-time event; it's a continuous habit within the TDD cycle. After every passing test, take a moment to look for ways to improve the code.

  • The Boy Scout Rule: Always leave the campsite cleaner than you found it. Apply this to code: always leave the module cleaner than when you started working on it.

This leads to a codebase that naturally evolves towards better design and higher quality.

Refactoring Benefits Check

Consider the benefits of refactoring for testability.

Recap: Refactoring for TDD

In this lesson, we explored the crucial "Refactor" step in TDD. We learned that refactoring, backed by passing tests, allows us to safely improve code design without altering behavior.

  • We saw how refactoring leads to more testable code by promoting loose coupling and dependency injection.
  • This enables easier isolation of units for testing and simpler use of test doubles.
  • Refactoring is a continuous process that improves code quality and maintainability over time.

Keep refactoring to build robust and clean software!

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

บทเรียน “การปรับโครงสร้างโค้ดเพื่อความสามารถในการทดสอบ” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การปรับโครงสร้างโค้ดเพื่อความสามารถในการทดสอบ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Testing Mastery: JUnit, Mockito & Integration Tests ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Testing Mastery: JUnit, Mockito & Integration Tests มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การปรับโครงสร้างโค้ดเพื่อความสามารถในการทดสอบ”

เรียนรู้ว่า TDD นำไปสู่การออกแบบโค้ดที่ดีขึ้นโดยธรรมชาติอย่างไร และปรับโครงสร้างโค้ดอย่างปลอดภัยด้วยความมั่นใจจากการทดสอบของคุณ คุณปฏิบัติ Testing Mastery: JUnit, Mockito & Integration Tests ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Testing Mastery: JUnit, Mockito & Integration Tests หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Testing Mastery: JUnit, Mockito & Integration Tests บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน

บทเรียน “การปรับโครงสร้างโค้ดเพื่อความสามารถในการทดสอบ” ใช้เวลานานแค่ไหน

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

ฉันเขียนและรันโค้ดในบทเรียน Testing Mastery: JUnit, Mockito & Integration Tests นี้ได้ไหม

ได้ บทเรียน Testing Mastery: JUnit, Mockito & Integration Tests ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

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

  1. แนะนำวงจร TDD
  2. การเขียนการทดสอบก่อน
  3. การปรับโครงสร้างโค้ดเพื่อความสามารถในการทดสอบ
  4. กฎสามข้อของ TDD
← กลับไปที่ Testing Mastery: JUnit, Mockito & Integration Tests