Tại sao nên sử dụng Test Driven Development (TDD)

Bài viết này mục đích chủ yếu là phân tích tính ưu việt của TDD với hi vọng giành được sự đồng tình của các nhà quản lý, người dạy và người học. Quy trình được giới thiệu sau đây không quá phức tạp, tuy nhiên nó đòi hỏi phải hiểu đúng và thực hiện nghiêm túc. Tuy nhiên, thực tế trong ngành CNTT của chúng ta: việc kiểm thử (nghĩa hẹp mà từ “test” đang được hiểu) chỉ được thực hiện sau khi chương trình viết hoàn chỉnh!

Phát triển hướng kiểm thử TDD (Test-Driven Development) là một phương pháp tiếp cận cải tiến để phát triển phần mềm trong đó kết hợp phương pháp Phát triển kiểm thử trước (Test First Development) và phương pháp Điều chỉnh lại mã nguồn (Refactoring). Mục tiêu quan trọng nhất của TDD là hãy nghĩ về thiết kế của bạn trước khi viết mã nguồn cho chức năng.

TDD (Test Driven Development) là một phương thức làm việc, hay một quy trình viết mã hiện đại. Lập trình viên sẽ thực hiện thông qua các bước nhỏ (BabyStep) và tiến độ được đảm bảo liên tục bằng cách viết và chạy các bài test tự động (automated tests). Quá trình lập trình trong TDD cực kỳ chú trọng vào các bước liên tục sau:

1. Viết 1 test cho hàm mới. Đảm bảo rằng test sẽ fail.
2. Chuyển qua viết code sơ khai nhất cho hàm đó để test có thể pass.
3. Tối ưu hóa đoạn code của hàm vừa viết sao cho đảm bảo test vẫn pass và tối ưu nhất cho việc lập trình kế tiếp
4. Lặp lại cho các hàm khác từ bước 1 Thực tế, nên sử dụng UnitTestFramework cho TDD (như JUnit trong Java), chúng ta có thể có được môi trường hiệu quả vì các test được thông báo rõ rang thông qua màu sắc:

• Đỏ: test fail, chuyển sang viết function cho test pass
• Xanh lá: viết một test mới hoặc tối ưu code đã viết trong màu đỏ.

Test trước hay test sau?

“Test trước” là dấu hiệu quan trọng của TDD. Quy trình đầy đủ sẽ là “test trước, trong và sau”. Mô hình “ba test” này gọi là Test-Driven Development (TDD).

TDD = TFD + Refactor

• Trong thực tiễn phát triển phần mềm, test dần thể hiện được vai trò của nó. Năm 1994, Kent Beck viết test framework đầu tiên cho môi trường ngôn ngữ SmallTalk. Với ưu thế rõ rệt, TDD nhanh chóng được tiếp thu và hầu như các ngôn ngữ lớn trên thế giới đều đã có test framework của mình. Ngày nay, TDD đã trở thành một chuẩn mực trong việc phát triển phần mềm.

• TDD được hiểu là việc phát triển phần mềm có sự tham gia ( đóng vai trò định hướng) chặt chẽ của test. Về mặt triển khai, TDD là mô thức phát triển phần mềm đã được quy trình hoá.

Trước khi bắt đầu, hãy nhớ khái niệm test trong TDD đã được mở rộng hơn so với lập trình truyền thống.

Phân biệt test với dò lỗi (bug)

• Công đoạn test trong “test sau” (lập trình truyền thống) là việc sau khi viết xong toàn bộ, người ta đưa chương trình vào môi trường production (môi trường làm việc thật) hoặc mô phỏng để chạy thử xem có phát sinh lỗi hay không.
• “Test trước”: khi bạn viết xong phần tử test đầu tiên (nó sẽ fail!) là khi bạn hiểu và trình bày được yêu cầu của bài toán.
• TDD (TFD + Refactor) chính là việc viết nháp với những dấu chấm lửng. Trong quá trình bạn viết test, bạn sẽ “nháp” và “xoá nháp” đi nhiều lần. Chỉ sau vài lượt như vậy, bài toán và thiết kế lời giải của bạn tiến rất gần đến mức thực tế!

Tư duy giải quyết vấn đề

Hiểu “test” theo nghĩa rộng của nó trong TDD, bạn sẽ không còn thấy nó ngược đời nữa. Trái lại, TDD còn rất tự nhiên, vì đó là quy trình được thiết kế cho con người:

• Khi gặp một bài toán, tư duy thông thường để giải quyết sẽ lần lượt qua các bước:
  • Bước 1: Phân tích vấn đề và đưa ra yêu cầu (tức kết quả muốn đạt được)
  • Bước 2: Phương hướng giải chung nhất (Trong lập trình: thường được thể hiện lại trên các sơ đồ UML)
  • Bước 3: Cho ra lời giải cụ thể bằng ngôn ngữ tự nhiên hay trừu tượng (Concept)
  • Bước 4: Thao tác (Trong lập trình: thể hiện lại lời giải trên bằng ngôn ngữ máy tính)
• Hầu hết mọi người sẽ đồng tình với các bước trên, nhưng đến khi bắt tay vào việc thì không phải ai cũng làm như vậy. Bước thao tác luôn là bước tốn nhiều thời gian nhất. Chính vì thế nhiều người bị sa đà vào bước này.

• Với các bài toán nhỏ, chẳng hạn như việc giao tiếp hàng ngày, 3 bước đầu diễn ra ngay trong vô thức. Khi các bài toán lớn hơn, nhất là khi nó trở thành một dự án tốn nhiều tháng thậm chí nhiều năm triển khai, thời gian cho 3 bước đầu lại không được nhân lên với tỉ lệ tương xứng!
• Hãy nhớ: Nếu chỉ cốt là giết được nhiều thời gian, bước 4 không cần đến kết quả của 3 bước trước