Đơn vị kiểm tra các thủ tục lưu trữ

Tôi đã xem xét điều này từ khá lâu rồi.

Câu hỏi cơ bản là: làm thế nào để kiểm tra đơn vị thủ tục lưu trữ?

Tôi thấy rằng tôi có thể thiết lập các bài kiểm tra đơn vị tương đối dễ dàng cho các hàm theo nghĩa cổ điển (ý tôi là chúng nhận được 0 hoặc nhiều đối số và trả về một giá trị). Nhưng nếu tôi xem xét một ví dụ thực tế về một thủ tục có vẻ đơn giản khi chèn một hàng ở đâu đó, với một vài kích hoạt làm điều này và trước hoặc sau khi chèn, thậm chí việc xác định ranh giới của một "đơn vị" là khá khó khăn. Tôi chỉ nên kiểm tra INSERTchính nó? Điều đó khá đơn giản, tôi nghĩ rằng với giá trị tương đối thấp. Tôi có nên kiểm tra kết quả của toàn bộ chuỗi sự kiện không? Ngoài câu hỏi liệu đây có phải là một bài kiểm tra đơn vị hay không, thiết kế một bài kiểm tra phù hợp có thể là một công việc khá vất vả với rất nhiều dấu hỏi bổ sung phát sinh trên đường đi.

Và sau đó là vấn đề liên tục thay đổi dữ liệu. Trong trường hợp UPDATEảnh hưởng nhiều hơn chỉ một vài hàng, mọi hàng có khả năng bị ảnh hưởng phải được đưa vào bằng cách nào đó trong các trường hợp thử nghiệm. Khó khăn hơn nữa với DELETEs và vân vân và vân vân.

Vì vậy, làm thế nào để bạn đơn vị kiểm tra thủ tục lưu trữ của bạn? Có một ngưỡng trong sự phức tạp nơi nó trở nên hoàn toàn vô vọng? Những nguồn lực cần thiết để bảo trì?

EDIT Một câu hỏi nhỏ nữa, dựa trên câu trả lời của AlexKuznetsov: Hoặc có một ngưỡng mà nó hoàn toàn vô dụng?

Chúng tôi đã làm điều này trong gần năm năm và chúng tôi nghĩ rằng việc sửa đổi thử nghiệm rõ ràng là hoàn toàn có thể thực hiện được, nhưng nó khá chậm. Ngoài ra, chúng tôi không thể dễ dàng chạy các thử nghiệm như vậy đồng thời từ một số kết nối, trừ khi chúng tôi sử dụng các cơ sở dữ liệu riêng biệt. Thay vào đó, chúng tôi nên kiểm tra các thay đổi ngầm - chúng tôi sử dụng chúng để xây dựng ít nhất một số dữ liệu thử nghiệm và xác minh rằng các lựa chọn của chúng tôi trả về kết quả mong đợi.

Tôi đã viết một bài báo có tựa đề Đóng những lỗ hổng đó: Bài học rút ra từ bài kiểm tra đơn vị T-SQL , cũng như một số bài đăng trên blog

Về câu hỏi của bạn "Có một ngưỡng nào trong sự phức tạp khi nó trở nên hoàn toàn vô vọng?", Các mô-đun phức tạp cần các bài kiểm tra nhiều hơn so với các mô đun đơn giản.

Để đơn giản hóa việc bảo trì, chúng tôi tạo ra kết quả mong đợi và chúng tôi lưu trữ chúng trong các tệp riêng biệt - điều đó tạo ra sự khác biệt rất lớn.

Có, bạn nên kiểm tra toàn bộ chuỗi sự kiện như một đơn vị. Vì vậy, trong ví dụ của bạn với một quy trình chèn vào bảng và gây ra một số kích hoạt, bạn nên viết các bài kiểm tra đơn vị để đánh giá thủ tục cho các đầu vào khác nhau. Mỗi thử nghiệm đơn vị phải vượt qua hoặc thất bại tùy thuộc vào việc nó trả về các giá trị chính xác, thay đổi trạng thái của các bảng một cách chính xác, tạo email chính xác và thậm chí gửi các gói mạng chính xác nếu nó được thiết kế để thực hiện điều đó. Trong ngắn hạn, mọi tác động của đơn vị phải được xác minh.

Bạn đã đúng, việc kiểm tra đơn vị thiết kế cần một số công việc, nhưng hầu hết công việc đó phải được thực hiện để kiểm tra đơn vị thủ công, bạn chỉ lưu công việc cần thiết để kiểm tra đơn vị để khi thay đổi được thực hiện trong tương lai, kiểm tra có thể chỉ là triệt để và dễ dàng hơn đáng kể.

Thay đổi dữ liệu làm cho việc kiểm tra trở nên khó khăn hơn, nhưng nó không làm cho việc kiểm tra trở nên ít quan trọng hơn và thực sự làm tăng giá trị của kiểm thử đơn vị vì hầu hết các khó khăn chỉ phải nghĩ qua một lần thay vì mỗi lần thay đổi được thực hiện cho đơn vị. Các bộ dữ liệu đã lưu, chèn / cập nhật / xóa là một phần của thiết lập / phân tích và hoạt động trong phạm vi hẹp đều có thể được sử dụng để làm cho việc này dễ dàng hơn. Vì câu hỏi không phải là cơ sở dữ liệu cụ thể, chi tiết sẽ thay đổi.

Không có ngưỡng phức tạp ở cấp cao hoặc cấp thấp sẽ ngăn bạn kiểm tra hoặc kiểm tra đơn vị. Hãy xem xét những câu hỏi sau:

1. Bạn luôn luôn viết mã lỗi miễn phí?
2. Có phải các đơn vị nhỏ luôn luôn không có lỗi?
3. Có ổn không khi một đơn vị lớn có lỗi?
4. Cần bao nhiêu lỗi để gây ra thảm họa?

Giả sử bạn bắt đầu một công việc mới và được giao nhiệm vụ tối ưu hóa cho một chức năng nhỏ được sử dụng ở nhiều nơi. Toàn bộ ứng dụng được viết và duy trì bởi một nhân viên mà thậm chí không ai còn nhớ. Các đơn vị có tài liệu mô tả hành vi dự kiến ​​bình thường, nhưng ít khác. Bạn muốn tìm cái nào trong số này?

• Không có đơn vị kiểm tra bất cứ nơi nào trong ứng dụng. Sau khi thực hiện thay đổi, bạn có thể thực hiện một số thử nghiệm thủ công đối với chính đơn vị để đảm bảo rằng nó vẫn trả về các giá trị dự kiến ​​trong tài liệu. Sau đó, bạn có thể đưa nó ra sản xuất, bắt chéo ngón tay của mình và hy vọng rằng nó hoạt động (sau tất cả, bạn luôn viết mã không có lỗi và tối ưu hóa trong một đơn vị không bao giờ có thể ảnh hưởng đến một đơn vị khác) hoặc dành một lượng lớn thời gian để tìm hiểu toàn bộ ứng dụng hoạt động để bạn có thể tự kiểm tra mọi đơn vị trực tiếp hoặc gián tiếp thực hiện.
• Đơn vị kiểm tra trong suốt ứng dụng chạy tự động hàng ngày hoặc theo yêu cầu. Họ kiểm tra không chỉ các giá trị đầu vào bình thường và phản ứng mong đợi của họ, mà cả các giá trị bất thường và các ngoại lệ dự kiến ​​sẽ được nêu ra. Bạn thực hiện thay đổi của mình và chạy bộ kiểm tra đơn vị cho ứng dụng ngay lập tức khi thấy rằng ba đơn vị khác không còn trả về kết quả mong đợi. Hai trong số chúng là lành tính, vì vậy bạn tinh chỉnh các bài kiểm tra đơn vị để giải thích cho điều đó. Thứ ba đòi hỏi một tinh chỉnh nhỏ và một bài kiểm tra đơn vị nhỏ mới. Sau khi thực hiện các thay đổi, toàn bộ bộ thử nghiệm thành công và bạn tự tin thực hiện thay đổi.

Đối với PostgreSQL, hãy xem pgTAP :

pgTAP là một bộ các hàm cơ sở dữ liệu giúp bạn dễ dàng viết các bài kiểm tra đơn vị phát ra TAP trong các tập lệnh psql hoặc các hàm kiểm tra kiểu xUnit.

Nếu bạn muốn thử nghiệm các thủ tục được lưu trữ được thực hiện hoàn toàn trên SQL, thì hãy xem http://tsqlt.org/

Nó tương thích với MS SQL 2005 SP2 trở lên và ưu điểm là các nhà phát triển không cần biết C # hoặc ngôn ngữ khác để thực hiện các thử nghiệm.

Ngoài ra còn có các cơ sở để thực hiện các bảng và chế độ xem giả để giúp bạn đạt được bộ kiểm tra có thể chạy lại.