Phát triển dựa trên thử nghiệm (TDD) là gì? Ví dụ

Phát triển dựa trên thử nghiệm (TDD) là gì?

Phát triển dựa trên thử nghiệm (TDD) là phương pháp phát triển phần mềm trong đó các trường hợp thử nghiệm được phát triển để xác định và xác thực những gì mã sẽ thực hiện. Nói một cách đơn giản, các trường hợp kiểm thử cho từng chức năng được tạo và kiểm thử trước tiên và nếu kiểm thử thất bại thì mã mới sẽ được viết để vượt qua kiểm thử và làm cho mã trở nên đơn giản và không có lỗi.

Phát triển dựa trên kiểm thử (Test-Driven Development) bắt đầu từ việc thiết kế và phát triển...ping Kiểm thử được thực hiện cho mọi chức năng nhỏ nhất của ứng dụng. Khung TDD hướng dẫn các nhà phát triển chỉ viết mã mới nếu một bài kiểm thử tự động thất bại. Điều này tránh được việc trùng lặp mã. TDD là viết tắt của Test-driven development (Phát triển dựa trên kiểm thử).

Khái niệm đơn giản của TDD là viết và sửa các bài kiểm tra thất bạ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 tôi viết một lượng nhỏ mã mỗi lần để vượt qua các bài kiểm tra. (Các bài kiểm tra không gì khác ngoài những đ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 dựa trên kiểm thử (Test-Driven development) là một quy trình phát triển...ping và chạy thử nghiệm tự động trước khi phát triển ứng dụng thực tế. Do đó, TDD đôi khi cũng được gọi là Kiểm tra sự phát triển đầu tiên.

Cách thực hiện kiểm tra TDD

Các bước sau đây xác định cách thực hiện thử nghiệm TDD,

1. Thêm một bài kiểm tra.
2. Chạy tất cả các thử nghiệm và xem có thử nghiệm mới nào thất bại không.
3. Viết một số mã.
4. Chạy thử nghiệm và mã Refactor.
5. Nói lại.

Chu trình TDD xác định

1. Viết bài kiểm tra
2. Làm cho nó chạy.
3. Thay đổi mã cho đúng tức là Refactor.
4. Quá trình lặp lại.

Một số giải thích rõ ràng về TDD:

• Cách tiếp cận TDD không phải là về “Thử nghiệm” cũng như về “Thiết kế”.
• TDD không có nghĩa là “viết một số bài kiểm tra, sau đó xây dựng một hệ thống vượt qua các bài kiểm tra.
• TDD không có nghĩa là “thực hiện nhiều thử nghiệm”.

TDD Vs. Kiểm tra truyền thống

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

TDD chấp nhận và TDD dành cho nhà phát triển là gì

Có hai cấp độ TDD

1. Chấp nhận TDD (ATDD): Với ATDD bạn viết một bài kiểm tra chấp nhận duy nhất. Thử nghiệm này đáp ứng yêu cầu của đặc tả hoặc đáp ứng hoạt động của hệ thống. Sau đó chỉ viết đủ mã sản xuất/chức năng để hoàn thành quá trình kiểm tra chấp nhận đó. Kiểm tra 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 hướng hành vi (BDD).
2. Nhà phát triển TDD: Với Nhà phát triển TDD, bạn viết bài kiểm tra dành cho nhà phát triển duy nhất, tức là bài kiểm tra đơn vị và sau đó chỉ cần đủ mã sản xuất để hoàn thành bài kiểm tra đó. Kiểm thử đơn vị tập trung vào mọi chức năng nhỏ của hệ thống. Nhà phát triển TDD được gọi đơn giản là TDD.Mục tiêu chính của ATDD 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ả.

Mở rộng quy mô TDD thông qua Phát triển dựa trên mô hình Agile (AMDD)

TDD rất giỏi về đặc tả và xác nhận chi tiết. Nó thất bại trong việc suy nghĩ thấu đáo các vấn đề lớn hơn như thiết kế tổng thể, việc sử dụng hệ thống hoặc giao diện người dùng. AMDD giải quyết các vấn đề mở rộng quy mô Agile mà TDD không giải quyết được.

Do đó AMDD được sử dụng cho các vấn đề lớn hơn.

Vòng đời của AMDD

Trong Phát triển dựa trên mô hình (MDD), các mô hình mở rộng được tạo trước khi viết mã nguồn. Mà lần lượt có một cách tiếp cận nhanh nhẹn?

Trong hình trên, mỗi ô đại diện cho một hoạt động phát triển.

Hình dung là một trong những quá trình TDD của các bài kiểm tra dự đoán/hình dung sẽ được thực hiện trong tuần đầu tiên của dự án. Mục tiêu chính của hình dung là xác định phạm vi của hệ thống và kiến ​​trúc của hệ thống. Các yêu cầu cấp cao và mô hình kiến ​​trúc được thực hiện để hình dung thành công.

Đây là quá trình không thực hiện đặc tả chi tiết về phần mềm/hệ thống mà khám phá các yêu cầu của phần mềm/hệ thống để xác định chiến lược tổng thể của dự án.

Lặp lại 0: Hình dung

Có hai kích hoạt phụ chính.

1. Hình dung các yêu cầu ban đầu.Có thể mất vài ngày để xác định các yêu cầu cấp cao và phạm vi của hệ thống. Trọng tâm chính là khám phá mô hình sử dụng, mô hình miền ban đầu và mô hình giao diện người dùng (UI).
2. Ban đầu Archihình dung kiến ​​trúc. Cũng mất vài ngày để xác định kiến ​​trúc của hệ thống. Nó cho phép thiết lập các hướng kỹ thuật cho dự án. Trọng tâm chính là khám phá sơ đồ công nghệ, luồng Giao diện người dùng (UI), mô hình miền và các trường hợp Thay đổi.

Mô hình lặp

Ở đây nhóm phải lập kế hoạch công việc sẽ được thực hiện cho mỗi lần lặp.

• Quy trình Agile được sử dụng cho mỗi lần lặp, tức là trong mỗi lần lặp, hạng mục công việc mới sẽ được ưu tiên thêm vào.
• Công việc có mức độ ưu tiên cao hơn sẽ được xem xét. Các mục công việc được thêm vào có thể được sắp xếp lại thứ tự ưu tiên hoặc bị xóa khỏi ngăn xếp mục bất kỳ lúc nào.
• Nhóm thảo luận về cách họ sẽ thực hiện từng yêu cầu. Mô hình hóa được sử dụng cho mục đích này.
• Phân tích và thiết kế mô hình được thực hiện cho từng yêu cầu sẽ được triển khai cho lần lặp đó.

Người mẫu gây bão

Điều này còn được gọi là Mô hình hóa đúng lúc.

• Ở đây, buổi làm mẫu có sự tham gia của một nhóm gồm 2/3 thành viên thảo luận các vấn đề trên giấy hoặc bảng trắng.
• Một thành viên trong nhóm sẽ yêu cầu một thành viên khác làm mẫu cùng họ. Phiên làm mẫu này sẽ mất khoảng 5 đến 10 phút. Nơi các thành viên trong nhóm tập hợp lại để chia sẻ bảng trắng/giấy.
• Họ khám phá các vấn đề cho đến khi không tìm ra nguyên nhân chính của vấn đề. Đúng lúc, nếu một thành viên trong nhóm xác định được vấn đề mà mình muốn giải quyết thì người đó sẽ nhanh chóng nhận được sự giúp đỡ của các thành viên khác trong nhóm.
• Các thành viên khác trong nhóm sau đó khám phá vấn đề và sau đó mọi người tiếp tục như trước. Nó còn được gọi là phiên mô hình hóa độc lập hoặc phiên QA của khách hàng.

Phát triển dựa trên thử nghiệm (TDD)

• Nó thúc đẩy việc kiểm tra xác nhận mã ứng dụng và thông số kỹ thuật chi tiết của bạn.
• Cả thử nghiệm chấp nhận (yêu cầu chi tiết) và thử nghiệm dành cho nhà phát triển (kiểm tra đơn vị) đều là đầu vào cho TDD.
• TDD làm cho mã đơn giản và rõ ràng hơn. Nó cho phép nhà phát triển duy trì ít tài liệu hơn.

Đánh giá

• Đây là tùy chọn. Nó bao gồm kiểm tra mã và đánh giá mô hình.
• Điều này có thể được thực hiện cho mỗi lần lặp hoặc cho toàn bộ dự án.
• Đây là một lựa chọn tốt để đưa ra phản hồi cho dự án.

Phát triển dựa trên thử nghiệm (TDD) Vs. Phát triển theo hướng mô hình linh hoạt (AMDD)

TDD	AMDD
TDD rút ngắn vòng phản hồi lập trình	AMDD rút ngắn vòng phản hồi mô hình hóa.
TDD là thông số kỹ thuật chi tiết	AMDD giải quyết các vấn đề lớn hơn
TDD thúc đẩy sự phát triển của mã chất lượng cao	AMDD thúc đẩy giao tiếp chất lượng cao với các bên liên quan và nhà phát triển.
TDD nói chuyện với các lập trình viên	AMDD nói chuyện với Chuyên viên phân tích kinh doanh, các bên liên quan và các chuyên gia dữ liệu.
TDD không định hướng trực quan	AMDD định hướng trực quan
TDD có phạm vi giới hạn đối với các công việc phần mềm	AMDD có phạm vi rộng bao gồm cả các bên liên quan. Nó liên quan đến việc hướng tới sự hiểu biết chung
Cả hai đều hỗ trợ sự phát triển tiến hóa	---------------

Khung TDD

Dưới đây là danh sách các khung phát triển dựa trên thử nghiệm (TDD) tốt nhất

1. Junit
2. TestNG
3. csUnit và NUnit
4. Rspec

Bây giờ, hãy tìm hiểu ví dụ về Phát triển dựa trên thử nghiệm.

Ví dụ về TDD

Ở đây trong ví dụ Phát triển theo hướng kiểm thử này, chúng ta sẽ định nghĩa một lớp mật khẩu. Đối với lớp này, chúng ta sẽ cố gắng đáp ứng các điều kiện sau.

Điều kiện để chấp nhận Mật khẩu:

• Mật khẩu phải có từ 5 đến 10 ký tự.

Đầu tiên trong ví dụ TDD này, chúng tôi viết mã đáp ứng tất cả các yêu cầu trên.

Kịch bản 1: Để chạy thử nghiệm, chúng ta tạo lớpPasswordValidator();

Chúng ta sẽ chạy trên lớp TestPassword();

Đầu ra được PASSED như hình bên dưới;

Đầu ra:

Kịch bản 2: Ở đây chúng ta có thể thấy trong phương thức TestPasswordLength() không cần tạo một thể hiện của lớpPasswordValidator. Ví dụ có nghĩa là tạo một vật của lớp để chỉ các thành viên (biến/phương thức) của lớp đó.

Chúng tôi sẽ xóa lớpPasswordValidator pv = newPasswordValidator() khỏi mã. Chúng ta có thể gọi làValid() phương pháp trực tiếp bằng Trình xác thực mật khẩu. IsValid (“Abc123”). (Xem hình ảnh bên dưới)

Vì vậy chúng ta Refactor (đổi code) như sau:

Kịch bản 3: Sau khi tái cấu trúc, đầu ra hiển thị trạng thái không thành công (xem hình ảnh bên dưới) điều này là do chúng tôi đã xóa phiên bản. Vì vậy, không có tham chiếu đến phương thức không tĩnh làValid().

Vì vậy chúng ta cần thay đổi phương thức này bằng cách thêm từ “tĩnh” trước Boolean dưới dạng public static boolean isValid (Mật khẩu chuỗi). Tái cấu trúc lớp PassValidator () để loại bỏ lỗi trên để vượt qua bài kiểm tra.

Đầu ra:

Sau khi thực hiện thay đổi class PassValidator() nếu chúng ta chạy test thì kết quả sẽ là PASSED như hình bên dưới.

Ưu điểm của TDD

Sau đây là những lợi thế chính của Phát triển theo hướng kiểm thử trong Kỹ thuật phần mềm:

Thông báo lỗi sớm.

• Các nhà phát triển kiểm tra mã của họ nhưng trong thế giới cơ sở dữ liệu, việc này thường bao gồm các kiểm tra thủ công hoặc các tập lệnh chỉ thực hiện một lần. Bằng cách sử dụng TDD, theo thời gian, bạn sẽ xây dựng một bộ thử nghiệm tự động mà bạn và bất kỳ nhà phát triển nào khác có thể chạy lại theo ý muốn.

Được thiết kế tốt hơn, sạch hơn và mã mở rộng hơn.

• Nó giúp hiểu cách mã sẽ được sử dụng và cách nó tương tác với các mô-đun khác.
• Nó dẫn đến quyết định thiết kế tốt hơn và mã dễ bảo trì hơn.
• TDD cho phép viết mã nhỏ hơn có trách nhiệm duy nhất thay vì các thủ tục nguyên khối với nhiều trách nhiệm. Điều này làm cho mã dễ hiểu hơn.
• TDD cũng buộc chỉ viết mã sản xuất để vượt qua các bài kiểm tra dựa trên yêu cầu của người dùng.

Sự tự tin để tái cấu trúc

• Nếu bạn cấu trúc lại mã, có thể có khả năng xảy ra lỗi trong mã. Vì vậy, có một bộ thử nghiệm tự động, bạn có thể khắc phục những điểm dừng đó trước khi phát hành. Cảnh báo thích hợp sẽ được đưa ra nếu phát hiện thấy vi phạm khi sử dụng các bài kiểm tra tự động.
• Sử dụng TDD sẽ mang lại mã nhanh hơn, có khả năng mở rộng hơn với ít lỗi hơn và có thể cập nhật với rủi ro tối thiểu.

Tốt cho làm việc nhóm

• Trong trường hợp không có thành viên nào trong nhóm, các thành viên khác trong nhóm có thể dễ dàng tiếp thu và xử lý mã. Nó cũng hỗ trợ việc chia sẻ kiến ​​thức, từ đó làm cho nhóm hoạt động hiệu quả hơn về tổng thể.

Tốt cho nhà phát triển

• Mặc dù các nhà phát triển phải dành nhiều thời gian hơn để viết các trường hợp kiểm thử TDD, nhưng họ lại tốn ít thời gian hơn cho việc gỡ lỗi và phát triển.ping Các tính năng mới. Bạn sẽ viết mã sạch hơn, ít phức tạp hơn.

Câu Hỏi Thường Gặp