Lợi nhuận:
- Khả năng ngăn trí tuệ nhân tạo chấp nhận hành vi sai lầm là 'đúng' bằng cách tính giá trị mong đợi trong các bài kiểm tra đơn vị độc lập với quy tắc chấp nhận
- Khả năng in các bài kiểm tra nhanh, độc lập và có thể lặp lại bằng cách áp dụng các nguyên tắc AAA và FIRST cũng như mô phỏng các phụ thuộc bên ngoài
- Khả năng kiểm tra các thử nghiệm có đột biến (phá mã) và nhận ra mã khó kiểm tra là mùi thiết kế
Lớp lớn nhất và nhanh nhất của kim tự tháp thử nghiệm là thử nghiệm đơn vị - thử nghiệm xác minh một chức năng hoặc đoạn mã nhỏ tách biệt với mọi thứ khác. Hàng nghìn bài kiểm tra đơn vị chạy trong vài giây và phát hiện lỗi trong khi mã vẫn còn trên màn hình của nhà phát triển. Trí tuệ nhân tạo (AI) có lẽ thành thạo nhất trong việc tạo ra các bài kiểm tra đơn vị: bạn đưa cho nó một chức năng, AI sẽ tạo ra hàng tá bài kiểm tra. Nhưng chính sự tiện lợi này đã dẫn đến cái bẫy lớn nhất: AI dễ dàng tạo ra các bài kiểm tra “có màu xanh lục nhưng không xác minh bất cứ điều gì” hoặc chấp nhận hành vi hiện tại (có thể bị lỗi) của mã là “chính xác”. Trong phần này, bạn sẽ học cách viết các bài kiểm thử đơn vị có tính bảo vệ thực sự bằng AI và mối quan hệ giữa mã có thể kiểm thử và AI.
Phẩm chất của một bài kiểm tra đơn vị tốt: ĐẦU TIÊN
Các bài kiểm tra đơn vị tốt tuân theo các nguyên tắc ĐẦU TIÊN: Nhanh, Độc lập (các bài kiểm tra không nên phụ thuộc vào nhau), Có thể lặp lại (có thể lặp lại - cùng một kết quả trong mọi môi trường), Tự xác thực (đạt/không đạt rõ ràng), Kịp thời (đúng giờ). Hãy nhắc nhở bản thân về những nguyên tắc này khi nhờ AI thực hiện các bài kiểm tra; yêu cầu cụ thể rằng bài kiểm tra không phụ thuộc vào thế giới bên ngoài (cơ sở dữ liệu thực tế, mạng, đồng hồ) để "độc lập" và "có thể lặp lại".
Mẫu AAA và sự khẳng định mang tính biểu cảm
Kiểm thử đơn vị vững chắc tuân theo cấu trúc AAA: Sắp xếp (chuẩn bị — thiết lập đầu vào và phần phụ thuộc), Hành động (thực thi — gọi hàm đang được kiểm tra), Khẳng định (xác thực — so sánh kết quả với giá trị mong đợi). Điều quan trọng là khẳng định. Lỗi phổ biến nhất mà AI mắc phải là đưa ra xác nhận từ đầu ra của mã đang được kiểm tra - logic “bất cứ mã nào trả về đều là đúng”. Điều này làm cho bài kiểm tra trở nên vô nghĩa. Cách đúng là xác định giá trị kỳ vọng một cách độc lập (từ tiêu chí chấp nhận, tính toán thủ công).
Chú ý: Nếu bạn nói với AI "viết bài kiểm tra cho hàm này", AI có thể chạy hàm và ghi kết quả đầu ra của nó là "dự kiến". Kiểm tra này vượt qua ngay cả khi chức năng sai. Thay vào đó, hãy nói "bạn tính toán kết quả mong đợi theo các quy tắc này, không tham chiếu kết quả đầu ra hiện tại của hàm".
Mô phỏng, sơ khai và phụ thuộc
Kiểm thử đơn vị yêu cầu sự cô lập. Nếu chức năng của bạn phụ thuộc vào cơ sở dữ liệu hoặc API, chúng sẽ được thay thế bằng các đối tượng mô phỏng (mock/stub — một sự thay thế giả, được kiểm soát cho phần phụ thuộc thực) trong thử nghiệm. Điều này làm cho bài kiểm tra nhanh chóng, độc lập và có thể lặp lại. AI có thể tạo ra bản cài đặt mô phỏng; Nhưng hãy cẩn thận với việc chế nhạo quá mức: nếu bạn chế nhạo mọi thứ, bài kiểm tra sẽ chỉ xác minh "những gì mô phỏng trả về", chứ không phải logic thực tế. Cân bằng: mô phỏng thế giới bên ngoài, thực thi logic thực đang được thử nghiệm.
Khả năng kiểm tra và AI
Có một phản hồi thú vị: mã khó kiểm tra thường là mã được thiết kế kém. Nếu AI gặp khó khăn khi viết bài kiểm tra cho một hàm (quá nhiều phụ thuộc, trạng thái toàn cục bị ẩn, tác dụng phụ), thì đó là lỗi thiết kế. Hỏi AI “bạn sẽ cấu trúc lại mã này như thế nào để làm cho nó có thể kiểm tra được” dẫn đến việc kiểm tra tốt hơn và mã tốt hơn.
Kiểm tra tham số và đa dạng dữ liệu
Mỗi lần viết một bài kiểm tra riêng để xác minh cùng một quy tắc với các đầu vào khác nhau vừa tẻ nhạt vừa khó duy trì. Kiểm tra tham số hóa - một cấu trúc chạy lặp đi lặp lại cùng một logic kiểm tra trên danh sách đầu vào và kết quả mong đợi - loại bỏ sự lặp lại này: một nội dung kiểm tra duy nhất được cung cấp hàng tá cặp đầu vào. AI rất hiệu quả trong việc tạo ra các bảng kết quả đầu vào mong đợi này khi bạn đưa ra cho nó các quy tắc chấp nhận; Đặc biệt, nó lập bảng một cách có hệ thống các giá trị giới hạn và các lớp tương đương.
Nhưng ở đây cũng có một cái bẫy: AI có xu hướng rút ra kết quả mong đợi trong bảng được tạo từ mã đang được thử nghiệm. Lỗi này thậm chí còn nguy hiểm hơn trong thử nghiệm tham số hóa, bởi vì một logic không chính xác sẽ làm mất hiệu lực của hàng chục dòng. Do đó, hãy luôn để cột kết quả mong đợi được tính toán độc lập theo quy tắc chấp nhận và xác thực thủ công ít nhất một vài hàng. Đồng thời yêu cầu cột mô tả "mỗi hàng đại diện cho điều gì"; vì vậy khi một hàng bị ngắt, bạn sẽ thấy ngay trạng thái nào bị hỏng.
Mẹo: Cố tình thêm một “hàng bẫy” vào bảng kiểm tra được tham số hóa — tức là cố tình nhập sai kết quả. Nếu dòng đó không chuyển sang màu đỏ khi bạn chạy bài kiểm tra thì bài kiểm tra của bạn không thực sự xác minh tình huống đó. Đây là một cuộc kiểm tra giả nhanh chóng.
Dấu nhắc yếu / Dấu nhắc mạnh
Yếu: "Viết bài kiểm tra đơn vị cho chức năng này."
Mạnh: Viết bài kiểm tra đơn vị [ngôn ngữ/khung] cho hàm "taxCalculate(amount, rate). Quy tắc chấp nhận: kết quả = số tiền * tỷ lệ, làm tròn đến 2 số thập phân; số tiền hoặc tỷ lệ âm sẽ gây ra lỗi; trả về 0 nếu tỷ lệ là 0. Sử dụng cấu trúc AAA. Tính toán thủ công các giá trị kỳ vọng theo các quy tắc NÀY; không tham chiếu đầu ra hiện tại của hàm. Bao gồm các trường hợp giới hạn và âm (0, âm, rất lớn, làm tròn thành số thập phân). Hãy đặt tên của từng thử nghiệm mô tả quy tắc mà nó xác minh. Phụ thuộc bên ngoài "Không."
Lời nhắc mạnh mẽ; Nó đưa ra quy tắc chấp nhận, kỳ vọng giá trị kỳ vọng độc lập, cấu trúc và các trường hợp cạnh. Vì vậy, bài kiểm tra trở thành người bảo vệ các quy tắc chứ không phải là tấm gương phản chiếu của mã.
Bảng chất lượng kiểm tra đơn vị
triệu chứng
Kiểm tra kém (tin cậy giả)
bài kiểm tra tốt
khẳng định
Không có hoặc "không rỗng"
Giá trị cụ thể dự kiến
Nguồn giá trị dự kiến
Đầu ra của hàm
Quy tắc chấp nhận/tính toán thủ công
nghiện
DB thực tế/mạng/giờ
Cách nhiệt bằng mô phỏng/sơ khai
trường hợp cạnh
Con đường hạnh phúc duy nhất
giới hạn, tiêu cực, lỗi
Khi bạn phá mã
vẫn xanh
chuyển sang màu đỏ
Tên
test1, phương thức kiểm tra
mô tả quy tắc nó xác nhận
Bốn mẫu có thể sao chép
1) Kiểm tra đơn vị theo quy tắc:
Vai trò của bạn: kỹ sư kiểm thử phần mềm cấp cao. Viết bài kiểm thử đơn vị cho hàm sau bằng [ngôn ngữ/khung]: [chữ ký]. Quy tắc chấp nhận: [quy tắc].- Sử dụng cấu trúc AAA.- Tính toán thủ công các giá trị mong đợi theo các quy tắc NÀY; KHÔNG tham chiếu đầu ra hiện tại của hàm. - Bao gồm đường dẫn giới hạn, tiêu cực, lỗi và hạnh phúc bằng các thử nghiệm riêng biệt. - Hãy để mỗi tên bài kiểm tra mô tả quy tắc mà nó xác minh. - Giả lập các phụ thuộc bên ngoài; Làm cho logic thực tế hoạt động.
2) Kiểm soát khả năng kháng đột biến:
Kiểm tra các bài kiểm tra đơn vị này. Liệt kê 5 điều chỉnh nhỏ mà tôi có thể thực hiện đối với mã đang được thử nghiệm (a - thay vì +, a >= thay vì a >, dịch chuyển ranh giới) và cho tôi biết đối với mỗi điều chỉnh, BÀI kiểm tra nào trong số này sẽ chuyển sang màu đỏ? Nếu không có kết quả nào được trả về thì bài kiểm tra không đủ. Mã + bài kiểm tra: [dán]
3) Đánh giá khả năng kiểm thử:
Tại sao việc viết bài kiểm tra đơn vị cho chức năng này lại khó khăn? Nghiện tiềm ẩn, địa vị toàn cầu, tác dụng phụ, có nhiều trách nhiệm? Đề xuất tái cấu trúc tối thiểu để làm cho nó có thể kiểm tra được; không thay đổi hành vi. Mã: [dán]
4) Hoàn thành kịch bản chưa đầy đủ:
Các chức năng sau đây và các bài kiểm tra có sẵn được đưa ra. Liệt kê hành vi/edgecase nào CHƯA BAO GIỜ được kiểm tra (khoảng cách phạm vi) và thêm kiểm tra cho từng hành vi/edgecase. Chức năng+kiểm tra: [dán]
ba trường hợp nhỏ
Trường hợp 1 - Kiểm tra việc sao chép mã. Một nhà phát triển đã nhờ AI viết bài kiểm tra hàm làm tròn; 10 bài kiểm tra đều xanh. Trên thực tế, hàm đã làm tròn sai hướng nhưng AI đã lấy các giá trị mong đợi từ đầu ra của hàm nên các cuộc kiểm tra coi lỗi là "true". Khi các giá trị mong đợi được tính toán thủ công bằng mẫu "theo quy tắc", 4 lần kiểm tra đều chuyển sang màu đỏ và lỗi thực sự đã lộ diện.
Trường hợp 2 - Giá trị của kiểm soát đột biến. Một đội dựa vào 45 bài kiểm tra đơn vị. Đã thử 20 điều chỉnh nhỏ đối với mã bằng "kiểm tra độ mạnh của đột biến"; các cuộc kiểm tra chỉ bắt được 11 người trong số họ. 9 lần gián đoạn còn lại trôi qua trong im lặng. Nhóm tăng cường các bài kiểm tra yếu; Các thử nghiệm nâng cao này đã phát hiện ra lỗi tính toán thực tế trong phiên bản tiếp theo.
Trường hợp 3 - Tính không thể kiểm thử là mùi thiết kế. AI không thể viết bài kiểm tra cho chức năng đặt hàng, nó liên tục cần cơ sở dữ liệu thực. Mẫu "đánh giá khả năng kiểm tra" cho thấy chức năng truy cập cơ sở dữ liệu được nhúng. Khi loại bỏ phần nội dung phụ thuộc, các bài kiểm tra có thể được viết và mã trở nên sạch hơn.
Những lỗi thường gặp
- Lấy giá trị mong đợi từ mã. AI chấp nhận đầu ra hàm là "chính xác"; kiểm tra xác nhận mã bị lỗi.
- Kiểm tra mà không có khẳng định hoặc với khẳng định tầm thường. Logic "Anh ấy không phạm lỗi, anh ấy đã vượt qua" logic; Nó không xác nhận bất cứ điều gì.
- Cực kỳ giả tạo. Chế nhạo mọi thứ và chỉ kiểm tra những gì mà mô hình trả về; logic thực sự không được kiểm tra.
- Chỉ là con đường hạnh phúc. Bỏ qua các trạng thái giới hạn, tiêu cực và lỗi.
- Không kiểm tra bằng cách phá mã. Tin tưởng vào màu xanh lá cây mà không kiểm tra đột biến.
- Bỏ qua tính không thể kiểm chứng. Không nhận ra và sửa chữa thiết kế xấu thay vì đẩy mạnh việc kiểm thử.
Tóm lại
Kiểm thử đơn vị là lớp nhanh nhất và lớn nhất của kim tự tháp kiểm thử; Nó bắt lỗi vào thời điểm rẻ nhất. AI rất có khả năng tạo ra các bài kiểm tra đơn vị, nhưng cạm bẫy lớn nhất của nó là viết các bài kiểm tra giả định hành vi không chính xác là "đúng" bằng cách lấy giá trị mong đợi từ chính mã đó. Giải pháp: đưa ra các quy tắc chấp nhận, tính toán thủ công các giá trị mong đợi, thực thi các nguyên tắc AAA và FIRST, mô phỏng thế giới bên ngoài và chạy logic thực tế, đồng thời kiểm tra từng thử nghiệm bằng đột biến (phá mã). Mã khó kiểm tra là dấu hiệu thiết kế cần sửa.
Nhiệm vụ ứng dụng
Chọn một hàm chứa quy tắc công việc từ dự án của riêng bạn. Viết các quy tắc chấp nhận và yêu cầu AI viết các bài kiểm tra với mẫu “thử nghiệm đơn vị theo quy tắc”; Có các giá trị mong đợi được tính toán thủ công. Sau đó, áp dụng “kiểm tra độ mạnh của đột biến”: tạo ít nhất 5 điểm ngắt nhỏ trong mã và đo xem có bao nhiêu lần kiểm tra chuyển sang màu đỏ. Thêm thử nghiệm mới cho các lỗi chưa được phát hiện. Báo cáo số lần gián đoạn đã được phát hiện (chẳng hạn như điểm đột biến).
danh sách kiểm tra
- [ ] Tôi đã đưa ra các quy tắc chấp nhận và tính toán các giá trị mong đợi theo cách thủ công.
- [ ] Tôi đã đảm bảo rằng các cuộc kiểm tra không lấy được giá trị mong đợi từ mã.
- [ ] Tôi đã thiết lập thử nghiệm độc lập theo hướng dẫn của AAA và FIRST.
- [ ] Tôi đã chế nhạo các phần phụ thuộc bên ngoài và chạy logic thực tế.
- [ ] Tôi đã đề cập đến các trường hợp giới hạn, tiêu cực và lỗi.
- [ ] Bằng cách phá mã (đột biến), tôi đã chứng minh rằng các thử nghiệm thực sự có tác dụng bảo vệ.