Một prompt có cấu trúc để tạo bộ kiểm thử đơn vị (unit test suite) Python toàn diện từ đầu. Tuân theo luồng phân tích - lập kế hoạch - khởi tạo kèm phân tích chuyên sâu hành vi mã nguồn, bản đồ độ bao phủ đầy đủ, các bài kiểm thử được phân loại theo mẫu AAA, thiết lập mock/patch cho các phụ thuộc bên ngoài, và thẻ tóm tắt chất lượng kiểm thử cuối cùng kèm ước tính độ bao phủ.
Bạn là một kỹ sư kiểm thử Python cấp cao với chuyên môn sâu rộng về pytest, unittest, phát triển hướng kiểm thử (TDD), các chiến lược tạo đối tượng giả lập (mocking), và phân tích độ bao phủ mã nguồn (code coverage). Các bài kiểm thử phải phản ánh đúng hành vi dự kiến của mã nguồn gốc mà không làm thay đổi nó. Sử dụng các tính năng của Python 3.10+ ở những nơi phù hợp. Tôi sẽ cung cấp cho bạn một đoạn mã Python. Hãy tạo một bộ kiểm thử đơn vị (unit test suite) toàn diện theo luồng có cấu trúc dưới đây: --- 📋 BƯỚC 1 — Phân tích Mã nguồn (Code Analysis) Trước khi viết bất kỳ bài kiểm thử nào, hãy phân tích sâu đoạn mã: - 🎯 Mục đích Mã nguồn (Code Purpose) : Tổng thể đoạn mã này làm gì - ⚙️ Hàm/Lớp (Functions/Classes) : Liệt kê mọi hàm và lớp cần được kiểm thử - 📥 Đầu vào (Inputs) : Tất cả các tham số, kiểu dữ liệu, miền giá trị hợp lệ và các đầu vào không hợp lệ - 📤 Đầu ra (Outputs) : Giá trị trả về, kiểu dữ liệu và các biến thể có thể xảy ra - 🌿 Các Nhánh Mã (Code Branches) : Nhận diện mọi nhánh rẽ if/else, try/except, vòng lặp - 🔌 Phụ thuộc Bên ngoài (External Deps) : Các lệnh gọi DB, gọi API, đọc/ghi tệp (file I/O), biến môi trường cần được mock - 🧨 Điểm Dễ Lỗi (Failure Points) : Những vị trí mà mã nguồn có khả năng bị lỗi cao nhất - 🛡️ Vùng Rủi ro (Risk Areas) : Các kịch bản sử dụng sai mục đích, điều kiện biên, các giả định thiếu an toàn Gắn cờ cảnh báo bất kỳ điểm mơ hồ nào trước khi tiếp tục. --- 🗺️ BƯỚC 2 — Bản đồ Độ bao phủ (Coverage Map) Trước khi viết mã kiểm thử, hãy trình bày kế hoạch kiểm thử hoàn chỉnh: | # | Hàm/Lớp (Function/Class) | Kịch bản Kiểm thử (Test Scenario) | Danh mục (Category) | Độ ưu tiên (Priority) | |---|---------------|---------------|----------|----------| Các danh mục (Categories): - ✅ Luồng Thuận lợi (Happy Path) — Hành vi bình thường đúng như kỳ vọng - ❌ Trường hợp Biên (Edge Case) — Các giá trị biên, rỗng, null, giá trị lớn nhất/nhỏ nhất - 💥 Kiểm thử Ngoại lệ (Exception Test)— Các lỗi dự kiến và việc xử lý ngoại lệ - 🔁 Kiểm thử Mock/Patch — Cô lập các thành phần phụ thuộc bên ngoài - 🧪 Đầu vào Tiêu cực (Negative Input) — Các đầu vào không hợp lệ hoặc độc hại Độ ưu tiên (Priority): - 🔴 Bắt buộc phải có (Must Have) — Chức năng cốt lõi, các luồng quan trọng - 🟡 Nên có (Should Have) — Các trường hợp biên, xử lý lỗi - 🔵 Có thì tốt (Nice to Have) — Các kịch bản hiếm gặp, mang tính thông tin Tổng số Bài kiểm thử theo Kế hoạch: [N] Độ bao phủ Ước tính: [N]% (Hướng tới mục tiêu bao phủ dòng & nhánh đạt từ 95%+ trở lên) --- 🧪 BƯỚC 3 — Bộ Kiểm thử Được Khởi tạo (Generated Test Suite) Khởi tạo bộ kiểm thử hoàn chỉnh tuân thủ các tiêu chuẩn sau: Framework & Cấu trúc: - Sử dụng pytest làm framework chính (kết hợp unittest.mock để tạo mock) - Một tệp kiểm thử duy nhất, được chia phần rõ ràng theo từng hàm/lớp - Tất cả các bài kiểm thử đều tuân thủ nghiêm ngặt mẫu AAA: · # Arrange — thiết lập dữ liệu đầu vào và các thành phần phụ thuộc · # Act — gọi hàm cần kiểm thử · # Assert — xác minh kết quả đầu ra Quy ước Đặt tên: - test_[function_name]_[scenario]_[expected_outcome] Ví dụ: test_calculate_tax_negative_income_raises_value_error Yêu cầu về Tài liệu hóa: - Docstring cấp độ module mô tả mục đích của toàn bộ bộ kiểm thử - Docstring cấp độ lớp cho từng lớp kiểm thử - Docstring dài một dòng cho mỗi bài kiểm thử giải thích điều mà nó xác thực - Chỉ viết chú thích nội dòng (inline comments) cho các logic không hiển nhiên Yêu cầu về Chất lượng Mã nguồn: - Tuân thủ chuẩn PEP8 - Sử dụng gợi ý kiểu (type hints) ở những nơi phù hợp - Không dùng các con số ma thuật (magic numbers) — hãy sử dụng hằng số hoặc fixtures - Các fixture có thể tái sử dụng thông qua `@pytest.fixture` - Sử dụng `@pytest.mark.parametrize` cho các bài kiểm thử lặp lại cùng cấu trúc - Chỉ viết các bài kiểm thử tất định (deterministic — không có yếu tố ngẫu nhiên hoặc phụ thuộc trạng thái bên ngoài) - Không dùng mã giữ chỗ (placeholders) hay ghi chú TODO — chỉ cung cấp mã kiểm thử đã hoàn chỉnh 100% --- 🔁 BƯỚC 4 — Thiết lập Mock & Patch (Mock & Patch Setup) Đối với mỗi phụ thuộc bên ngoài đã được nhận diện ở Bước 1: | # | Phụ thuộc (Dependency) | Chiến lược Mock | Đích Patch (Patch Target) | Thành phần Được Cô lập | |---|-----------|---------------|--------------|----------------------| Sau đó cung cấp: - Khối mã thiết lập mock/fixture hoàn chỉnh - Giải thích TẠI SAO từng thành phần phụ thuộc lại cần được mock - Ví dụ về cách sử dụng mock đó trong ít nhất một bài kiểm thử Nguyên tắc Mocking: - Sử dụng `unittest.mock.patch` dưới dạng decorator hoặc trình quản lý ngữ cảnh (context manager) - Sử dụng `MagicMock` cho các đối tượng, `patch` cho các hàm/module - Kiểm tra xác nhận các tương tác với mock ở những nơi phù hợp (ví dụ: `assert_called_once_with`) - KHÔNG mock logic thuần túy hoặc chính bản thân hàm đang được kiểm thử — chỉ mock các ranh giới giao tiếp bên ngoài --- 📊 BƯỚC 5 — Thẻ Tóm tắt Kiểm thử (Test Summary Card) Tổng quan Bộ Kiểm thử: Tổng số Bài kiểm thử Đã tạo : [N] Độ bao phủ Ước tính : [N]% (Dòng - Line) | [N]% (Nhánh - Branch) Framework Đã sử dụng : pytest + unittest.mock | Danh mục (Category) | Số lượng | Ghi chú | |-------------------|-------|------------------------------------| | Happy Path | ... | ... | | Edge Cases | ... | ... | | Exception Tests | ... | ... | | Mock/Patch | ... | ... | | Negative Inputs | ... | ... | | Must Have | ... | ... | | Should Have | ... | ... | | Nice to Have | ... | ... | | Tiêu chí Chất lượng (Quality Marker) | Trạng thái | Ghi chú | |-------------------------|---------|------------------------------| | Mẫu AAA (AAA Pattern) | ✅ / ❌ | ... | | Quy ước Đặt tên | ✅ / ❌ | ... | | Có sử dụng Fixtures | ✅ / ❌ | ... | | Có sử dụng Parametrize | ✅ / ❌ | ... | | Cô lập Mock Đúng cách | ✅ / ❌ | ... | | Kiểm thử Tất định | ✅ / ❌ | ... | | Tuân thủ PEP8 | ✅ / ❌ | ... | | Có đầy đủ Docstrings | ✅ / ❌ | ... | Khoảng trống & Khuyến nghị: - Bất kỳ kịch bản nào chưa được bao phủ và lý do tại sao - Các bước tiếp theo được đề xuất (kiểm thử tích hợp, kiểm thử dựa trên thuộc tính property-based tests, kiểm thử làm mờ fuzzing) - Câu lệnh để chạy bộ kiểm thử: pytest [filename] -v --tb=short --- Đây là đoạn mã Python của tôi: [PASTE YOUR CODE HERE]
Giải thích từng dòng của tệp .gitignore, kiểm thử tệp đó với các đường dẫn bắt buộc phải bỏ qua hoặc bắt buộc phải giữ lại để có thể commit, chỉ rõ quy tắc quyết định cho từng đường dẫn, đồng thời cảnh báo các lỗi sai như quy tắc phủ định bị chặn bởi thư mục cha đã bị loại trừ, chú thích nội dòng (inline comment), khoảng trắng ở đầu dòng, dấu gạch chéo ngược (backslash), ký tự ** thừa, thông tin bí mật (secrets) chưa được bao phủ và tệp .env.example bị bỏ qua. Trả về một tệp đã được sửa lỗi. Bao gồm một trình kiểm tra viết bằng thư viện chuẩn Python có hỗ trợ --self-test, đối chiếu khớp với git thực tế.
Tìm các bài kiểm thử chập chờn (flaky test) từ các lần chạy CI lặp đi lặp lại: phân tích cú pháp tệp JUnit XML hoặc lịch sử chạy dạng CSV, gắn cờ các bài kiểm thử lúc đạt lúc trượt (được xác nhận khi xảy ra trên cùng một commit), xếp hạng chúng theo tỷ lệ đảo chiều và tỷ lệ lỗi, đồng thời đề xuất nguyên nhân có thể xảy ra và cách khắc phục. Sử dụng khi CI "báo đỏ ngẫu nhiên", trước khi thêm cơ chế chạy lại (retry), hoặc khi phân loại danh sách cách ly (quarantine). Bao gồm công cụ phát hiện bằng thư viện chuẩn Python với cờ --self-test.
Giải thích biểu thức chính quy (regular expressions) trong Python theo từng thành phần (token), kiểm thử chúng trên các mẫu bắt buộc phải khớp và bắt buộc không được khớp kèm vị trí khớp (spans) và nhóm định danh (named groups), đồng thời gắn cờ cảnh báo các mẫu tiềm ẩn rủi ro: các toán tử định lượng lồng nhau gây quay lui thảm khốc (catastrophic backtracking), [A-z], dấu chấm chưa thoát ký tự (unescaped dot), kết quả khớp rỗng và thiếu ký tự neo (anchors), sau đó đề xuất bản viết lại an toàn hơn. Sử dụng khi người dùng hỏi "regex này làm gì?", "tại sao nó không khớp?" hoặc "regex này có an toàn không?". Đi kèm công cụ kiểm tra bằng thư viện chuẩn Python đã được kiểm thử.
Kiểm tra một thư mục tài liệu Markdown để tìm các liên kết gây lỗi cho người đọc - các liên kết tương đối trỏ đến những tệp bị thiếu hoặc đã đổi tên, các điểm neo (anchor) không khớp với tiêu đề nào, các điểm neo tiêu đề bị trùng lặp, cách viết hoa thường tên tệp chỉ hoạt động trên macOS, đường dẫn tuyệt đối cục bộ, các liên kết kiểu tham chiếu bị thiếu, không sử dụng hoặc trùng lặp định nghĩa, hình ảnh thiếu văn bản thay thế (alt text) và các URL trần. Hoạt động ngoại tuyến và liệt kê các URL bên ngoài để kiểm tra riêng. Bao gồm một trình kiểm tra bằng thư viện chuẩn Python với tùy chọn --self-test.
