Đây là tài liệu :
Phát triển dựa trên kiểm thử-TDD
Phát triển dựa trên kiểm thử (Test-Driven Development-TDD) là một phương pháp tiếp cận cải tiến để phát triển phần mềm trong đó kết hợp phương pháp Phát triển kiểm thử trước (Test First Development) và phương pháp Điều chỉnh lại mã nguồn (Refactoring). Mục tiêu quan trọng nhất của TDD là gì? Có quan điểm cho rằng mục tiêu của TDD là đặc tả (specification) chứ không phải là xác nhận tính đúng đắn (validation). Nói cách khác, đó là một cách để nghĩ về thiết kế của bạn trước khi viết mã nguồn cho chức năng. Một quan điểm khác lại cho rằng TDD là một kỹ thuật lập trình. Nhưng nhìn chung, mục tiêu của TDD là viết mã nguồn sáng sủa, rõ ràng và có thể chạy được.
Phát triển dựa trên kiểm thử (Test-Driven Development-TDD) là một phương pháp tiếp cận cải tiến để phát triển phần mềm trong đó kết hợp phương pháp Phát triển kiểm thử trước (Test First Development) và phương pháp Điều chỉnh lại mã nguồn (Refactoring). Mục tiêu quan trọng nhất của TDD là gì? Có quan điểm cho rằng mục tiêu của TDD là đặc tả (specification) chứ không phải là xác nhận tính đúng đắn (validation). Nói cách khác, đó là một cách để nghĩ về thiết kế của bạn trước khi viết mã nguồn cho chức năng. Một quan điểm khác lại cho rằng TDD là một kỹ thuật lập trình. Nhưng nhìn chung, mục tiêu của TDD là viết mã nguồn sáng sủa, rõ ràng và có thể chạy được.
TDD là gì?
TDD hoàn toàn thay đổi cách phát triển truyền thống. Khi bạn bắt đầu thực hiện một tính năng mới, câu hỏi đầu tiên đặt ra là liệu thiết kế hiện tại có phải là thiết kế tốt nhất cho phép bạn thực hiện các chức năng hay không. Nếu có, bạn tiến hành thông qua một phương pháp Phát triển kiểm thử trước TFD. Nếu không, bạn điều chỉnh lại nó một cách cục bộ để thay đổi riêng phần thiết kế bị ảnh hưởng bởi tính năng mới, cho phép bạn dễ dàng bổ thêm các tính năng có thể. Kết quả là chất lượng thiết kế của bạn sẽ luôn luôn được nâng cao, do đó sẽ thuận lợi hơn khi làm việc với nó trong tương lai.
Một giả định cơ bản của TDD là bạn có sẵn một nền tảng (framework) cho kiểm thử mức đơn vị (unit-test). Những lập trình viên phần mềm theo phương pháp Agile thường sử dụng các công cụ mã nguồn mở thuộc họ xUnit, như JUnit hay VBUnit, mặc dù các công cụ thương mại cũng là những lựa chọn khả dĩ. Nếu không có những công cụ như vậy thì TDD hầu như không thể thực hiện được. Hình 1 trình bày một sơ đồ trạng thái trên UML thể hiện cách mà mọi người thường làm việc với các công cụ xUnit.
Hình 1. Kiểm thử thông qua các framework xUnit
Hai nguyên tắc đơn giản cho TDD: Trước tiên, bạn nên viết mã xử lý nghiệp vụ mới chỉ khi mẫu kiểm thử tự động thực hiện không thành công. Thứ hai, bạn nên loại bỏ bất kỳ sự trùng lặp mà bạn tìm thấy. Những quy tắc đơn giản:
Bạn thiết kế với mã nguồn mà chúng chạy được và tạo ra kết quả phản hồi giữa các quyết định.
Bạn viết các mẫu kiểm thử cho riêng bạn bởi vì bạn không thể chờ đợi 20 lần mỗi ngày một người nào khác viết thay bạn.
Môi trường phát triển của bạn phải cung cấp được kết quả nhanh với những thay đổi nhỏ (ví dụ như bạn cần một trình biên dịch nhanh và chuỗi kiểm thử hồi quy (regression test)
Thiết kế của bạn phải bao gồm những thành phần gắn kết, sự phụ thuộc lẫn nhau nhỏ (loosely coupled) để thực hiện các mẫu kiểm thử dễ dàng hơn (điều này cũng làm cho quá trình nâng cấp và bảo trì các hệ thống của bạn dễ dàng hơn).
TDD và cách kiểm thử truyền thống
TDD là một kỹ thuật thiết kế với một hiệu ứng phụ là việc đảm bảo toàn bộ mã nguồn của bạn được thực hiện kiểm thử mức đơn vị. Tuy nhiên, có những điều còn quan trọng hơn cả việc thực hiện kiểm thử. Bạn sẽ vẫn cần xem xét các kỹ thuật kiểm thử khác như kiểm thử chấp nhận sản phẩm (acceptance test) hay kiểm thử dò hỏi (investigative test) theo kiểu Agile. Bạn có thể thực hiện nhiều những kiểu kiểm thử này trong dự án nếu như bạn chọn làm điều đó (và bạn nên làm).
Với kiểu kiểm thử truyền thống, một mẫu kiểm thử thành công sẽ tìm ra một hoặc nhiều lỗi. Tương tự với TDD, khi một mẫu kiểm thử thất bại thì bạn cũng có sự tiến triển bởi vì bây giờ bạn biết rằng bạn cần phải giải quyết một số vấn đề. Quan trọng hơn, bạn có một cách đo rõ ràng về sự thành công khi mẫu kiểm thử không thất bại nữa. TDD tăng niềm tin về hệ thống của bạn đáp ứng được các yêu cầu được định nghĩa cho nó, và hệ thống của bạn đang hoạt động và do đó bạn có thể tiếp tục với một sự tự tin.
Như với thử nghiệm truyền thống, hệ thống càng có nhiều rủi ro lớn càng cần phải có nhiều mẫu kiểm thử được thực hiện. Với cả hai kiểu kiểm thử truyền thống và TDD bạn không phấn đấu cho sự hoàn hảo, thay vào đó bạn kiểm thử tầm quan trọng của hệ thống. Một hiệu ứng phụ thú vị của TDD là bạn đạt được 100% khi kiểm thử độ phủ mã nguồn (coverage test) - mọi dòng mã đều được kiểm thử - điều mà kiểm thử truyền thống không bảo đảm dù cho nó khuyến khích điều đó. Không có gì ngạc nhiên khi nói rằng TDD là một kỹ thuật đặc tả (specification technique), với một tác dụng phụ có giá trị là nó đem lại kết quả trong việc kiểm thử mã nguồn tốt hơn đáng kể so với các kỹ thuật truyền thống.
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à người ta đã phát huy trong nhiều năm qua bởi vì nó mang lại hiệu quả nhiều hơn so với cố gắng viết mã trong những bước lớn. Ví dụ, giả sử bạn thêm một số mã nguồn cho chức năng mới, biên dịch, và kiểm thử nó. Khả năng rất lớn là các kiểm thử của bạn sẽ thất bại bởi những lỗi có trong mã nguồn mới. Sẽ dễ dàng hơn nhiều trong việc tìm kiếm, và sau đó sửa chữa những lỗi đó nếu bạn đã viết thêm hai dòng mã mới thay vì hai nghìn dòng.
Nhiều người cho rằng các kỹ thuật Agile hoạt động rất ổn với những dự án nhỏ, cần một số ít người trong một vài tháng, nhưng chúng không hoạt động đối với những dự án thực sự lớn hơn. Tuy nhiên, điều đó không hoàn toàn đúng. Người ta đã đưa ra một bản báo cáo rằng làm việc với một hệ thống Smalltalk sử dụng hoàn toàn phương pháp hướng kiểm thử (test-driven) hết 4 năm với chi phí nhân công 40 man-year, ra kết quả gồm 250,000 dòng mã nguồn chức năng và 250,000 dòng mã kiểm thử. Có 4000 mẫu kiểm thử chạy dưới 20 phút, còn với bộ mẫu kiểm thử đầy đủ thì cần chạy vài ngày. Điều đó chứng tỏ rằng TDD vẫn hoạt động tốt với những dự án có kích thước lớn.
Công cụ
Các công cụ phục vụ cho TDD, thường là các nền tảng cho kiểm thử mã nguồn mức đơn vị (unit test): cppUnit, csUnit (.Net), CUnit, DUnit (Delphi), DBFit, DBUnit, HTMLUnit, HTTPUnit, JMock, JUnit, NDbUnit, NUnit, OUnit, PHPUnit, PyUnit (Python), SimpleTest, TestNG, Test::Unit (Ruby), VBUnit, XTUnit.
Kết luận
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.
bangdv56
commented
11 years ago
Đây là tài liệu : Phát triển dựa trên kiểm thử-TDD
Phát triển dựa trên kiểm thử (Test-Driven Development-TDD) là một phương pháp tiếp cận cải tiến để phát triển phần mềm trong đó kết hợp phương pháp Phát triển kiểm thử trước (Test First Development) và phương pháp Điều chỉnh lại mã nguồn (Refactoring). Mục tiêu quan trọng nhất của TDD là gì? Có quan điểm cho rằng mục tiêu của TDD là đặc tả (specification) chứ không phải là xác nhận tính đúng đắn (validation). Nói cách khác, đó là một cách để nghĩ về thiết kế của bạn trước khi viết mã nguồn cho chức năng. Một quan điểm khác lại cho rằng TDD là một kỹ thuật lập trình. Nhưng nhìn chung, mục tiêu của TDD là viết mã nguồn sáng sủa, rõ ràng và có thể chạy được.
Phát triển dựa trên kiểm thử (Test-Driven Development-TDD) là một phương pháp tiếp cận cải tiến để phát triển phần mềm trong đó kết hợp phương pháp Phát triển kiểm thử trước (Test First Development) và phương pháp Điều chỉnh lại mã nguồn (Refactoring). Mục tiêu quan trọng nhất của TDD là gì? Có quan điểm cho rằng mục tiêu của TDD là đặc tả (specification) chứ không phải là xác nhận tính đúng đắn (validation). Nói cách khác, đó là một cách để nghĩ về thiết kế của bạn trước khi viết mã nguồn cho chức năng. Một quan điểm khác lại cho rằng TDD là một kỹ thuật lập trình. Nhưng nhìn chung, mục tiêu của TDD là viết mã nguồn sáng sủa, rõ ràng và có thể chạy được.
TDD là gì? TDD hoàn toàn thay đổi cách phát triển truyền thống. Khi bạn bắt đầu thực hiện một tính năng mới, câu hỏi đầu tiên đặt ra là liệu thiết kế hiện tại có phải là thiết kế tốt nhất cho phép bạn thực hiện các chức năng hay không. Nếu có, bạn tiến hành thông qua một phương pháp Phát triển kiểm thử trước TFD. Nếu không, bạn điều chỉnh lại nó một cách cục bộ để thay đổi riêng phần thiết kế bị ảnh hưởng bởi tính năng mới, cho phép bạn dễ dàng bổ thêm các tính năng có thể. Kết quả là chất lượng thiết kế của bạn sẽ luôn luôn được nâng cao, do đó sẽ thuận lợi hơn khi làm việc với nó trong tương lai.
Một giả định cơ bản của TDD là bạn có sẵn một nền tảng (framework) cho kiểm thử mức đơn vị (unit-test). Những lập trình viên phần mềm theo phương pháp Agile thường sử dụng các công cụ mã nguồn mở thuộc họ xUnit, như JUnit hay VBUnit, mặc dù các công cụ thương mại cũng là những lựa chọn khả dĩ. Nếu không có những công cụ như vậy thì TDD hầu như không thể thực hiện được. Hình 1 trình bày một sơ đồ trạng thái trên UML thể hiện cách mà mọi người thường làm việc với các công cụ xUnit.
Hình 1. Kiểm thử thông qua các framework xUnit
Hai nguyên tắc đơn giản cho TDD: Trước tiên, bạn nên viết mã xử lý nghiệp vụ mới chỉ khi mẫu kiểm thử tự động thực hiện không thành công. Thứ hai, bạn nên loại bỏ bất kỳ sự trùng lặp mà bạn tìm thấy. Những quy tắc đơn giản:
TDD và cách kiểm thử truyền thống TDD là một kỹ thuật thiết kế với một hiệu ứng phụ là việc đảm bảo toàn bộ mã nguồn của bạn được thực hiện kiểm thử mức đơn vị. Tuy nhiên, có những điều còn quan trọng hơn cả việc thực hiện kiểm thử. Bạn sẽ vẫn cần xem xét các kỹ thuật kiểm thử khác như kiểm thử chấp nhận sản phẩm (acceptance test) hay kiểm thử dò hỏi (investigative test) theo kiểu Agile. Bạn có thể thực hiện nhiều những kiểu kiểm thử này trong dự án nếu như bạn chọn làm điều đó (và bạn nên làm).
Với kiểu kiểm thử truyền thống, một mẫu kiểm thử thành công sẽ tìm ra một hoặc nhiều lỗi. Tương tự với TDD, khi một mẫu kiểm thử thất bại thì bạn cũng có sự tiến triển bởi vì bây giờ bạn biết rằng bạn cần phải giải quyết một số vấn đề. Quan trọng hơn, bạn có một cách đo rõ ràng về sự thành công khi mẫu kiểm thử không thất bại nữa. TDD tăng niềm tin về hệ thống của bạn đáp ứng được các yêu cầu được định nghĩa cho nó, và hệ thống của bạn đang hoạt động và do đó bạn có thể tiếp tục với một sự tự tin.
Như với thử nghiệm truyền thống, hệ thống càng có nhiều rủi ro lớn càng cần phải có nhiều mẫu kiểm thử được thực hiện. Với cả hai kiểu kiểm thử truyền thống và TDD bạn không phấn đấu cho sự hoàn hảo, thay vào đó bạn kiểm thử tầm quan trọng của hệ thống. Một hiệu ứng phụ thú vị của TDD là bạn đạt được 100% khi kiểm thử độ phủ mã nguồn (coverage test) - mọi dòng mã đều được kiểm thử - điều mà kiểm thử truyền thống không bảo đảm dù cho nó khuyến khích điều đó. Không có gì ngạc nhiên khi nói rằng TDD là một kỹ thuật đặc tả (specification technique), với một tác dụng phụ có giá trị là nó đem lại kết quả trong việc kiểm thử mã nguồn tốt hơn đáng kể so với các kỹ thuật truyền thống.
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à người ta đã phát huy trong nhiều năm qua bởi vì nó mang lại hiệu quả nhiều hơn so với cố gắng viết mã trong những bước lớn. Ví dụ, giả sử bạn thêm một số mã nguồn cho chức năng mới, biên dịch, và kiểm thử nó. Khả năng rất lớn là các kiểm thử của bạn sẽ thất bại bởi những lỗi có trong mã nguồn mới. Sẽ dễ dàng hơn nhiều trong việc tìm kiếm, và sau đó sửa chữa những lỗi đó nếu bạn đã viết thêm hai dòng mã mới thay vì hai nghìn dòng.
Nhiều người cho rằng các kỹ thuật Agile hoạt động rất ổn với những dự án nhỏ, cần một số ít người trong một vài tháng, nhưng chúng không hoạt động đối với những dự án thực sự lớn hơn. Tuy nhiên, điều đó không hoàn toàn đúng. Người ta đã đưa ra một bản báo cáo rằng làm việc với một hệ thống Smalltalk sử dụng hoàn toàn phương pháp hướng kiểm thử (test-driven) hết 4 năm với chi phí nhân công 40 man-year, ra kết quả gồm 250,000 dòng mã nguồn chức năng và 250,000 dòng mã kiểm thử. Có 4000 mẫu kiểm thử chạy dưới 20 phút, còn với bộ mẫu kiểm thử đầy đủ thì cần chạy vài ngày. Điều đó chứng tỏ rằng TDD vẫn hoạt động tốt với những dự án có kích thước lớn.
Công cụ Các công cụ phục vụ cho TDD, thường là các nền tảng cho kiểm thử mã nguồn mức đơn vị (unit test): cppUnit, csUnit (.Net), CUnit, DUnit (Delphi), DBFit, DBUnit, HTMLUnit, HTTPUnit, JMock, JUnit, NDbUnit, NUnit, OUnit, PHPUnit, PyUnit (Python), SimpleTest, TestNG, Test::Unit (Ruby), VBUnit, XTUnit.
Kết luận 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.
(Theo tài liệu tại nguồn: http://www.agiledata.org)