Hướng phát triển thử nghiệm
Test Driven Development (TDD) là cách tiếp cận phát triển phần mềm trong đó các trường hợp kiểm thử được phát triển để chỉ định và xác thực những gì mã sẽ làm. Nói một cách dễ hiểu, các trường hợp thử nghiệm cho mỗi chức năng được tạo và thử nghiệm trước và nếu thử nghiệm không thành công thì mã mới sẽ được viết để vượt qua thử nghiệm và làm cho mã trở nên đơn giản và không có lỗi.
Phát triển theo hướng kiểm tra bắt đầu với việc thiết kế và phát triển các bài kiểm tra cho mọi chức năng nhỏ của ứng dụng. TDD hướng dẫn các nhà phát triển viết mã mới chỉ khi kiểm tra tự động không thành công. Điều này tránh trùng lặp mã. Dạng đầy đủ của TDD là Phát triển theo hướng kiểm tra.
Khái niệm đơn giản của TDD là viết và sửa các bài kiểm tra không thành công 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ã tại một thời điểm để vượt qua các bài kiểm tra. (Kiểm tra không là gì ngoài các điều kiện bắt buộc mà chúng ta cần kiểm tra để đáp ứng chúng).
Phát triển theo hướng kiểm tra là một quá trình phát triển và chạy kiểm thử tự động trước khi phát triển ứng dụng thực tế. Do đó, TDD đôi khi còn được gọi là Test First Development.
Trong hướng dẫn này, bạn sẽ tìm hiểu thêm về-
- Cách thực hiện Kiểm tra TDD
- TDD Vs. Thử nghiệm truyền thống
- TDD chấp nhận và TDD nhà phát triển là gì
- Mở rộng TDD thông qua Phát triển theo hướng mô hình Agile (AMDD)
- Phát triển theo hướng kiểm tra (TDD) Vs. Phát triển theo hướng mô hình Agile (AMDD)
- Ví dụ về TDD
- Lợi ích của TDD
Cách thực hiện Kiểm tra TDD
Các bước sau xác định cách thực hiện kiểm tra TDD,
- Thêm một bài kiểm tra.
- Chạy tất cả các thử nghiệm và xem có thử nghiệm mới nào không.
- Viết một số mã.
- Chạy thử nghiệm và mã Refactor.
- Nói lại.
Chu kỳ TDD xác định
- Viết một bài kiểm tra
- Làm cho nó chạy.
- Thay đổi mã để làm cho nó đúng tức là Refactor.
- Lặp lại quá trình.
Một số thông tin làm rõ về TDD:
- TDD không phải về "Thử nghiệm" cũng không phải 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. 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, một thử nghiệm thành công sẽ tìm thấy một hoặc nhiều khiếm khuyết. Nó cũng giống như TDD. Khi một bài kiểm tra không thành công, bạn đã đạt được tiến bộ bởi 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 bạn xây dựng niềm tin về hệ thống của mình.
- 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 bình thường 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 bài kiểm tra sẽ cho thấy việc thực thi ứng dụng đúng / sai để đáp ứng các yêu cầu.
- Trong TDD, bạn đạt được kiểm tra độ phủ 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ả kiểm thử truyền thống và TDD dẫn đến tầm quan trọng của việc kiểm thử hệ thống hơn là sự hoàn thiện của hệ thống.
- Trong Mô hình Agile (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 thiết của nó.
TDD chấp nhận và TDD nhà phát triển là gì
Có hai mức TDD
- Chấp nhận TDD (ATDD): Với ATDD, bạn viết một thử nghiệm chấp nhận duy nhất. Kiểm tra này đáp ứng yêu cầu của đặc điểm kỹ thuật hoặc đáp ứng hành vi của hệ thống. Sau đó, hãy viết mã sản xuất / chức năng vừa đủ để thực hiện 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 Định hướng Hành vi (BDD).
- Nhà phát triển TDD: Với Nhà phát triển TDD, bạn viết thử nghiệm nhà phát triển đơn tức là thử nghiệm đơn vị và sau đó chỉ cần mã sản xuất đủ để thực hiện thử nghiệm đó. Bài kiểm tra đơ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 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 TDD thông qua Phát triển theo hướng mô hình Agile (AMDD)
TDD rất giỏi về đặc điểm kỹ thuật và xác nhận chi tiết. Nó không thành công trong việc suy nghĩ thông qua các vấn đề lớn hơn như thiết kế tổng thể, 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 theo hướng mô hình (MDD), các mô hình mở rộng được tạo trước khi mã nguồn được viết. Đến lượt mình, cái nào có cách tiếp cận nhanh nhẹn?
Trong hình trên, mỗi hộp đạ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 dự đoán / tưởng tượng các bài kiểm tra 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. 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 phải thực hiện một đặc tả chi tiết của phần mềm / hệ thống mà là 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.
- Hình dung 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).
- Hình dung kiến trúc ban đầu.
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à Trường hợp thay đổi.
- Mô hình lặp lại:
Ở đâ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 lại.
- 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 ưu tiên cao hơn đầu tiên sẽ được xem xét. Các hạng mục công việc đã thêm có thể được sắp xếp lại hoặc xóa khỏi ngăn xếp hạng 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ẽ thực hiện cho lần lặp đó.
- Mô hình làm mưa làm gió:
Điều này còn được gọi là Lập mô hình đúng lúc.
- Ở đây, phiên mô hình bao gồm 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 người khác làm mẫu với họ. Phiên lập mô hình 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 với nhau để chia sẻ bảng / giấy trắng.
- Họ khám phá các vấn đề cho đến khi họ 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à anh ấy / cô ấy muốn giải quyết thì anh ấy / cô ấy sẽ nhanh chóng giúp đỡ 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 lập mô hình độc lập hoặc phiên QA của khách hàng.
- Phát triển theo hướng kiểm tra (TDD).
- Nó thúc đẩy kiểm tra xác nhận mã ứng dụng của bạn và thông số kỹ thuật chi tiết.
- Cả kiểm thử chấp nhận (yêu cầu chi tiết) và kiểm thử nhà phát triển (kiểm thử đơn vị) đều là đầu vào cho TDD.
- TDD làm cho mã đơn giản và rõ ràng. Nó cho phép nhà phát triển duy trì ít tài liệu hơn.
- Nhận xét.
- Đâ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 lại 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 theo hướng kiểm tra (TDD) Vs. Phát triển theo hướng mô hình Agile (AMDD)
| TDD | AMDD |
|
|
|
|
|
|
|
|
|
|
|
|
| -------------------------------------------- |
Ví dụ về TDD
Ở đây trong ví dụ này, chúng tôi sẽ xác định một mật khẩu lớp. Đối với lớp này, chúng tôi 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, chúng tôi viết mã đáp ứng tất cả các yêu cầu trên.
Tình huống 1 : Để chạy thử nghiệm, chúng tôi tạo lớp PasswordValidator ();
Chúng tôi sẽ chạy trên lớp TestPassword ();
Đầu ra được PASSED như hình dưới đây;
Đầu ra :
Tình huống 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ớp PasswordValidator. Instance có nghĩa là tạo một đối tượng của lớp để tham chiếu đến các thành viên (biến / phương thức) của lớp đó.
Chúng tôi sẽ xóa lớp PasswordValidator pv = new PasswordValidator () khỏi mã. Chúng ta có thể gọi phương thức isValid () trực tiếp bằng PasswordValidator. IsValid ("Abc123") . (Xem hình ảnh bên dưới)
Vì vậy chúng tôi Refactor (thay đổi mã) như sau:
Tình huống 3 : Sau khi cấu trúc lại, đầ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 non-static isValid ().
Vì vậy chúng ta cần thay đổi phương thức này bằng cách thêm từ "static" vào trước Boolean dưới dạng public static boolean isValid (String password). Cấu trúc lại lớp PasswordValidator () để loại bỏ lỗi trên để vượt qua bài kiểm tra.
Đầu ra:
Sau khi thực hiện các thay đổi đối với lớp PassValidator () nếu chúng ta chạy thử nghiệm thì đầu ra sẽ được PASSED như hình dưới đây.
Ưu điểm của TDD
- 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, điều này thường bao gồm kiểm tra thủ công hoặc tập lệnh một lần. Sử dụng TDD, theo thời gian, bạn xây dựng một bộ kiểm tra 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, mã sạch hơn và có thể 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ã đơn giản hơn để hiểu.
- 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 để Refactor
- 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 tập hợp các bài kiểm tra tự động, bạn có thể khắc phục những lỗi đó trước khi phát hành. Cảnh báo thích hợp sẽ được đưa ra nếu tìm thấy các lỗi khi sử dụng các bài kiểm tra tự động.
- Sử dụng TDD, sẽ dẫn đến mã nhanh hơn, có thể mở rộng hơn với ít lỗi hơn và có thể được cập nhật với rủi ro tối thiểu.
- Tốt cho tinh thần đồng đội
Trong trường hợp không có bất kỳ 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 nhận và làm việc trên mã. Nó cũng hỗ trợ chia sẻ kiến thức, do đó làm cho nhóm hiệu quả hơn về tổng thể.
- Tốt cho các 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 thử nghiệm TDD, nhưng lại mất ít thời gian hơn để gỡ lỗi và phát triển 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.
Tóm lược:
- TDD là viết tắt của Test-driven development. Đây là một quá trình sửa đổi mã để vượt qua một bài kiểm tra được thiết kế trước đó.
- Nó tập trung nhiều hơn vào mã sản xuất hơn là thiết kế trường hợp thử nghiệm.
- Phát triển theo hướng kiểm tra là một quá trình sửa đổi mã để vượt qua bài kiểm tra được thiết kế trước đó.
- Trong Kỹ thuật phần mềm, nó đôi khi được gọi là "Thử nghiệm phát triển đầu tiên."
- TDD bao gồm việc tái cấu trúc mã tức là thay đổi / thêm một số lượng mã vào mã hiện có mà không ảnh hưởng đến hoạt động của mã.
- TDD khi được sử dụng, mã trở nên rõ ràng và đơn giản để hiểu.
Bài viết này được đóng góp bởi Kanchan Kulkarni