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

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.

ĐĂNG KÝ NHẬN TÀI LIỆU HỌC LẬP TRÌNH MIỄN PHÍ TẠI ĐÂY.

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:

1. Viết một test mới
2. Chạy tất cả các test và xem nếu test đó fails
3. Viết mã
4. Chạy tất cả các test và refactor code
5. 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 độ:

1. 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).
2. 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.

Các công cụ hỗ trợ

Ngày này TDD đã quá phổ biến, có rất nhiều công cụ giúp bạn triển khai TDD dễ dàng hơn. Hầu hết chúng là các nền tảng cho kiểm thử mã nguồn mức đơn vị (unit test).

• cpputest
• csUnit (.Net)
• CUnit
• DUnit (Delphi)
• DBFit
• DBUnit
• DocTest (Python)
• Googletest
• HTMLUnit
• HTTPUnit
• JMock
• JUnit
• Moq
• NDbUnit
• NUnit
• OUnit
• PHPUnit
• PyUnit (Python)
• SimpleTest
• TestNG
• TestOoB (Python)
• Test::Unit (Ruby)
• VBUnit
• XTUnit
• xUnit.net

Thiết kế dựa trên kiểm thử (TDD) là một kỹ thuật phát triển, trong đó trước tiên bạn phải viết một mã kiểm thử chạy thất bại, trước khi bạn viết mã nguồn cho chức năng mới. TDD đang nhanh chóng được nhiều nhà phát triển phần mềm theo phương pháp Agile chấp nhận để phát triển mã nguồn ứng dụng, và thậm chí còn được thông qua bởi những nhà quản trị cơ sở dữ liệu theo phương pháp Agile (Agile DBA) cho phát triển cơ sở dữ liệu. TDD nên được xem như là bổ sung cho phương pháp phát triển hướng mô hình Agile (Agile Model Driven Development – AMDD) và cả hai có thể được sử dụng cùng nhau.

TDD không thay thế phương pháp kiểm thử truyền thống, thay vào đó nó định nghĩa một cách thức để đảm bảo việc thực hiện các unit test một cách hiệu quả. Hiệu ứng phụ của TDD là các kiểm thử cung cấp một đặc tả hoạt động cho mã nguồn. TDD được đánh giá tin cậy trong thực tế và được nhiều lập trình viên phần mềm quan tâm và lựa chọn.

Bài tiếp theo chúng ta sẽ thử những dòng test đầu tiên.

Nguồn tham khảo: https://www.guru99.com/test-driven-development.html

Đăng ký nhận bộ tài liệu kỹ năng dành cho lập trình viên tại đây