TDD – Hướng phát triển kiểm thử

May 31, 2024

Khái niệm TDD chắc chắn không còn xa lạ đối với chúng ta – các nhà phát triển phần mềm. Tuy nhiên rất nhiều bạn vẫn còn mơ hồ về khái niệm, cũng như chưa biết áp dụng vào project thực tế như thế nào? Vậy TDD là gì? Triển khai nó như thế nào? Loạt bài viết này sẽ phần nào cung cấp câu trả lời cho bạn.

TDD là gì?

TDD – Test Driven Development có thể được định nghĩa là một kỹ thuật lập trình hướng dẫn các nhà phát triển viết mã mới chỉ khi test tự động thất bại. Điều này tránh sự trùng lặp của mã. TDD có nghĩa là Hướng phát triển kiểm thử. Mục tiêu chính của TDD là làm cho mã rõ ràng hơn, đơn giản và không có lỗi.

TDD bắt đầu bằng việc thiết kế và phát triển các thử nghiệm cho mọi chức năng nhỏ của ứng dụng. Trong phương pháp TDD, đầu tiên, thử nghiệm được phát triển nhằm xác định và xác nhận những gì mã của bạn sẽ làm.

Trong quy trình Kiểm thử phần mềm thông thường, trước tiên chúng tôi tạo mã và sau đó kiểm tra. Các thử nghiệm có thể thất bại vì các thử nghiệm được phát triển ngay cả trước khi phát triển. Để vượt qua bài kiểm tra, nhóm phát triển phải phát triển và tái cấu trúc mã. Tái cấu trúc mã nguồn có nghĩa là thay đổi một số mã mà không ảnh hưởng đến hành vi của nó.

Khái niệm đơn giản của TDD là viết và sửa các unit test thất bại trước khi viết mã mới (trước khi phát triển). Điều này giúp tránh trùng lặp mã khi chúng tôi viết một lượng nhỏ mã tại một thời điểm để vượt qua các unit test. (Các unit không có gì ngoài các điều kiện yêu cầu mà chúng tôi cần kiểm tra để hoàn thành chúng).

TDD là một quá trình phát triển và chạy test tự động trước khi phát triển ứng dụng thực tế. Do đó, đôi khi TDD còn được gọi là Test First Development.

Tại sao dùng TDD?

Một lợi thế đáng kể của TDD là nó cho phép bạn thực hiện các bước nhỏ khi viết phần mềm. Đây là một thực tế mà tôi đã thúc đẩy trong nhiều năm vì nó hiệu quả hơn nhiều so với cố gắng viết mã theo các bước lớn. Ví dụ: giả sử bạn thêm một số mã chức năng mới, biên dịch và kiểm tra nó. Rất có thể là các bài kiểm tra của bạn sẽ bị phá vỡ bởi các lỗi tồn tại trong mã mới. Dễ dàng tìm thấy hơn và sau đó sửa chữa những khiếm khuyết đó nếu bạn đã viết hai dòng mã mới hơn hai nghìn. Hàm ý là bộ kiểm tra trình biên dịch và hồi quy của bạn càng nhanh thì càng hấp dẫn khi tiến hành các bước nhỏ hơn và nhỏ hơn. Tôi thường thích thêm một vài dòng mã chức năng mới, thường là ít hơn mười, trước khi tôi biên dịch lại và chạy lại các bài kiểm tra của mình.

Cách thực hiện TDD

Các bước sau xác định cách thực hiện kiểm tra TDD:

Viết một test mới
Chạy tất cả các test và xem nếu test đó fails
Viết mã
Chạy tất cả các test và refactor code
Lập lại các bước trên

Chu kỳ của TDD

Viết test
Làm cho nó chạy fail.
Thay đổi mã để làm cho nó pass, tức là Refactor.
Lặp lại quá trình.

Một số giải thích về TDD

TDD không phải là về “Testing” hay về “Design”
TDD không có nghĩa là “viết một số testcase, sau đó xây dựng một hệ thống vượt qua các testcase đó.
TDD không có nghĩa là “làm nhiều testcase”.

TDD Vs Testing truyền thống

Phương pháp TDD chủ yếu là một kỹ thuật đặc tả. Nó đảm bảo rằng mã nguồn của bạn được kiểm tra kỹ lưỡng.

Với thử nghiệm truyền thống, một thử nghiệm thành công tìm thấy một hoặc nhiều khiếm khuyết. Nó giống như TDD. Khi kiểm tra thất bại, bạn đã đạt được tiến bộ vì bạn biết rằng bạn cần giải quyết vấn đề.
TDD đảm bảo rằng hệ thống của bạn thực sự đáp ứng các yêu cầu được xác định cho nó. Nó giúp xây dựng sự tự tin của bạn về hệ thống của bạn.
Trong TDD tập trung nhiều hơn vào mã để xác minh xem thử nghiệm có hoạt động đúng không. Trong thử nghiệm truyền thống, tập trung nhiều hơn vào thiết kế trường hợp thử nghiệm. Liệu thử nghiệm sẽ cho thấy việc thực hiện đúng / không đúng của ứng dụng để đáp ứng các yêu cầu.
Trong TDD, bạn sẽ được kiểm tra 100%. Mỗi dòng mã sẽ được kiểm tra, không giống như kiểm tra truyền thống.

Acceptance TDD và Developer TDD là gì?

TDD có 2 cấp độ:

Mức chấp nhận (Acceptance TDD (ATDD)): với ATDD thì bạn viết một test chấp nhận đơn (single acceptance test) hoặc một đặc tả hành vi (behavioral specification) tùy theo cách gọi của bạn; mà test đó chỉ cần đủ cho các mã chường trình sản phẩm thực hiện (pass or fail) được test đó. Acceptance TDD còn được gọi là Behavior Driven Development (BDD).
Mức lập trình (Developer TDD): với mức này bạn cần viết một test lập trình đơn (single developer test) đôi khi được gọi là unit test mà test đó chỉ cần đủ cho các mã chường trình sản phẩm thực hiện (pass or fail) được test đó. Developer TDD thông thường được gọi là TDD.

You need to login in order to like this post: click here