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. Một quan điểm khác lại cho rằng TDD là một kỹ thuật lập trình. Nhưng nhìn chung, mục tiêu của TDD là viết mã nguồn sáng sủa, rõ ràng và có thể chạy được. Về tổng quan trong TDD lập trình viên sẽ viết bài kiểm tra trước và sau đó viết mã để vượt qua bài kiểm tra đó, và công việc này sẽ lặp đi lặp lại.

Test Driven Development (TDD), được phổ biến bởi Kent Beck. TDD là một trong những kỹ thuật chính được áp dụng trong phương pháp Extreme programming của ông.

Bây giờ hãy để trực quan hóa TDD theo các bước: 

  • Viết một bài kiểm thử – test (đủ để làm cho nó fail) 
  • Chạy nó, và thấy nó fail. 
  • Viết mã. 
  • Chạy thử nghiệm một lần nữa và xem nó vượt qua. 
  • Lặp lại bước 1

Vì vậy, bạn có thể thấy rằng TDD là một quy trình khép kín. Một lập trình viên đắm mình vào một dòng chảy giữ anh ta gắn liền với việc viết một bài kiểm thử và viết mã thực hiện tính năng.

Lợi ích của TDD

Thế lợi ích của TDD là gì? Có một số lợi ích khi làm theo phương pháp TDD.

  1. Nó giúp giữ khoảng cách giữa những gì bạn biết hoạt động và những gì không có trong mã của bạn rất nhanh. Bạn có thể tìm ra những gì đã sai, vì bạn đã có các bài test hoàn hảo vài giây trước.
  2. Nó giúp giảm thiểu thời gian cần thiết để cấu trúc lại mã nguồn của bạn, vì bạn có thể dễ dàng kiểm tra nếu có lỗi xảy ra khi bạn thực hiện tái cấu trúc.
  3. Nó làm cho việc thêm các tính năng mới trở nên dễ dàng hơn rất nhiều, vì bạn có thể thay đổi mã để phù hợp với các tính năng mới rất dễ dàng.
  4. Nó làm cho bạn tự tin hơn. Bạn không phải sợ code thêm nữa. Điều này là do các điểm 2 và 3. Ở trên, bạn có thể dễ dàng thêm các tính năng mới và cấu trúc lại mã của mình mà không phải lo lắng
  5. Nó giúp chia nhỏ sự phát triển phần mềm thành các phần mà bạn có thể quản lý. Đã từ lâu, nỗi sợ bắt đầu với một tính năng mới, vì vòng lặp TDD đủ ngắn để dễ dàng bắt đầu
  6. Nó giúp giảm chi phí thay đổi theo cấp số nhân khi phần mềm phát triển, vì bạn có thể thêm các tính năng mà không mất nhiều thời gian hơn.

Một cuộc nói chuyện rất hay về vấn đề này là Chi phí phần mềm tối đa của Konstantin Kudryashov.

Trong buổi nói chuyện, Konstantin nói về sự gia tăng theo cấp số nhân của chi phí thay đổi (thêm các tính năng mới) khi thời gian dự án tiếp tục nếu không có kiểm thử.

Chi phí thay đổi theo cấp số nhân mà không cần kiểm thử.

Nhưng nếu có kiểm thử, chi phí thay đổi sẽ được giới hạn, giúp việc thêm các tính năng mới dễ dàng hơn nhiều.

Chi phí thay đổi khi có kiểm thử.

Tất nhiên nó cũng có một số nhược điểm:

  1. Không dễ để bắt đầu với TDD. Nó đòi hỏi bạn phải biết rất nhiều thực hành và kỹ thuật mới. Ví dụ: Unit test, mocks, assertions .v.v
  2. Phải mất nhiều thời gian hơn khi phát triển, vì bạn đang kiểm thử mã của mình khi bạn viết mã.

Nhưng trên tất cả, tôi thích TDD hơn vì nó có nhiều mặt tích cực hơn và rất ít nhược điểm. TDD thực sự cần thiết nếu bạn muốn duy trì mã nguồn của mình trong một thời gian dài. Nếu bạn chỉ đang thử nghiệm mã của mình và không cần nó trong thời gian dài hơn, bạn có thể không cần TDD trong trường hợp đó.

Vậy, TDD bao gồm những gì? Vâng, bạn cần phải viết unit test trước khi bạn viết mã cho chức năng.

Một số loại kiểm thử TDD

  1. Kiểm thử đơn vị – Unit test: Kiểm tra đơn vị là mức kiểm tra thấp nhất bạn có thể làm. Nó thường là thử nghiệm một phương thức bên trong một lớp. Các bài kiểm tra đơn vị không tương tác trực tiếp với các lớp khác, mà thay vào đó chúng ta sẽ sử dụng mock để giả lập kết quả. Điều này làm cho các bài kiểm tra đơn vị bị cô lập và dễ dàng gỡ lỗi và cấu trúc lại.
  2. Kiểm thử tích hợp – Integration Testing: Kiểm thử tích hợp chạm vào nhiều hơn một lớp. Do đó, nó kiểm tra sự tích hợp giữa các lớp phụ thuộc. Nó được sử dụng để kiểm tra xem cơ sở dữ liệu có cho chúng ta kết quả chính xác hay không, API bên ngoài đang cung cấp cho chúng tôi dữ liệu chính xác không? V.v.Kiểm thử tích hợp chậm hơn đáng kể so với kiểm thử đơn vị, vì chúng tương tác với cơ sở dữ liệu và API bên ngoài.
  3. Kiểm tra chức năng – Function testing: Kiểm tra chức năng là một loại kiểm tra kiểm tra toàn bộ tính năng có thể gọi rất nhiều phụ thuộc. Thông thường, bạn sẽ kiểm tra route để có phản hồi chính xác hoặc phương thức Controller liên quan đến một tính năng nhất định trong ứng dụng. Chúng chậm hơn các bài kiểm tra tích hợp vì chúng cần nhiều phụ thuộc hơn.
  4. Kiểm tra chấp nhận – Acceptance testing: Kiểm tra chấp nhận là cấp độ kiểm tra cao nhất. Nó chỉ quan tâm nếu tính năng hoạt động thông qua điểm chấp nhận của khách hàng.

Trong phần tiếp theo chúng ta sẽ tìm hiểu cách thiết lập PHPUnit và bắt đầu với Unit test. Trước tiên chúng ta sẽ làm điều đó mà không theo phương pháp TDD. Điều này là do sẽ khó nắm bắt cả hai khái niệm trong khi chỉ bắt đầu học cách kiểm thử. Sau đó chúng ta sẽ làm theo hướng TDD.

 


Hãy tham gia nhóm Học lập trình để thảo luận thêm về các vấn đề cùng quan tâm.