Lợi nhuận:
- Khả năng tạo thử nghiệm đơn vị, trường hợp tiên tiến và phân tích khoảng cách phạm vi phủ sóng bằng AI
- Khả năng in các kỳ vọng kiểm tra dựa trên đặc điểm kỹ thuật, không phải hành vi hiện tại của mã
- Khả năng kiểm tra xem thử nghiệm có thực sự bảo vệ bằng cách chèn lỗi hay không
Viết bài kiểm thử là một trong những nhiệm vụ tạo ra giá trị cao nhất mà hầu hết các nhà phát triển đều trì hoãn. Một bộ thử nghiệm tốt là bằng chứng cho thấy mã hoạt động như mong đợi và là cứu cánh cho những thay đổi trong tương lai. Vấn đề là việc viết bài kiểm tra lặp đi lặp lại và tốn thời gian - chính xác là loại công việc mà AI tỏa sáng. Nhưng có một nhược điểm: AI thường kiểm tra hành vi hiện có của mã chứ không phải hành vi cần có. Quản lý sự khác biệt này là bản chất của đơn vị này.
Trong học phần này, bạn sẽ học kiểm thử đơn vị (kiểm thử chỉ kiểm thử một chức năng, riêng biệt), kiểm thử các trường hợp đặc biệt và tạo dữ liệu kiểm thử bằng AI; thu hẹp khoảng cách trong phạm vi kiểm tra; và tại sao việc tin tưởng một cách mù quáng vào các bài kiểm tra AI lại nguy hiểm.
Hai mặt của việc kiểm tra: Khắc phục hành vi so với xác minh
Một bài kiểm tra có thể phục vụ hai mục đích khác nhau. Đầu tiên là xác minh: nó kiểm tra xem mã có đúng không, có tuân thủ đặc điểm kỹ thuật hay không. Thứ hai là bảo vệ hồi quy: nó đóng băng hành vi của mã ngày hôm nay, vì vậy nếu ai đó vô tình thay đổi nó vào ngày mai, quá trình kiểm tra sẽ bị hỏng và thông báo.
AI rất giỏi ở phần sau; Nó xem xét mã và tạo ra các trường hợp kiểm tra "hiện tại nó đang làm gì". Nhưng nếu mã sai ngay từ đầu, AI có thể ghim hành vi sai đó là “đúng”. Vì vậy, bạn phải xem lại khẳng định của từng bài kiểm tra mà AI đưa ra: "Mã trả về 42 và bài kiểm tra mong đợi 42" không có nghĩa là 42 là câu trả lời đúng.
Thận trọng: Nếu AI vượt qua bài kiểm tra, điều đó không có nghĩa là mã đang "hoạt động"; nó chỉ có nghĩa là "nó hoạt động như AI mong đợi". Bạn quyết định xem kỳ vọng có đúng hay không bằng cách xem xét thông số kỹ thuật.
Từng bước: Viết bài kiểm tra hiệu quả với AI
- Đưa ra thông số kỹ thuật, không chỉ mã. Nếu bạn thêm thông tin “Chức năng này nên làm điều này”, AI có thể viết đúng kỳ vọng; Nó sẽ kiểm tra hành vi hiện tại nếu bạn chỉ cung cấp mã.
- Yêu cầu các trường hợp cạnh. Trống, null, 0, âm, quá lớn, định dạng sai, đồng thời - yêu cầu rõ ràng về con đường hạnh phúc.
- Chỉ định khung và phong cách thử nghiệm. "sử dụng pytest", "Mẫu sắp xếp-Act-Assert", "hãy để mỗi bài kiểm tra kiểm tra một điều", v.v.
- Kiểm tra kỳ vọng (khẳng định). So sánh với đặc tả mà mỗi xác nhận sẽ kiểm tra giá trị chính xác.
- Thu hẹp khoảng cách về phạm vi. Đưa ra các bài kiểm tra hiện có và hỏi "những nhánh và trường hợp nào chưa được kiểm tra?" khiến bạn phải hỏi; sau đó xác minh các thử nghiệm bổ sung được thực hiện.
Ba hộp nhỏ
Trường hợp 1 - Độ bao phủ từ 52% đến 85%. Phạm vi kiểm tra của một mô-đun dịch vụ là 52%. Nhóm đã cung cấp các bài kiểm tra hiện có cho AI, yêu cầu AI liệt kê các nhánh chưa được kiểm tra và tạo các bài kiểm tra cho chúng. Với sự đánh giá của con người, phạm vi bao phủ tăng lên 85%; Trong quá trình này, AI đã phát hiện ra một lỗi thực tế (đường dẫn trả về mã lỗi sai) trong một nhánh lỗi chưa từng được kiểm tra trước đây.
Trường hợp 2 - Bẫy cố định kỳ vọng sai lầm. Chức năng làm tròn số tiền thực sự sai; Thay vì làm tròn 2,675 thành 2,67, nó làm tròn 2,67 thay vì 2,68. AI đã xem mã và viết khẳng định round_money(2.675) == 2.67 - đóng băng lỗi là “true”. Khi nhà phát triển đọc đặc tả, anh ta đã sửa lại kỳ vọng và tìm ra lỗi thực sự. Kiểm tra quy tắc chứ không phải mã đã tạo ra sự khác biệt.
Trường hợp 3 - Bùng nổ trạng thái biên. Khi yêu cầu AI chỉ cung cấp “các trường hợp đặc biệt” cho chức năng phạm vi ngày; Nó tạo ra 8 trường hợp như bắt đầu=kết thúc, khoảng thời gian đảo ngược, năm nhuận ngày 29 tháng 2, các múi giờ khác nhau và khoảng thời gian không. Hai trong số này (khoảng cách đảo ngược và năm nhuận) thực sự đã gây ra lỗi. Việc xem xét các trường hợp này theo cách thủ công thường bị bỏ qua; AI đã trở thành đối tác “động não trong các trường hợp phức tạp” ở đây.
Bốn mẫu có thể sao chép
Tạo thử nghiệm dựa trên đặc điểm kỹ thuật:
Vai trò: Một nhà phát triển viết bài kiểm tra. Framework: {{pytest/JUnit/Jest...}}.Hàm NÊN LÀM GÌ (đặc tả): {{rule}}Viết bài kiểm tra cho hàm sau. Viết kỳ vọng theo đặc điểm kỹ thuật, KHÔNG phải đầu ra hiện tại của mã. Đường đi hạnh phúc + thêm ít nhất 4 trường hợp cạnh. Hãy để mỗi bài kiểm tra một điều, sử dụng tên mô tả. {{chức năng}}
Động não trường hợp cạnh:
Liệt kê các trường hợp cạnh/lỗi cần được thử khi kiểm tra chức năng này (null, null, điểm dừng, định dạng sai, đồng thời, lỗi bên ngoài). Đối với mỗi trường hợp: đầu vào, hành vi dự kiến. KHÔNG viết mã, chỉ liệt kê.{{function}}
Phân tích khoảng cách bảo hiểm:
Dưới đây là các chức năng và các bài kiểm tra có sẵn. Những ngành, điều kiện, trường hợp nào chưa được kiểm nghiệm? Liệt kê những thiếu sót và viết bài kiểm tra mới chỉ cho những thiếu sót. Đừng lặp lại những cái hiện có. Chức năng:{{function}}Kiểm tra:{{being_tests}}
Dữ liệu thử nghiệm/tạo đối tượng giả:
Tạo dữ liệu thử nghiệm thực tế cho các thử nghiệm {{function/service}}: mẫu hợp lệ, mẫu biên giới và mẫu không hợp lệ riêng biệt. Đề xuất hành vi mô phỏng đơn giản cho phần phụ thuộc bên ngoài {{X}}. Sử dụng dữ liệu bí mật/PII thực sự; Tạo dữ liệu giả.
Dấu nhắc yếu / Dấu nhắc mạnh
Yếu: "Viết bài kiểm tra cho chức năng này."
Mạnh: "với pytest. Hàm apply_discount(tổng, phần trăm) — quy tắc: chiết khấu phải là 0%–30%, vượt quá giới hạn sẽ đưa ra ValueError, kết quả phải được làm tròn thành 2 số thập phân. Viết kỳ vọng theo QUY TẮC này (không phải theo mã). Đường dẫn hạnh phúc + các trường hợp đặc biệt này: 0%, 30%, 31% (lỗi), âm, tổng = 0. [mã]"
Anh ta đưa ra quy tắc phát hành mạnh mẽ và nói "viết kỳ vọng theo quy tắc, không phải mã"; Câu duy nhất này đã khép lại cái bẫy AI sửa chữa hành vi sai trái.
Loại thử nghiệm
Đóng góp của AI
sự kiểm soát của con người
Kiểm tra đơn vị đường hạnh phúc
bộ xương nhanh
Kỳ vọng có đúng không?
Vỏ cạnh
Động não sâu rộng
Loại bỏ những thứ không liên quan
Lấp đầy khoảng trống phạm vi
Tìm các nhánh bị bỏ qua
Xác nhận tầm quan trọng
Dữ liệu thử nghiệm/mô phỏng
Tạo mẫu thực tế
Không có PII, kiểm soát hiện thực
Kiểm tra quản lý chất lượng, không đảm bảo chất lượng
Phạm vi kiểm tra cao mang lại sự tự tin, nhưng nó cũng có thể gây hiểu nhầm: phạm vi bao phủ 100 phần trăm có nghĩa là "mọi dòng đều được chạy" chứ không phải "mọi dòng đều đúng". Dễ dàng tăng mức độ phủ sóng bằng AI; Giá trị thực sự nằm ở việc viết ra những kỳ vọng có ý nghĩa. Giá trị của bài kiểm tra là khả năng phá vỡ và cảnh báo bạn khi mã bị hỏng. Đó là lý do tại sao các bài kiểm tra do AI tạo ra dựa trên câu hỏi "mã có thực sự bị hỏng khi thay đổi không?" Kiểm tra nó bằng câu hỏi; Cố tình ngắt một dòng và nhìn thấy đoạn kiểm tra bị ngắt (ý tưởng đột biến) là bằng chứng cho thấy bài kiểm tra đã thành công.
Mẹo: Để xem liệu bài kiểm tra mà AI viết có hoạt động hay không, hãy tạo một lỗi nhỏ trong mã (ví dụ: thay đổi + thành -) và xem liệu bài kiểm tra có bị hỏng hay không. Nếu nó không vỡ, bài kiểm tra đó không bảo vệ bạn.
Những lỗi thường gặp
- Yêu cầu kiểm tra mà không đưa ra quy tắc. Mô hình đóng băng hành vi hiện tại; sửa lỗi là "true".
- Chấp nhận những kỳ vọng mà không cần đọc chúng. Việc kiểm tra sẽ gây hiểu nhầm nếu bạn không kiểm tra xem các xác nhận có đang kiểm tra giá trị chính xác hay không.
- Chỉ cần thử nghiệm con đường hạnh phúc. Những lỗi thực sự nằm ở bên lề; Yêu cầu các trường hợp cạnh một cách rõ ràng.
- Nhầm phạm vi cho mục đích. Tỷ lệ phần trăm cao không đảm bảo hành vi đúng.
- Tạo dữ liệu thực/ẩn làm dữ liệu thử nghiệm. Dữ liệu hoặc bí mật của khách hàng không được đưa vào thử nghiệm và lưu trữ; Tạo dữ liệu tổng hợp.
Tóm lại
AI loại bỏ phần lớn gánh nặng lặp đi lặp lại khi viết các bài kiểm tra: nó tạo ra các khung nhanh, danh sách lớn các trường hợp khó khăn và phân tích khoảng cách về phạm vi bao phủ. Nhưng điểm quan trọng nhất là kỳ vọng: AI có xu hướng kiểm tra hành vi hiện tại của mã, trong khi việc kiểm tra phải được viết theo đặc tả. Đưa ra quy tắc, kiểm tra kỳ vọng, thực thi các trường hợp đặc biệt và kiểm tra xem các thử nghiệm có thực sự bảo vệ bằng cách chèn lỗi hay không. Phạm vi kiểm tra là một công cụ, không phải là mục tiêu.
Nhiệm vụ ứng dụng
Chọn một chức năng và trước tiên in bài kiểm tra cho AI bằng cách đưa mã của nó; Lưu ý những mong đợi. Sau đó in lại bài kiểm tra, đưa ra thông số kỹ thuật (hành vi bắt buộc) cho cùng chức năng. So sánh kỳ vọng của hai bộ thử nghiệm: có bộ nào khác nhau không, bộ nào bộc lộ lỗi thực sự? Cuối cùng, hãy xác minh rằng một trong các thử nghiệm được tạo đã hoạt động bằng cách thêm lỗi có chủ ý vào mã và xem lỗi thử nghiệm.
danh sách kiểm tra
- [ ] Tôi phân biệt xem thử nghiệm là để sửa chữa hay xác minh hành vi.
- [ ] Khi tôi yêu cầu một bài kiểm tra, tôi đưa ra quy tắc (thông số kỹ thuật) cần có, chứ không phải mã.
- [ ] Tôi so sánh từng xác nhận được tạo với đặc tả.
- [ ] Tôi yêu cầu rõ ràng các trường hợp khó khăn và thất bại.
- [ ] Tôi xem tỷ lệ phần trăm là một công cụ chứ không phải là mục tiêu.
- [ ] Tôi kiểm tra xem thử nghiệm có thực sự bảo vệ được bằng cách chèn lỗi hay không.