TDD là gì? Một số lý do nên sử dụng TDD

Bizfly Cloud

1382

27-06-2022

TDD là một phương pháp tiếp cận cải tiến hiện đại để phát triển phần mềm, kết hợp phương pháp Test First Development và Refactoring. Tham khảo bài viết dưới đây để hiểu rõ hơn TDD là gì, cùng Bizfly Cloud tìm hiểu cách thực hiện của nó cũng như các mô hình chu trình như thế nào nhé!

TDD là gì?

TDD là một mô hình phát triển với trọng tâm hướng về việc kiểm thử và được xây dựng theo hai tiêu chí là Test First và Refactoring. Các lập trình viên sẽ soạn thảo kịch bản kiểm thử cho yêu cầu đó trước tiên và chạy thử lần đầu. Việc chạy thử có thể thất bại bởi hiện tại chức năng dfos chưa được xây dựng và thông qua kết quả này, ta cũng có thể kiểm tra được kịch bản kiểm thử này có được viết đúng hay không.

Theo đó, các Developer sẽ xây dựng một lượng mã nguồn vừa đủ để lần chạy test thứ hai thành công dựa vào mong muốn của kịch bản. Nếu lần thứ hai kết quả vẫn là thất bại thì có nghĩa là thiết kế của bạn chưa ổn và Developer cần chỉnh sửa và thiết kế lại mã nguồn. Các Developer cần tiến hành chuẩn hóa đoạn mã nguồn và tiếp tục hồi quy với kịch bản kiểm thử tiếp theo sau khi kịch bản kiểm thử chạy thành công. Việc chuẩn hoá có thể bao gồm các công việc như thêm comment, loại bỏ các phần dư thừa, tối ưu biến,....

Trên thực tế, bạn nên sử dụng UnitTestFramework cho TDD như JUnit trong Java bởi các test được thông báo rõ ràng thông qua màu sắc. Cụ thể, màu đỏ là test fail, cần chuyển sang viết function cho test pass, màu xanh là tối ưu code đã viết trong màu đỏ hoặc viết một test mới. Chính vì vậy, chúng ta có thể có một môi trường của hiệu quả hơn cho quá trình viết mã.

Lý do nên sử dụng TDD

TDD hỗ trợ các lập trình viên xử lý hiệu quả các yêu cầu của khách hàng:

• Tập trung, tăng năng suất khi làm việc: TDD giúp bạn giữ năng suất cao khi code bằng việc giới hạn sự tập trung của bạn. Nếu test thất bại, TDD sẽ hỗ trợ bạn tập trung cao độ để đoạn test thành công bởi bạn bắt buộc phải cân nhắc các tính năng nhỏ nhất tại một thời điểm.
• Code gọn gàng, dễ hiểu, ít bugs hơn.
• Giảm chi phí cho việc thay đổi bởi các test được viết trước sẽ đảm bảo các thay đổi mới không phá vỡ các chức năng hiện có.
• TDD rút ngắn thời gian lập trình, đảm bảo chất lượng code và dùng cho spec detail.
• Refactor an toàn hơn ngay khi làm cho test thành công: Nếu bạn làm việc với một legacy code hoặc code không có test, bạn vẫn có thể thực hành TDD bằng cách viết test bao quát được càng nhiều càng tốt. Đây là cơ sở vững chắc để refactor, thêm tính năng mới mà không bị hỏng cấu trúc nguyên bản.
• TDD có thể coi như một tài liệu sống cho một lập trình viên tham khảo: Trong TDD, các test thường được viết cho nhiều trường hợp nên bạn có thể hiểu được yêu cầu của Input mong muốn cho một method và thông qua các test so sánh có thể kỳ vọng output.

Điểm khác biệt của TDD với mô hình truyền thống

Điểm khác biệt của TDD với mô hình truyền thống là các bước xây dựng tính năng phần mềm gần như đã được đảo ngược:

• Trong mô hình thác đổ thông thường, việc phân tích các yêu cầu thường được các BA tiến hành chuyên hoá và đa phần các Developer tiếp xúc với yêu cầu phần mềm dưới dạng bản thiết kế. Điều này dẫn đến một hệ quả tất yếu là lỗi phần mềm đến từ việc sản phẩm không tiện dụng với người dùng.
• Việc ứng dụng TDD giúp khoảng cách giữa đội ngũ thiết kế phần mềm và sản phẩm thực tiễn, tối ưu quy trình được thu hẹp lại.
• Các Developer thông qua kịch bản kiểm thử sẽ có cái nhìn trực quan về sản phẩm ngay trước khi xây dựng mã nguồn. Các sản phẩm tạo ra thường chính xác và gần gũi với người dùng hơn. Phần mã nguồn được thêm vào chỉ đủ để chạy kịch bản kiểm thử thành công nên hạn chế tối đa dự thừa và lỗi. TDD giúp mã nguồn đảm bảo phản ánh đúng và vừa đủ yêu cầu phần mềm, hạn chế công sức tối ưu mã nguồn về sau.

Cách thực hiện của TDD

Các bước thực hiện của TDD gồm:

• Tạo test
• Chạy test và kiểm tra xem có lỗi xảy ra không
• Viết code
• Chạy test và refactor để pass code
• Lặp lại quy trình gồm 4 bước trên

Bạn cần lưu ý rằng, TDD không phải tập trung về testing hoặc design. Nó có nghĩa là viết các kịch bản test và sau đó xây dựng một hệ thống sao cho nó pass các kịch bản này và TDD cũng không có nghĩa là test nhiều hơn.

Mô hình chu trình TDD

Một mô hình chu trình TDD gồm có các bước sau:

Start => Start next step (Write a Failing Test- Write Code to make test Pass)=> Refactor (Write Code to Make Test Pass)=> Can’t Think of more Tests => Stop.

Các cấp độ của TDD

TDD có 2 cấp độ, bao gồm:

• Mức Acceptance TDD (Mức độ chấp nhận): Với mức độ này, bạn cần viết một test single acceptance test (kiểm thử chấp nhận đơn) hoặc một behavioral specification (đặc tả hành vi) tuỳ vào cách đặt tên của bạn. Test này chỉ cần đáp ứng đủ cho các mã chương trình sản phẩm thực hiện được test đó. Ngoài ra, Acceptance TDD còn có thể được gọi là Behavior Driven Development (BDD).
• Mức Developer TDD (Mức độ lập trình): Ở mức này, bạn cần viết một single developer test (kiểm thử lập trình đơn). Nó còn được gọi là Unit test và các test này chỉ cần đủ cho các mã chương trình sản phẩm thực hiện được test đó. Thông thường, các Developer TDD được gọi là TDD.

Một số lỗi thường gặp khi áp dụng TDD

Trong quá trình áp dụng TDD, bạn có thể gặp phải một số lỗi điển hình dưới đây:

• Không quan tâm tới các test bị thất bại.
• Sau khi viết code cho test pass thường quên đi các thao tác tối ưu.
• Trong lúc viết code cho test pass, thực hiện tối ưu code.
• Đặt tên các test tối nghĩa, gây khó hiểu.
• Không bắt đầu từ các test đơn giản và không theo thứ tự của các baby step.
• Chỉ chú trọng chạy các test hiện tại đang bị fail.
• Kịch bản test được viết quá phức tạp và khó hiểu.

Trên đây là tất cả thông tin cơ bản giải đáp thắc mắc TDD là gì, lợi ích, cấp độ, cách thực hiện và một số vấn đề liên quan tới TDD. Hy vọng bài viết có thể giúp bạn hiểu rõ hơn về TDD và chu trình của nó. Từ đó thực hành và áp dụng giải quyết công việc của bạn một cách hiệu quả nhất.