Làm thế nào để (đơn vị) kiểm tra dữ liệu chuyên sâu PL/SQL ứng dụng

Question

Nhóm của chúng tôi sẵn sàng kiểm tra đơn vị một mã mới được viết theo một dự án đang chạy mở rộng một hệ thống Oracle hiện có rất lớn.

Hệ thống được viết hoàn toàn bằng PL/SQL, bao gồm hàng nghìn bảng, hàng trăm gói thủ tục lưu trữ, chủ yếu nhận dữ liệu từ bảng và/hoặc chèn/cập nhật dữ liệu khác.

Tiện ích mở rộng của chúng tôi không phải là ngoại lệ. Hầu hết các hàm trả về dữ liệu từ một câu lệnh SELECT phức tạp trên nhiều bảng bị ràng buộc lẫn nhau (với một logic được thêm vào trước khi trả về) hoặc chuyển đổi từ một cấu trúc dữ liệu phức tạp sang cấu trúc dữ liệu phức tạp khác (phức tạp theo cách khác).

Cách tiếp cận tốt nhất để kiểm tra đơn vị mã như vậy là gì?

Không có kiểm tra đơn vị nào cho cơ sở mã hiện có. Để làm cho mọi việc tồi tệ hơn, chỉ các gói, trình kích hoạt và khung nhìn được kiểm soát nguồn, cấu trúc bảng (bao gồm cả công cụ "thay đổi bảng" và các biến đổi dữ liệu cần thiết được triển khai thông qua kênh ngoài điều khiển phiên bản). Không có cách nào để thay đổi điều này trong phạm vi dự án của chúng tôi.

Việc duy trì bộ dữ liệu thử nghiệm dường như là không thể vì có mã mới được triển khai cho môi trường sản xuất hàng tuần, thường không có thông báo trước, thường thay đổi cấu trúc dữ liệu (thêm cột ở đây, xóa cột ở đó).

Tôi rất vui vì bất kỳ đề xuất hoặc tham chiếu nào để giúp chúng tôi. Một số thành viên trong nhóm có xu hướng mệt mỏi bằng cách tìm ra cách để bắt đầu trải nghiệm của chúng tôi với thử nghiệm đơn vị không bao gồm các hệ thống kế thừa dữ liệu PL/SQL chuyên sâu (chỉ có những dự án Java "xanh").

Answer 1

Có một số công cụ kiểm tra khác nhau cho PL/SQL ngoài đó. Steven Feuerstein đã viết hai trong số chúng, utplsql và Quest Code Tester for 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 (đó là một sự xấu hổ). Nó cũng có xu hướng khá tiết tấu, đặc biệt là khi thiết lập đồ đạc thử nghiệm. Nó có số ảo là gói PL/SQL tinh khiết; mã nguồn hơi gnarly 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 - chỉ là Windows. Nó không chính xác tự động hóa 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 Quest 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 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 ra mắt, nhưng tôi nghĩ sự so sánh là trung thực. Check it out.

Tư vấn về đồ đạc kiểm tra trong utplsql

dữ liệu quản lý kiểm tra cho kiểm tra đơn vị có thể là một nỗi đ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 luôn kiểm tra chống giá trị đã biết:
  • Tránh sử dụng dbms_random;
  • Cố gắng hạn chế việc sử dụng chuỗi các cột có giá trị không quan trọng;
  • Ngày cũng 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 sysdate. Học cách đánh giá cao add_months(), last_day(), interval, trunc(sysdate, 'MM') vv
• Cô lập các dữ liệu thử nghiệm từ 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 bất cứ khi nào 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 quy trình thử nghiệm thay đổi dữ liệu tạo ra các bản ghi cụ thể cho mỗi bài kiểm tra đơn vị.
• Ngoài ra: không phụ thuộc vào đầu ra 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 thử nghiệm các thủ tục chỉ đơn giản là báo cáo chống lại dữ liệu chia sẻ hồ sơ 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 thử nghiệm hoặc kiểm tra nào sử dụng hồ sơ.
• Giảm thiểu công việc liên quan đến việc tạo 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 giá trị mặc định càng nhiều càng tốt;
  • Thủ tục hóa càng nhiều càng tốt.

Những điều khác cần ghi nhớ:

• thiết lập bộ ghép đo có thể là một tập thể dục tốn nhiều thời gian. Nếu bạn có nhiều dữ liệu, hãy xem xét 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 dễ bay hơi trong chính số ut_setup. Đ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à dễ bị lỗi.
• sử dụng tất cả các tính năng của utplsql. utAssert.EqQuery, utAssert.EqQueryValue, utAssert.EqTable, utAssert.EqTabCount và utAssert.Eq_RefC_Query là 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 dễ bay hơi.
• khi chẩn đoán chạy thử nghiệm không theo cách chúng tôi mong đợi có thể hữu ích khi có dữ liệu được sử dụng. Vì vậy, hãy xem xét có một thủ tục rỗng ut_teardown và xóa dữ liệu thử nghiệm lúc bắt đầu ut_setup.

Đối phó với mã di sản

Bình luận về bài của Gary nhắc tôi nhớ đến một điều khác mà bạn có thể thấy hữu ích. Steven F đã viết ulplsql như là một triển khai PL/SQL của JUnit, một đội tiên phong Java của phong trào Test First. 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 ngữ 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ỳ kiểm tra đơn vị nào).

Điều quan trọng cần ghi nhớ là bạn không phải làm mọi thứ dưới thử nghiệm đơn vị ngay lập tức. Bắt đầu tăng dần. Xây dựng các bài kiểm tra đơn vị cho các công cụ mới, Test First. 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 bạn áp dụng thay đổi, vì vậy 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 (chắc chắn nếu đáng xấu hổ) 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 mình Working Effectively With Legacy Code. Nếu bạn thấy nó hữu ích sau đó ông đã viết một cuốn sách cùng tên.

Answer 2

utPLSQL có thể hữu ích, nhưng có vẻ như bạn cần một cách tốt hơn để duy trì dữ liệu thử nghiệm. Bạn có thể cũng muốn xem Swingbench cho điều đó.

Answer 3

Tôi đã sử dụng DbFit để kiểm tra đơn vị mã PL/SQL. Hãy thử một lần.

Answer 4

Đi kịch bản sau đây

FUNCTION ret_count (local_client_id IN number) RETURN NUMBER IS 
    v_ret number; 
BEGIN 
    SELECT count(*) INTO v_ret FROM table_1 WHERE client_id = local_client_id; 
    RETURN v_ret; 
END; 

chức năng Rất đơn giản nhưng có một mớ hỗn độn toàn bộ những thứ mà có thể đi sai. Chuyển đổi kiểu dữ liệu, lập chỉ mục, thống kê tất cả có thể ảnh hưởng đến đường dẫn truy vấn, hiệu suất và, trong một số trường hợp, lỗi. Ngoài ra còn có rất nhiều khớp nối lỏng lẻo như cài đặt phiên (ví dụ như sở thích ngôn ngữ). Nếu ai đó đến và thêm cột "LOCAL_CLIENT_ID" vào bảng_1, toàn bộ logic của hàm sẽ thay đổi.

Cá nhân tôi không cảm thấy rằng TDD phù hợp với môi trường này. Đánh giá mã của các cá nhân có kiến ​​thức sẽ có cơ hội bắt gặp các vấn đề lớn hơn.

Nếu bạn có tiền, hãy xem RAT của Oracle (kiểm tra ứng dụng thực) để kiểm tra hồi quy.