Làm thế nào để thêm test vào legacy code?

Question

Accepted Answer

**Legacy code** (code thường chưa được test, khó thay đổi) là thách thức để test — nó có thể có dependency rối rắm và không có test. Thêm test an toàn liên quan đến các kỹ thuật như **characterization test**, **seam** để phá vỡ dependency, và cải thiện dần dần, cho phép thay đổi an toàn hơn.

## Thách thức của legacy code

```text
Legacy code thường: chưa test, coupling chặt, khó hiểu, rủi ro khi thay đổi:
  → không có test → thay đổi nó nguy hiểm (bạn không biết mình có làm hỏng gì không)
  → khó test → dependency rối rắm (không cô lập unit được); không thiết kế để test
→ một vấn đề con-gà-quả-trứng: để thay đổi an toàn bạn cần test, nhưng khó để test.
```

## Characterization test (ghim hành vi hiện tại)

```text
CHARACTERIZATION (golden master) test → bắt hành vi HIỆN TẠI của code như nó vốn có
  (kể cả khi bạn không hiểu hết / nó có lỗi):
  → viết test assert cái nó THỰC SỰ làm bây giờ → một LƯỚI AN TOÀN
  → rồi bạn có thể refactor/thay đổi với sự tự tin rằng hành vi được bảo toàn
→ Đừng assert cái nó NÊN làm — assert cái nó LÀM, để bảo vệ chống regression.
```

## Phá vỡ dependency (seam)

```text
Để cô lập code khó test, tìm/tạo SEAM (chỗ để thay thế dependency):
  → trích xuất dependency sau interface; inject chúng; dùng các refactor an toàn nhỏ nhất
    để làm code test được (kỹ thuật của Michael Feathers)
  → cẩn thận phá vỡ dependency để bạn có thể đưa code vào test, rồi test, rồi refactor
```

## Cách tiếp cận dần dần

```text
✓ Thêm test QUANH code TRƯỚC khi thay đổi nó (một lưới an toàn cho thay đổi)
✓ Tập trung vào vùng bạn ĐANG THAY ĐỔI / rủi ro cao / giá trị cao (không phải toàn bộ codebase cùng lúc)
✓ Cải thiện dần dần — để code tốt hơn một chút mỗi lần ("boy scout rule")
✓ Dùng characterization test để bắt hành vi, rồi refactor hướng tới khả năng test
```

## Tại sao điều này quan trọng

Hiểu cách thêm test vào legacy code là kiến thức cấp senior có giá trị vì **hầu hết công việc thực tế liên quan đến code hiện có, thường chưa được test**, và cải thiện nó an toàn là một thách thức phổ biến, quan trọng, nên nó liên quan thực tiễn.

Legacy code (chưa test, coupling chặt, khó thay đổi) đặt ra một **vấn đề con-gà-quả-trứng** thực: để thay đổi nó an toàn bạn cần test, nhưng khó để test (dependency rối rắm, không thiết kế để test) — và thay đổi code chưa test nguy hiểm vì bạn không biết mình có làm hỏng gì không.

Hiểu các kỹ thuật để giải quyết điều này là kiến thức thực hành có giá trị. **Characterization test** (bắt hành vi *hiện tại* của code như nó vốn có, assert cái nó thực sự làm thay vì cái nó nên làm — kể cả khi không hiểu hết) cung cấp một **lưới an toàn** cho phép bạn refactor và thay đổi với sự tự tin rằng hành vi hiện có được bảo toàn — một kỹ thuật then chốt để làm việc với code bạn không hiểu hết.

Hiểu **phá vỡ dependency qua seam** (tìm hoặc tạo chỗ để thay thế dependency, dùng các refactor an toàn tối thiểu để làm code rối rắm test được — các kỹ thuật từ công trình của Michael Feathers về legacy code) là thiết yếu để đưa code khó test vào test.

Hiểu **cách tiếp cận dần dần** — thêm test quanh code trước khi thay đổi nó (một lưới an toàn cho thay đổi), tập trung vào vùng đang được thay đổi hoặc rủi ro cao/giá trị cao (không phải toàn bộ codebase cùng lúc), và cải thiện dần dần (boy scout rule) — phản ánh cách thực dụng, thực tế để cải thiện hệ thống legacy theo thời gian.

Vì hầu hết phát triển thực tế liên quan đến legacy code hiện có, thường chưa test phải được thay đổi an toàn (một tình huống phổ biến, thách thức), và vì hiểu các kỹ thuật (characterization test cho một lưới an toàn, seam để phá vỡ dependency, cải thiện dần dần) cho phép làm điều này, hiểu cách thêm test vào legacy code là kiến thức cấp senior có giá trị — liên quan thực tiễn cho thực tế phổ biến của việc làm việc với code chưa test hiện có, phản ánh kinh nghiệm và kỹ thuật cần thiết để cải thiện hệ thống legacy an toàn, một năng lực quan trọng cho kỹ sư senior thường phải làm code chưa test an toàn hơn để thay đổi.