Phát triển hướng kiểm thử (TDD)

Trong Kiểm thử Tags #bdd #tdd #software-testing Xuất bản 30/09/2021

Phát triển theo hướng kiểm thử là gì?

Phương pháp phát triển hướng kiểm thử (TDD-Test Driven Development) trước tiên kiểm thử được phát triển để chỉ định và xác nhận những gì mã sẽ làm. Nói một cách dễ hiểu, các trường hợp kiểm thử được tạo trước khi viết mã lệnh. Mục đích của TDD là làm cho mã lệnh rõ ràng, đơn giản hơn và không có lỗi.

Phát triển theo hướng kiểm thử bắt đầu với việc thiết kế và phát triển các trường hợp kiểm thử cho mọi chức năng nhỏ của ứng dụng. TDD hướng dẫn các nhà phát triển viết mã mới chỉ khi kiểm thử tự động không thành công. Điều này tránh trùng lặp mã. Dạng đầy đủ của TDD là Phát triển theo hướng kiểm thử.

Khái niệm đơn giản của TDD là viết và sửa các trường hợp kiểm thử bị lỗ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 ta viết một lượng nhỏ mã tại một thời điểm để vượt qua các trường hợp kiểm thử. (Kiểm thử không là gì ngoài các điều kiện yêu cầu mà chúng ta cần kiểm tra để đáp ứng chúng).

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

TDD hoàn toàn xoay chuyển sự phát triển truyền thống. Khi bạn lần đầu tiên triển khai một tính năng mới, câu hỏi đầu tiên bạn đặt ra là liệu thiết kế hiện tại có phải là thiết kế tốt nhất có thể cho phép bạn triển khai chức năng đó hay không. Nếu vậy, bạn tiến hành theo phương pháp TFD. Nếu không, bạn cấu trúc lại cục bộ để thay đổi phần thiết kế bị ảnh hưởng bởi tính năng mới, cho phép bạn thêm tính năng đó dễ dàng nhất có thể. Do đó, bạn sẽ luôn cải thiện chất lượng thiết kế của mình, do đó làm việc dễ dàng hơn trong tương lai.

Các bước thực hiện TDD

  • Thêm một Kiểm thử
  • Chạy tất cả các Kiểm thử và thấy kiểm thử không thành công
  • Viết mã lệnh
  • Chạy kiểm thử và tái cấu trúc lại mã nguồn
  • Lặp lại bước trên cho đến khi tất cả các kiểm thử đều thành công

TDD với Kiểm thử truyền thống

Cách tiếp cận 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 ở cấp độ xác nhận.

  • Với kiểm thử truyền thống, một kiểm thử thành công sẽ tìm thấy một hoặc nhiều khiếm khuyết. Nó cũng giống như TDD. Khi một trường hợp kiểm thử không thành công, bạn đã đạt được tiến bộ vì bạn biết rằng bạn cần phải 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 bạn xây dựng niềm tin về hệ thống của mình.
  • Trong TDD tập trung nhiều hơn vào mã sản xuất để xác minh xem kiểm thử có hoạt động bình thường hay không. Trong kiểm thử truyền thống, tập trung nhiều hơn vào thiết kế trường hợp kiểm thử. Việc kiểm tra sẽ cho thấy việc thực thi ứng dụng đúng / sai để đáp ứng các yêu cầu.
  • Trong TDD, bạn đạt được kiểm thử độ phủ 100%. Mọi dòng mã đều được kiểm tra, không giống như kiểm thử truyền thống.
  • Sự kết hợp của cả kiểm thử truyền thống và TDD dẫn đến tầm quan trọng của việc kiểm thử hệ thống hơn là sự hoàn thiện của hệ thống.
  • Trong Mô hình Agile (AM), bạn nên "kiểm thử có mục đích". Bạn nên biết lý do tại sao bạn đang kiểm thử thứ gì đó và mức độ cần thiết của nó.

TDD Chấp nhận và TDD Phát triển

Có 2 cấp độ TDD

  • Chấp nhận TDD (Acceptance TDD-ATDD): Với ATDD, bạn viết một kiểm thử chấp nhận duy nhất. Kiểm thử này đáp ứng yêu cầu của đặc điểm kỹ thuật hoặc đáp ứng hành vi của hệ thống. Sau đó, hãy viết mã cho sản phẩm hoặc chức năng vừa đủ để thực hiện kiểm thử chấp nhận đó. Kiểm thử chấp nhận tập trung vào hành vi tổng thể của hệ thống. ATDD còn được gọi là Phát triển theo định hướng hành vi (BDD-Behavioral Driven Development).

  • Phát triển TDD: Với Phát triển TDD, bạn viết thử nghiệm phát triển đơn lẻ, tức là thử nghiệm đơn vị và sau đó chỉ cần mã sản xuất đủ để thực hiện kiểm thử đó. Bài kiểm thử đơn vị tập trung vào mọi chức năng nhỏ của hệ thống. Phát triển TDD được gọi đơn giản là TDD.

     

Mục tiêu chính của ATDD (BDD) và TDD là xác định các yêu cầu chi tiết, có thể thực thi được cho giải pháp của bạn trên cơ sở đúng lúc (JIT). JIT có nghĩa là chỉ xem xét những yêu cầu cần thiết trong hệ thống. Vì vậy, tăng hiệu quả.

Tài liệu tham khảo

https://www.tutorialspoint.com/software_testing_dictionary/test_driven_development.htm
https://dev.to/vepo/a-very-simple-test-driven-development-tutorial-3309
https://dzone.com/articles/get-started-with-test-driven-development-a-beginne
https://www.guru99.com/test-driven-development.html