Tìm hiểu mô hình TDD (Test - Driven Development)

Test-driven development (TDD) là một cách tiếp cận để phát triển kết hợp test đầu tiên. Bạn sẽ viết test trước khi bạn viết đầy đủ code để hoàn thành việc test và refactoring. Mục tiêu của TDD là một cách suy nghĩ để thông qua các yêu cầu hoặc thiết kế trước khi viết code các chức năng của hệ hống (TDD là một kĩ thuật quan trọng cả yêu cầu agile và thiết kế agile). Quan điểm khác, TDD là một kỹ thuật lập trình giúp viết code hoạt động sạch sẽ.

TDD là gì?

Các bước đầu tiên của phát triển test-first (TFD) được mô tả trong diagram hoạt động UML ở hình dưới đây. Đầu tiên, nhanh chóng add một test , đủ đơn giản để code fail. Bước tiếp theo là chạy các test, thường xuyên hoàn thành test mặc dù chỉ chạy các subset sẽ đem lại tốc độ cao hơn, để chắc chắn rằng new test trên thực tế là fail. Sau đó, bạn cần update functional code để làm nó pass qua các test mới. Bước thứ tư là chạy lại test một lần nữa. Nếu chúng fail, bạn lại tiếp tục update functional code và retest. Mỗi lần test pass bước tiếp theo là bắt đầu lại (đầu tiên bạn có thể cần refector bất kì sao chép nào trong design của bạn, chuyển từ TFD sang TDD).

Các bước trong Test-First Development (TFD)

Ta có thể hiểu TDD với công thức đơn giản sau: TDD = refectoring + TFD

TDD hoàn toàn xoay quanh development truyền thống. Đầu tiên khi bạn thực thi chức năng mới, câu hỏi đầu tiên mà bạn đề cập về design phải là một bản design tốt nhất có thể cho phép bạn triển khai được không. Nếu có bạn tiến hành thông qua cách tiếp cận TFD. Nếu không, bạn refactor cục bộ để thay đổi phần design bị ảnh hưởng bở chức năng mới, cho phép bạn thêm chức năng mới một cách dễ dàng. Kết quả là bạn sẽ luôn luôn cải thiện được chức năng của design, do đó ta sẽ dễ dàng làm việc hơn trong tương lai.

Thay vì viết code chức năng đầu tiên và sau đó mới thực thi testing code sau, nếu bạn viết lại tất cả, thay vào đó bạn biết test code trước khi viết functional code. Hơn nữa, ạn làm như vậy trong các bước rất nhỏ – một test và một ít functional code tương ứng tại một thời điểm. Một programmer thực hiện một phương pháp tiếp cận TDD từ chối viết một hàm mới cho đến khi có first test fails vì không có chức năng đó. Trong thực tế, họ từ chối thêm ngay cả một dòng code duy nhất cho đến khi một test tồn tại. Khi test đã được thực hiện, họ sẽ thực hiện yêu cầu công việc để đảm bảo pass các test. Điều này nghe đơn giản về nguyên tắc, nhưng khi bạn lần đầu tiên học tập để có một cách tiếp cận TDD , nó yêu cầu một kỉ luật tuyệt vời bời vì rất dễ bỏ qua và viết mã code mà không cần viết một test mới. Một trong những lợi thế của lập trình pair là pair của bạn sẽ giúp bạn theo dõi điều đó.

Có hai level của TDD:

• Acceptance TDD (ATDD): Với ATDD bạn viết một single acceptance test duy nhất, hoặc behavioral specification tùy thuộc vào thuật ngữ ưa thích của bạn, và sau đó chỉ đủ hiệu suất để thực thi code để hoàn thành test đó. Mục tiêu của ATDD là xác định các yêu cầu chi tiết, thực thi cho giải pháp của bạn trên cơ sở thời gian (JIT). ATDD còn được gọi là Behavior Driven Development (BDD).
• Developer TDD: Với developer TDD, bạn viết một single developer test, đôi khi được gọi không chính xác là một unit test, và sau đó chỉ cần đủ production code để hoàn thành test đó. Mục tiêu của developer TDD là chỉ định thiết kế chi tiết, thực thi cho giải pháp của bạn dựa trên cơ sở JIT. Developer TDD thường được gọi là TDD. Hình sau đây mô tả diagram hoạt động của UML cho thấy ATDD and developer TDD kết hợp với nhau như thế nào. Một cách lý tưởng, bạn sẽ viết một single acceptance test, sau đó thực hiện production code được yêu cầu để hoàn thành test đó, bạn sẽ thực hiện phương pháp TDD của developer. Điều này lần lượt yêu cầu bạn phải lặp lại nhiều lần việc viết test, viết production code, làm nó theo một chu kì làm việc theo developer TDD level.

Cách acceptance TDD and developer TDD làm việc với nhau.

Lưu ý rằng Hình trên đây giả định rằng bạn đang làm cả hai, mặc dù có thể làm một trong hai mà không có sự khác biệt. Trên thực tế, một số đội sẽ làm developer TDD mà không thực hiện ATDD, mặc dù nếu bạn đang thực hiện ATDD thì chắc chắn bạn đang làm developer TDD. Thách thức ở đây là cả hai dạng của TDD đều yêu cầu các học viên phải có kỹ năng kỹ năng testing kỹ thuật, các kỹ năng mà nhiều chuyên gia yêu cầu thường không có.

Testing thông qua xUnit Framework.

Kent Beck, người đã phổ biến TDD trong chương trình eXtreme (XP) (Beck 2000), định nghĩa hai quy tắc đơn giản cho TDD (Beck 2003). Trước tiên, ạn chỉ nên viết business code mới khi một automated test tự động fail. hứ hai, bạn nên loại bỏ bất kỳ trùng lặp mà bạn tìm thấy. Beck giải thích hai nguyên tắc đơn giản này tạo ra hành vi cá nhân và nhóm phức tạp như thế nào:

• Bạn phát triển cơ bản, với running code cung cấp phản hồi giữa các quyết định.
• Bạn viết tests bởi vì bạn không thể đợi 20 lần mỗi ngày để người khác viết chúng cho bạn.
• Môi trường phát triển của bạn phải đáp ứng nhanh những thay đổi nhỏ
• Thiết kế của bạn phải bao gồm các thành phần liên kết chặt chẽ và lỏng lẻo để làm cho việc testing dễ dàng hơn Đối với các developer, họ cần phải học cách viết unit test có hiệu quả. Kinh nghiệm của Beck’s experience dể có unit test tốt:
• Chạy nhanh (chúng có thiết lập ngắn, run times, và break downs).
• Chạy trong sự cô lập (bạn sẽ có thể sắp xếp lại chúng).
• Sử dụng dữ liệu giúp chúng dễ đọc và dễ hiểu.
• Sử dụng dữ liệu thực khi cần
• Đạt được một bước về mục tiêu chung của bạn.

Tài liệu tham khảo:

http://agiledata.org/essays/tdd.html