Có một số công cụ kiểm tra khác nhau cho PL / SQL trên mạng. Steven Feuerstein đã viết hai trong số chúng, utplsql và Trình kiểm tra mã nhiệm vụ dành cho Oracle (trước đây là QUTE). Tôi là một fan hâm mộ lớn của utplsql, nhưng nó không còn có một cộng đồng hỗ trợ tích cực nữa (thật đáng tiếc). Nó cũng có xu hướng khá dài dòng, đặc biệt là khi nói đến việc thiết lập các thiết bị kiểm tra. Nó có ảo chính là gói PL / SQL thuần túy ; mã nguồn là một chút phức tạp nhưng nó là FOSS.
QCTO đi kèm với GUI, có nghĩa là - giống như các sản phẩm Quest khác, tức là TOAD - nó chỉ dành cho Windows. Nó không tự động hóa chính xác việc tạo dữ liệu thử nghiệm, nhưng nó cung cấp một giao diện để hỗ trợ nó. Cũng giống như các sản phẩm Nhiệm vụ khác, QCTO được cấp phép mặc dù có bản sao phần mềm miễn phí.
Steven (tiết lộ, anh ấy là một trong những anh hùng Oracle của tôi) đã viết một bản so sánh tính năng của tất cả các công cụ kiểm tra PL / SQL. Rõ ràng, QOTC đứng đầu, nhưng tôi nghĩ sự so sánh là trung thực. Hãy khám phá.
Lời khuyên về các thiết bị kiểm tra trong utplsql
Quản lý dữ liệu thử nghiệm để kiểm tra đơn vị có thể là một cơn đau thực sự ở cổ. Thật không may, utplsql không cung cấp nhiều để gánh vác gánh nặng. Vì vậy,
- Luôn kiểm tra các giá trị đã biết :
- Tránh sử dụng dbms_random;
- Cố gắng hạn chế việc sử dụng chuỗi cho các cột có giá trị không quan trọng;
- Ngày cũng rất phức tạp. Tránh ngày mã hóa cứng:sử dụng các biến được điền bằng ngày tháng. Học cách đánh giá cao
add_months(),last_day(),interval,trunc(sysdate, 'MM'), v.v.
- Tách dữ liệu thử nghiệm khỏi những người dùng khác. Xây dựng nó từ đầu. Sử dụng các giá trị đặc biệt nếu có thể.
- Chỉ tạo nhiều dữ liệu thử nghiệm nếu bạn cần. Kiểm tra thể tích là một trách nhiệm khác.
- Khi các thủ tục kiểm tra thay đổi dữ liệu, hãy tạo các bản ghi cụ thể cho từng bài kiểm tra đơn vị.
- Ngoài ra:không dựa vào kết quả thành công từ một thử nghiệm để cung cấp đầu vào từ một thử nghiệm khác.
- Khi kiểm tra các thủ tục chỉ báo cáo dựa trên bản ghi chia sẻ dữ liệu giữa các bài kiểm tra đơn vị khi thích hợp.
- Chia sẻ dữ liệu khung (ví dụ:khóa chính được tham chiếu) bất cứ khi nào có thể.
- Sử dụng các trường văn bản miễn phí (tên, mô tả, nhận xét) để xác định bài kiểm tra hoặc bài kiểm tra nào sử dụng bản ghi.
- Giảm thiểu công việc liên quan đến việc tạo các bản ghi mới:
- Chỉ gán các giá trị cần thiết cho bộ thử nghiệm và các ràng buộc của bảng;
- Sử dụng các giá trị mặc định nhiều nhất có thể;
- Tiến hành thủ tục càng nhiều càng tốt.
Những điều khác cần lưu ý:
- thiết lập một lịch thi đấu có thể là một bài tập tốn nhiều thời gian. Nếu bạn có nhiều dữ liệu, hãy cân nhắc xây dựng một quy trình để thiết lập dữ liệu tĩnh có thể chạy một lần mỗi phiên và chỉ bao gồm dữ liệu biến động trong
ut_setupchính nó. Điều này đặc biệt hữu ích khi thử nghiệm chức năng chỉ đọc. - hãy nhớ rằng việc tạo dữ liệu thử nghiệm là một bài tập lập trình theo đúng nghĩa của nó và rất dễ xảy ra lỗi.
- sử dụng tất cả các tính năng của utplsql.
utAssert.EqQuery,utAssert.EqQueryValue,utAssert.EqTable,utAssert.EqTabCountvàutAssert.Eq_RefC_Querylà tất cả các tính năng rất hữu ích khi nói đến việc suy ra các giá trị của dữ liệu biến động. - khi chẩn đoán một lần chạy thử nghiệm không diễn ra theo cách chúng tôi mong đợi, việc sử dụng dữ liệu có thể hữu ích. Vì vậy, hãy xem xét có một
ut_teardownrỗng quy trình và xóa dữ liệu thử nghiệm khi bắt đầuut_setup.
Xử lý mã kế thừa
Nhận xét về bài đăng của Gary nhắc nhở tôi về một điều khác mà bạn có thể thấy hữu ích. Steven F đã viết ulplsql dưới dạng triển khai PL / SQL của JUnit, đội tiên phong của Java trong phong trào Thử nghiệm Đầu tiên. Tuy nhiên, các kỹ thuật của TDD cũng có thể được áp dụng cho một lượng lớn mã kế thừa (trong bối cảnh này, mã kế thừa là bất kỳ bộ chương trình nào mà không có bất kỳ bài kiểm tra đơn vị nào).
Điều quan trọng cần ghi nhớ là bạn không cần phải hoàn thành mọi thứ trong bài kiểm tra đơn vị ngay lập tức. Bắt đầu tăng dần. Tạo các bài kiểm tra đơn vị cho nội dung mới, Thử nghiệm trước . Xây dựng các bài kiểm tra đơn vị cho các bit bạn sẽ thay đổi trước khi áp dụng thay đổi, để bạn biết rằng chúng vẫn hoạt động sau khi bạn thực hiện thay đổi.
Có rất nhiều suy nghĩ trong lĩnh vực này, nhưng (không tránh khỏi nếu đáng xấu hổ) nó chủ yếu đến từ các lập trình viên OO. Michael Feathers là chap chính. Đọc bài viết của anh ấy Làm việc hiệu quả với mã kế thừa . Nếu bạn thấy hữu ích, sau đó anh ấy đã viết một cuốn sách cùng tên.
