Skip to toolbar

Tìm hiểu mô hình TDD và BDD trong Agile

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

tim hieu mo hinh TDD

TDD (Test-Driven Development) là mô hình phát triển với trọng tâm hướng về việc kiểm thử. TDD được xây dựng theo hai tiêu chí: Test-First (Kiểm thử trước) và Refactoring (Điều chỉnh mã nguồn). Bạn có thể hiểu TDD chính là một phương pháp lập trình chú trọng vào việc test, “viết test trước viết code sau”.

Khi bạn định implement một function nào đó, bạn sẽ phải viết một function khác, sử dụng chính cái function bạn định implement, và khi chạy test tất nhiên nó sẽ fail, đơn giản là vì bạn chưa implement cái gì cả. Vì vậy việc tiếp theo là implement để làm cho nó hết fail (pass). Cuối cùng, bỏ chút thời gian ra refactor lại code cho đẹp và gọn gàng hơn.

Những lợi ích của TDD

  • Rõ ràng về những tiêu chí chấp nhận (Acceptance Criteria): Trước khi bắt tay vào code, bạn thường có một danh sách những đặc điểm bắt buộc cần phải có trong chức năng đó. Vì vậy, bạn hoàn toàn dựa vào những điều này để biết được cần phải test những gì. Điều này sẽ rất hữu ích vì bạn có thể an tâm rằng bạn không bỏ qua những tiêu chí chấp nhận mà khách hàng đưa ra.
  • Tập trung: Bạn sẽ trở nên năng suất hơn khi code, và TDD giúp bạn giữ năng suất của mình cao bằng việc giới hạn sự tập trung của bạn. Bạn sẽ viết một đoạn test thất bại, và sẽ tập trung cao độ để làm cho đoạn test đó được thành công. Điều đó bắt buộc bạn nghĩ tới những tính năng nhỏ nhất vào một thời điểm hơn là nghĩ về tổng thể hệ thống, và sau đó bạn có thể tập trung vào việc làm cho test thành công, hơn là dành nhiều tâm sức để nhìn vào bức tranh tổng thể ngay từ lúc đầu, điều mà sẽ dẫn đến nhiều bugs và nhiều thời gian dành cho việc phát triển.
  • Refactor an toàn hơn: Ngay khi bạn làm cho test thành công, vậy là bạn có thể refactor code mình một cách an toàn rồi. Nếu bạn phải làm việc với legacy code, hay code được viết bởi người khác, và không có test, bạn vẫn có thể thực hành TDD. Thay vì bạn nghĩ rằng bạn sẽ chỉ TDD đoạn code mà bạn đã viết, thì bạn hãy nghĩ rằng bạn sẽ TDD cho đoạn code mà bạn sắp viết. Vậy thì khi bạn thừa kế đoạn code của người khác, trước khi bắt đầu, hãy viết test mà bao quát được càng nhiều càng tốt. Điều đó giúp bạn có cơ sở vững chắc để refactor, hay thậm chí là thêm tính năng mới, mà lại không lo rằng bạn đã làm hỏng cấu trúc nguyên bản.
  • Ít Bugs hơn: TDD sinh ra nhiều test, điều mà có thể dẫn tới thời gian chạy test lâu hơn. Tuy nhiên, với độ bao phủ test tốt, bạn có thể tiết kiệm thời gian mà bạn sẽ dùng để sửa bug. Điều này không có nghĩa là bạn sẽ có thể nghĩ tới tất cả test case, mà có nghĩa rằng nếu có một bug xuất hiện, bạn vẫn có thể viết một đoạn test trước khi tìm cách sửa nó, điều đó sẽ đảm bảo là bug sẽ không xuất hiện nữa. Điều này cũng giúp bạn chỉ ra rõ bug đó xuất phát từ đâu và tái hiện lại các bước được.
  • Một tài liệu sống: Test có thể đóng vai trò như tài liệu cho một lập trình viên. Nếu bạn không rõ một class hay một library hoạt động ra sao, hãy đọc qua test của chúng. Với TDD, test thường được viết cho nhiều trường hợp, một trong đó có thể là bạn muốn sử dụng class ra sao. Vì vậy bạn có thể hiểu được yêu cầu của input mong muốn cho một method và bạn có thể kỳ vọng output thông qua những test so sánh.

Tìm hiểu mô hình BDD (Behavior Driven Development)

Như vậy, trong mô hình TDD nhiệm vụ kiểm thử do developer đảm nhiệm và vai trò chuyên hóa của người tester gần như không còn nữa. Chắc hẳn các bạn sẽ tự hỏi: “Vậy một Acceptance Tester như chúng ta có vai trò gì trong mô hình?”, “Tại sao tôi phải hiểu về TDD khi người ta không cần tôi trong quy trình đó?”
Quả thực, trong mô hình TDD người Acceptance Tester thực sự đã chết. Tuy nhiên, việc cộng gộp vai trò phát sinh vấn đề quá tải cho người developer. Để làm tốt công việc, xuyên suốt chu trình người developer phải chú ý thêm những vấn đề thuần túy của kiểm thử (test) như: “Cái gì cần test và cái gì không?” “Viết bao nhiêu kịch bản là đủ?” “Làm sao để hiểu là test đó thất bại?” “Bắt đầu test từ đâu?” …
Để giải quyết vần đề phát sinh mà vẫn tận dụng triệt để lợi ích mà TDD mang lại, Dan North phát triển một mô hình mới với tên gọi: Behavior-Driven Development – BDD (hoặc ta có thể hiểu là Acceptance Test-Driven Development – ATDD).
Trong đó, một vai trò mới trong việc thiết kế kiểm thử (Test Design) được đặt ra:
Thay vì chờ đợi sản phẩm hoàn thành và kiểm thử, người tester/analyst tham gia vào quá trình xây dựng mã nguồn với vai trò phân tích và xây dựng hệ thống kịch bản kiểm thử dưới góc độ ngôn ngữ tự nhiên dễ hiểu từ các yêu cầu (requirement). Đồng thời, họ giúp đỡ developer trong việc giải thích và đưa ra các phương án xây dựng mã nguồn mang tính thực tiễn với người dùng ngay trước khi bắt tay xây dựng.
Người developer liên hệ mật thiết với người tester và xây dựng mã nguồn với những phương án mà tester cung cấp theo mô hình TDD.
Kịch bản kiểm thử được phân chia làm 2 lớp: Lớp chấp nhận (feature/acceptance test) và Lớp đơn vị (unit test).
Theo đó, kịch bản kiểm thử lớp đơn vị mang thuần tính thiết kế và phục vụ cho việc kiểm thử lớp đơn vị (Unit test) còn kịch bản kiểm thử lớp chấp nhận có thể được tái sử dụng cho quá trình kiểm thử hồi quy về sau (Regression Test)Mô hình BDD - TDD trong Agile mô phỏng bởi Paul LittleburyTừ mô hình trên ta dễ dàng nhìn nhận được sự ưu việt BDD mang lại đặc biệt là trong các dự án phần mềm lớn và phức tạp, khi cả hai khía cạnh phân hóa vai trò và chất lượng phải đi đôi. Ngoài ra, việc chạy kịch bản kiểm thử và xử lý sớm các vấn đề thiết kế ngay trong khâu xây dựng giúp giảm thiểu tối đa chi phí và công sức sữa chữa lỗi.
Trong khi khái niệm BDD mang tính lý thuyết, việc ứng dụng của nó lại đặt nặng sự thực nghiệm. Để phát huy lợi ích về thời gian trong việc xây dựng kịch bản kiểm thử, ngôn ngữ và cách truyền tải là 1 thử thách khi phải đáp ứng khả năng đọc hiểu từ cả 2 khía cạnh: tự nhiên và thiết kế. Bằng sự vay mượn từ ngôn ngữ viết User Story, ngôn ngữ Gherkin được phát triển để phục vụ nhu cầu đó với cấu trúc đơn giản, hướng đối tượng và tương đồng cho mọi kịch bản: Given – When – Then

Related Articles

Adhoc Testing

Adhoc Testing là gì? Thuật ngữ Adhoc testing là phương pháp kiểm thử dạng Black box test mà không theo cách thông thường. Với quy…

Responses

Your email address will not be published. Required fields are marked *

Chào bạn!

Để nhận được những bí quyết giúp bạn trở thành Tester chuyên nghiệp, hãy để lại thông tin của bạn bên dưới, chúng tôi sẽ gửi chúng cho bạn!