Tất cả các bài kiểm tra đơn vị trong một thực thi, hoặc tách chúng ra?

Khi viết các bài kiểm tra cho một phần mềm, giả sử là một thư viện, bạn có muốn biên dịch tất cả các bài kiểm tra đơn vị thành một hoặc tách chúng thành nhiều phần thi hành không?

Lý do tôi hỏi là vì tôi hiện đang sử dụng CUnit để kiểm tra thư viện tôi đang làm việc. Các thử nghiệm được chia thành các bộ riêng biệt được biên dịch thành một bộ hoàn chỉnh có thể thực hiện được với đầu ra được in cho các lỗi. Bây giờ, xây dựng hệ thống thư viện đó là CMake (trong đó, mặc dù tên của nó, có ít để làm với Cunit), mà đi kèm với khuôn khổ thử nghiệm riêng của mình, CTest . CTest cho phép tôi đăng ký một danh sách các tệp thực thi đóng vai trò kiểm tra.

Tôi đang cân nhắc có nên sử dụng CTest để chạy thử tự động hay không. Tuy nhiên, điều này sẽ yêu cầu tôi tách các bài kiểm tra mà tôi đã viết cho đến nay thành các mục tiêu biên dịch riêng biệt. Mặt khác, tôi thực sự không thể sử dụng một số tính năng nâng cao của CTest, chẳng hạn như kiểm tra chạy có chọn lọc.

Tôi nhận ra đây là câu hỏi về việc sử dụng công cụ nào và cách xử lý cũng như quy ước của họ, nhưng ngoài ra, còn có lý do nào khác để thích một thử nghiệm duy nhất có thể thực thi hơn các công cụ riêng biệt không? Hoặc ngược lại?

Tôi muốn thực hiện các kiểm tra tự động của mình trong các tệp nhị phân riêng lẻ hoặc ít nhất là được nhóm theo nhóm "thuộc về nhau" và sau đó gọi chúng từ một tập lệnh shell đơn giản (trong đó một mã thoát không bằng 0 báo hiệu lỗi và đầu ra trên stderr có thể bị bắt để ghi lại một lời giải thích). Bằng cách này, tôi giữ được sự linh hoạt hoàn toàn trong thử nghiệm - Tôi có thể chạy các thử nghiệm riêng lẻ trực tiếp từ dòng lệnh, tôi có thể tạo tất cả các loại kịch bản ưa thích nếu tôi muốn, tôi có thể sắp xếp lại chúng khi tôi thấy phù hợp mà không cần biên dịch lại bất cứ điều gì, v.v.

Nhưng quan trọng hơn, nó cũng cho phép tôi bao gồm các bài kiểm tra được viết bằng các ngôn ngữ khác nhau hoặc sử dụng các bộ công cụ khác nhau trong cùng một lần chạy. Ví dụ, các bài kiểm tra đơn vị tôi viết rất có thể bằng ngôn ngữ chính của dự án và việc chạy chúng là vấn đề xây dựng và gọi các nhị phân; nhưng tôi cũng muốn kiểm tra cơ sở dữ liệu của mình và tôi có thể muốn cung cấp các tập lệnh SQL trực tiếp cho cơ sở dữ liệu này; Tôi có thể muốn chạy một số công cụ phân tích mã tĩnh trên mã của mình (ngay cả khi đó chỉ là một loại kẻ nói dối). Tôi có thể muốn chạy HTML tĩnh của mình thông qua trình kiểm tra tính hợp lệ. Tôi có thể chạy một greplệnh trên cơ sở mã để kiểm tra các cấu trúc đáng ngờ, vi phạm kiểu mã hóa hoặc từ khóa "cờ đỏ". Khả năng là vô tận - nếu nó có thể được chạy từ dòng lệnh và tuân thủ "trạng thái thoát không có nghĩa là OK", tôi có thể sử dụng nó.

Tôi có xu hướng có một thư viện cho các bài kiểm tra đơn vị của một ứng dụng (hoặc cho một gói thư viện thường được chia sẻ). Trong thư viện đó, tôi cố gắng sao chép hoặc gần đúng các không gian tên của các đối tượng được kiểm tra cho các đồ đạc thử nghiệm (tôi chủ yếu sử dụng NUnit). Điều này đơn giản hóa việc biên dịch, vì trong .NET có một chi phí cố hữu trong việc xây dựng mỗi nhị phân sẽ tăng thời gian xây dựng của một giải pháp 20 dự án so với giải pháp 10 dự án có cùng LỘC. Các tệp nhị phân kiểm tra không được phân phối theo bất kỳ cách nào, do đó, mọi tổ chức kiểm tra thành các tệp nhị phân là để thuận tiện cho bạn và tôi thường thấy rằng YAGNI áp dụng ở đây như mọi nơi.

Bây giờ, tôi thường không có những cân nhắc mà tdammers có; Mã của tôi hầu như chỉ có một ngôn ngữ và bất kỳ thử nghiệm nào liên quan đến chuỗi SQL không phải là thử nghiệm đơn vị (trừ khi bạn đang kiểm tra rằng nhà sản xuất truy vấn trả về chuỗi SQL dự kiến ​​theo các tiêu chí nhất định) và tôi hầu như không bao giờ kiểm tra đơn vị thực tế UI (trong nhiều tình huống đơn giản là không thể). Tôi cũng sử dụng thư viện kiểm thử đơn vị được các công cụ của bên thứ ba chấp nhận tốt như các trình xây dựng bot và trình cắm IDE, và vì vậy mọi lo ngại về việc chạy thử nghiệm riêng lẻ, bộ phần mềm, v.v ... là tối thiểu.