Tôi có phải là Kiểm tra đơn vị hoặc Kiểm tra tích hợp Các thủ tục được lưu trữ của tôi không?

Gần đây tôi đã có nhiều lần cần thiết để duy trì các thủ tục và chức năng được lưu trữ phức tạp. Chúng đã bị hỏng, thường là theo những cách khá tinh tế - có rất ít trường hợp bạn sẽ gọi SP với các tham số hợp lệ và nó hoàn toàn không hoạt động.

Giải pháp của tôi là phát triển một khung hình thực thi các thủ tục được lưu trữ trong một giao dịch, sau khi khởi tạo cơ sở dữ liệu theo các điều kiện ban đầu tôi cần, sau đó kiểm tra kết quả mong đợi, cũng trong cùng một giao dịch. Giao dịch đã được khôi phục vào cuối thử nghiệm.

Điều này đã làm việc rất tốt. Nhưng một số người sẽ gọi đây là "thử nghiệm tích hợp" vì nó liên quan đến việc tích hợp với cơ sở dữ liệu. Tôi gọi nó là thử nghiệm đơn vị, vì tôi đã thử nghiệm các thành phần riêng lẻ và các trường hợp thử nghiệm riêng lẻ cho các thành phần đó và vì tôi hoàn toàn kiểm soát trạng thái ban đầu của cơ sở dữ liệu.

Nhưng dòng nên được vẽ ở đâu? Đây là thử nghiệm tích hợp hoặc thử nghiệm đơn vị? Có một lý do thực tế tại sao loại thử nghiệm này là một ý tưởng tồi? Nếu đây là thử nghiệm tích hợp "duy nhất", có ai có đề xuất về cách thực hiện "thử nghiệm đơn vị" thực tế trên các quy trình được lưu trữ này không?

Cập nhật, 3 năm rưỡi sau. Trong dự án hiện tại của tôi, tôi đã bắt đầu sử dụng các bài kiểm tra đơn vị SSDT, với thành công, mặc dù chúng có thể tốt hơn. Xem Xác minh mã cơ sở dữ liệu bằng cách sử dụng các bài kiểm tra đơn vị SQL Server . Chúng thường triển khai dự án cơ sở dữ liệu tới phiên bản SQL Server LocalDB của bạn, do đó, việc này sẽ xóa mọi câu hỏi về môi trường cơ sở dữ liệu ảnh hưởng đến kiểm tra. Tôi điền vào cơ sở dữ liệu các dữ liệu cần thiết trong Thử nghiệm trước, để loại bỏ các câu hỏi về nội dung cơ sở dữ liệu. Trên thực tế, tôi sử dụng các câu lệnh MERGE để làm điều này, đảm bảo rằng mọi dữ liệu tôi không cần cho bài kiểm tra hiện tại sẽ bị xóa, chèn hoặc cập nhật từ cơ sở dữ liệu trước khi kiểm tra. Họ có vấn đề:

• Họ không nhanh
• Không thể sử dụng lại các điều kiện kiểm tra
• Không thể sử dụng lại các thử nghiệm trước (trừ khi bạn làm cho chúng chung cho tất cả các thử nghiệm trong một dự án)
• Giao diện người dùng có thể được cải thiện

Một trong những lý do cho các vấn đề trên là tôi chưa phàn nàn về chúng. Tôi khuyên mọi người quan tâm nên thử tính năng này và sau đó phàn nàn về nó. Đó là cách cải tiến được thực hiện.

Quan điểm của thử nghiệm đơn vị không phải là để làm cho một phép thử đơn vị ma thuật đến và xác thực ý kiến ​​của bạn. Đó là để kiểm tra các khối xây dựng nhỏ nhất, đơn giản nhất trong hệ thống của bạn, vì vậy bạn không kiểm tra một số chức năng mở rộng hơn và vấp ngã vì một cái gì đó không hoạt động theo cách bạn nghĩ. Vì vậy, bạn có thể phá vỡ điều này hơn nữa? Tôi không nghĩ bạn có thể, trong trường hợp này:

(a) Nghe có vẻ như là một bài kiểm tra đơn vị đối với tôi và (b) Không quan trọng đó có phải là bài kiểm tra đơn vị hay không, bởi vì nó kiểm tra những gì bạn cần kiểm tra, đó là điểm sử dụng bài kiểm tra đơn vị ở nơi đầu tiên!

Nếu bạn cảm thấy các thủ tục quá phức tạp, bạn có thể muốn chia chúng thành các phần nhỏ hơn (trong thủ tục cơ sở dữ liệu hoặc mã), nhưng để làm được điều đó, rõ ràng bạn muốn thực hiện các thử nghiệm này trước tiên!

Kiểm thử đơn vị theo định nghĩa xoay quanh việc kiểm tra "đơn vị" mã trong môi trường hoặc nền tảng đang chạy của nó. Nền tảng bạn sử dụng là một cơ sở dữ liệu để bạn phải sử dụng nó, nó không tích hợp.

Một câu hỏi tốt hơn là tại sao bạn quan tâm. Miễn là nó tự động và thêm giá trị, bạn có quan tâm rằng thử nghiệm của bạn trong thử nghiệm đơn vị, thử nghiệm chấp nhận, thử nghiệm khói hoặc thử nghiệm chức năng không?

Trong công việc của tôi, chúng tôi hiện đang tận dụng khung thử nghiệm đơn vị để thực hiện Phát triển dựa trên thử nghiệm chấp nhận (ATDD). Một số bài kiểm tra là tích hợp, một số thì không. Hầu như không ai trong số họ là bài kiểm tra đơn vị, nhưng chúng tôi không quan tâm miễn là:

• kiểm tra thêm giá trị
• bài kiểm tra không có thất bại hoặc thành công sai (chủ yếu là xác định)
• kiểm tra là tự động

Cập nhật

Đó là tất cả một câu hỏi về chi phí và lợi ích. Càng nhiều bộ phận chuyển động, bạn có nguy cơ có một bài kiểm tra không xác định càng cao. Các thử nghiệm đơn vị cổ điển có số lượng bộ phận chuyển động ít nhất, và do đó ít có khả năng là không xác định. Sự cân bằng là bạn không kiểm tra các điểm tích hợp (mã, cơ sở dữ liệu, fs, mạng, v.v.). Tất cả những điều này là hữu ích để được bảo hiểm trong một thử nghiệm, miễn là nguy cơ thất bại hoặc thành công là đủ thấp.

Các xét nghiệm cung cấp giá trị trong những gì họ không phải là những gì họ đang có. Điều quan trọng là mức độ thường xuyên bạn sẽ có những thất bại và thành công sai lầm. Nếu tôi có lỗi sai trong 2 giờ mỗi tháng vì đó là cửa sổ bảo trì cho mạng, thì giá trị của các thử nghiệm là rõ ràng. Khi họ thất bại, rõ ràng có điều gì đó không ổn với tài nguyên được nối mạng, không phải là một thử nghiệm cụ thể. Và bây giờ bạn có phạm vi kiểm tra chính xác hơn vì bạn đang kiểm tra các điểm tích hợp đó.

Tôi nghĩ rằng nó phụ thuộc vào nơi dữ liệu đến từ. Nếu bạn đang tạo điều kiện kiểm tra của mình trong tiền tố kiểm tra, tôi nghĩ việc gọi nó là kiểm tra đơn vị là hợp lý. Mặt khác, bạn đang tranh luận về sự kén chọn về những gì được coi là "tồn tại trước" cho một bài kiểm tra đơn vị. Giống như các kiểm tra đơn vị cơ sở dữ liệu của bạn dựa trên sự tồn tại của các bảng cơ sở dữ liệu, v.v., các kiểm tra đơn vị bên ngoài cơ sở dữ liệu dựa trên những thứ như định nghĩa lớp và thường là các trường hợp của các cụm. Điều đó không tệ, nó thực tế.

Tôi sẽ coi đó là thử nghiệm tích hợp:

1. Nó chậm hơn nhiều so với một bài kiểm tra đơn vị.
2. Nó không thực hiện một đơn vị mã nguyên tử duy nhất - nó thực hiện thủ tục của bạn, máy chủ cơ sở dữ liệu, ngăn xếp mạng, v.v.
3. Sẽ không dễ dàng phát hiện lỗi xảy ra ở đâu nếu thử nghiệm thất bại. Bạn sẽ phải xem xét từng lỗi một cách thủ công để xem đó là lỗi hệ thống bên ngoài hay mã của bạn.

Tuy nhiên, các bài kiểm tra như bạn mô tả là vô giá để có. Gần đây chúng tôi đã bắt đầu thêm các bài kiểm tra như thế, để kiểm tra các quy trình được lưu trữ không thể kiểm tra thủ công trong một số môi trường nhất định. Tôi không biết một cách khác để có các bài kiểm tra tự động cho các thủ tục được lưu trữ.

Vì vậy, các thử nghiệm này là một ý tưởng tuyệt vời, nhưng gọi chúng là các thử nghiệm tích hợp - sử dụng một loại thử nghiệm hoặc hậu tố tên để phân biệt chúng với các thử nghiệm đơn vị thông thường. Bằng cách này, bạn có thể gắn cờ các lỗi thử nghiệm tích hợp khác với các lỗi thử nghiệm đơn vị trong tự động hóa bản dựng của bạn.

Đây là thử nghiệm tích hợp hoặc thử nghiệm đơn vị?

Trường hợp chạy thử? Trên cơ sở dữ liệu hoặc thông qua khai thác thử nghiệm dựa trên mã (JUnit)?

Trên cơ sở dữ liệu sau đó có khả năng là một thử nghiệm đơn vị (vì nó là độc lập), khai thác thử nghiệm giống như JUnit sau đó nó kết nối với cơ sở dữ liệu bên ngoài và như một thử nghiệm tích hợp.

Nếu đây là thử nghiệm tích hợp "chỉ"

Tại sao báo giá? Kiểm tra tích hợp không phải là một loại quái vật bạn không bao giờ nên làm.

có ai có đề xuất về cách thực hiện "kiểm tra đơn vị" thực tế trên các thủ tục được lưu trữ này không?

Tôi thường tìm thấy đơn vị hợp lý duy nhất cho một thủ tục được lưu trữ là mã gọi và thủ tục. Vì vậy, tôi tích hợp kiểm tra bộ hoàn chỉnh trong một tập hợp các bài kiểm tra trông giống như kiểm tra đơn vị.

Một câu hỏi tốt hơn là tại sao bạn quan tâm [về tên].

Vì nó cho phép bạn tách các bài kiểm tra ra. Kiểm thử tích hợp mất nhiều thời gian hơn để chạy, yêu cầu thiết lập bổ sung và có khả năng truy cập vào tài nguyên được chia sẻ bởi nhiều thử nghiệm (ví dụ: cơ sở dữ liệu).

1) Mã cuộc gọi sẽ có các bài kiểm tra đơn vị bổ sung nếu được yêu cầu.

Microtest là một thuật ngữ hữu ích có thể giúp bạn vượt qua cuộc tranh luận về thuật ngữ và liệu bài kiểm tra của bạn có phải là bài kiểm tra đơn vị hay không.

Một định nghĩa chung về kiểm tra đơn vị bao gồm hệ thống được kiểm tra là một đơn vị chức năng nhỏ và bạn phải có thể chạy tất cả các kiểm tra đối với nó trong bộ nhớ, mà không cần sự trợ giúp từ các hệ thống tệp, mạng hoặc công cụ cơ sở dữ liệu . Nếu bạn cần một công cụ cơ sở dữ liệu thực tế để chạy nó, thì đó không phải là một bài kiểm tra đơn vị.

Mặc dù định nghĩa này hoạt động rất tốt cho tất cả các lớp ứng dụng, nhưng nó không hữu ích cho lớp truy cập cơ sở dữ liệu nội địa. Chúng tôi phải nhận ra rằng nó là đặc biệt. Nếu các thử nghiệm của bạn chỉ kiểm tra các đơn vị nhỏ chức năng lưu trữ / truy xuất / cập nhật / xóa, thì các thử nghiệm của bạn rõ ràng có giá trị như các thử nghiệm đơn vị "nghiêm ngặt" được viết đối với các lớp trên của hệ thống.