Kiểm tra đơn vị cho mã C ++ - Công cụ và phương pháp [đã đóng]

Tôi đang làm việc trên một hệ thống c ++ lớn đã được phát triển vài năm nay. Là một phần trong nỗ lực cải thiện chất lượng của mã hiện tại, chúng tôi đã tham gia vào một dự án tái cấu trúc dài hạn lớn.

Bạn có biết một công cụ tốt có thể giúp tôi viết bài kiểm tra đơn vị trong C ++ không? Có lẽ một cái gì đó tương tự như Junit hoặc Nunit?

Bất cứ ai cũng có thể đưa ra một số lời khuyên tốt về phương pháp viết bài kiểm tra đơn vị cho các mô-đun được viết mà không có bài kiểm tra đơn vị trong tâm trí?

Áp dụng các bài kiểm tra đơn vị cho mã kế thừa là lý do làm việc hiệu quả với Mã kế thừa được viết. Michael Feathers là tác giả - như đã đề cập trong các câu trả lời khác, ông đã tham gia vào việc tạo ra cả CppUnit và CppUnitLite .

Google gần đây đã phát hành thư viện riêng của họ để thử nghiệm đơn vị ứng dụng C ++, được gọi là Google Test.

Dự án trên Google Code

Kiểm tra một so sánh tuyệt vời giữa một số bộ có sẵn. Tác giả của bài báo đó sau đó đã phát triển UnitTest ++ .

Điều tôi đặc biệt thích về nó (ngoài thực tế là nó xử lý các trường hợp ngoại lệ, v.v.) là có một số lượng 'quản trị' rất hạn chế xung quanh các trường hợp kiểm tra và định nghĩa đồ đạc thử nghiệm.

Boost có thư viện Kiểm tra có hỗ trợ kiểm tra đơn vị. Nó có thể là giá trị kiểm tra.

Noel Llopis of Games From Inside là tác giả của Khám phá khung thử nghiệm đơn vị C ++ Jungle , một đánh giá toàn diện (nhưng hiện tại) về các khung thử nghiệm đơn vị C ++ khác nhau, cũng như một cuốn sách về lập trình trò chơi.

Ông đã sử dụng CppUnitLite trong một thời gian dài, sửa chữa nhiều thứ khác nhau, nhưng cuối cùng đã hợp tác với một tác giả thư viện thử nghiệm đơn vị khác và sản xuất UnitTest ++ . Chúng tôi sử dụng UnitTest ++ ở đây và cho đến nay tôi rất thích nó. Nó có (với tôi) sự cân bằng quyền lực chính xác với một dấu chân nhỏ.

Tôi đã sử dụng các giải pháp cây nhà lá vườn, CxxTest (yêu cầu Perl) và boost :: test. Khi tôi triển khai thử nghiệm đơn vị ở đây trong công việc hiện tại của mình, nó đã xuất hiện khá nhiều đến UnitTest ++ vs boost :: test.

Tôi thực sự thích hầu hết các thư viện boost tôi đã sử dụng, nhưng IMHO, boost :: test hơi quá nặng tay. Tôi đặc biệt không thích điều đó đòi hỏi bạn (AFAIK) phải triển khai chương trình chính của khai thác thử nghiệm bằng cách sử dụng macro boost :: test. Tôi biết rằng đó không phải là TDD "thuần túy", nhưng đôi khi chúng ta cần một cách để chạy thử nghiệm từ việc tắt ứng dụng GUI, ví dụ như khi một cờ kiểm tra đặc biệt được truyền vào dòng lệnh và boost :: test không thể hỗ trợ loại này của kịch bản.

UnitTest ++ là khung thử nghiệm đơn giản nhất để thiết lập và sử dụng mà tôi đã gặp trong trải nghiệm (giới hạn) của mình.

Tôi đang sử dụng thư viện Boost.Test tuyệt vời kết hợp với thư viện Rùa ít được biết đến nhưng rất tuyệt vời : thư viện đối tượng giả dựa trên boost.

Như một ví dụ mã nói tốt hơn lời nói, hãy tưởng tượng bạn muốn kiểm tra một calculatorđối tượng hoạt động trên viewgiao diện (đó là ví dụ giới thiệu của Rùa):

// declares a 'mock_view' class implementing 'view'
MOCK_BASE_CLASS( mock_view, view )
{
    // implements the 'display' method from 'view' (taking 1 argument)
    MOCK_METHOD( display, 1 )                   
};

BOOST_AUTO_TEST_CASE( zero_plus_zero_is_zero )
{
    mock_view v;
    calculator c( v );

    // expects the 'display' method to be called once with a parameter value equal to 0
    MOCK_EXPECT( v, display ).once().with( 0 ); 

    c.add( 0, 0 );
}

Xem nó dễ dàng và dài dòng như thế nào khi tuyên bố kỳ vọng vào đối tượng giả? Rõ ràng, thử nghiệm thất bại nếu kỳ vọng không được đáp ứng.

Tôi vừa mới đẩy khuôn khổ của riêng mình, CATCH , ra khỏi đó. Nó vẫn đang được phát triển nhưng tôi tin rằng nó đã vượt qua hầu hết các khung khác. Những người khác nhau có các tiêu chí khác nhau nhưng tôi đã cố gắng bao quát hầu hết các mặt bằng mà không có quá nhiều sự đánh đổi. Hãy xem mục blog được liên kết của tôi cho một người khai thác. Năm tính năng hàng đầu của tôi là:

• Chỉ tiêu đề
• Tự động đăng ký kiểm tra chức năng và phương pháp
• Phân tách các biểu thức C ++ tiêu chuẩn thành LHS và RHS (vì vậy bạn không cần cả gia đình macro xác nhận).
• Hỗ trợ cho các phần lồng nhau trong một vật cố dựa trên chức năng
• Kiểm tra tên bằng ngôn ngữ tự nhiên - tên hàm / phương thức được tạo

Nó cũng có các ràng buộc Objective-C.

CxxTest là một khung công tác JUnit / CppUnit / xUnit giống như nền tảng nhẹ, dễ sử dụng cho C ++.

CppUnit là cách. Xem liên kết dưới đây:

http://cppunit.sourceforge.net/cppunit-wiki

http://en.wikipedia.org/wiki/CppUnit

UnitTest ++ , nhỏ & đơn giản.

Tôi hiện đang tìm kiếm một thử nghiệm đơn vị và khung giả có thể được sử dụng tại công ty chúng tôi cho một cơ sở mã tồn tại lâu dài. Như bạn đã biết danh sách các khung kiểm tra đơn vị cho c ++ dài, vì vậy tôi đã áp dụng một số bộ lọc để giảm nó xuống mức đầy đủ có thể xem xét kỹ hơn. Tiêu chí lọc đầu tiên là nó phải miễn phí. Tiêu chí thứ hai là hoạt động của dự án. Tôi cũng đã tìm kiếm các khung mô phỏng bởi vì bạn cần một khung nếu bạn muốn viết các bài kiểm tra đơn vị.

Tôi đã đưa ra danh sách sau (khoảng) được sắp xếp theo hoạt động, hoạt động cao nhất ở đầu:

• GoogleTest / GoogleMock: Nhiều người đóng góp và được sử dụng bởi chính Google. Điều này có thể sẽ ở đây một thời gian và nhận được cập nhật. Đối với cơ sở mã riêng của tôi, tôi sẽ chuyển sang kết hợp này với hy vọng nhảy lên chuyến tàu nhanh nhất.

• BoostTest + Rùa: Không được cập nhật thường xuyên, nhưng khung thử nghiệm là một phần của boost nên cần được duy trì. Mặt khác, rùa được duy trì chủ yếu bởi một anh chàng, nhưng nó có hoạt động bực bội nên không chết. Tôi đã thực hiện gần như tất cả trải nghiệm thử nghiệm của mình với sự kết hợp này bởi vì chúng tôi đã sử dụng thư viện boost tại công việc trước đây của tôi và tôi hiện đang sử dụng nó cho mã riêng của mình.

• CppUTest: Cung cấp thử nghiệm và chế nhạo. Dự án này đã hoạt động từ năm 2008 đến 2015 và có khá nhiều hoạt động gần đây. Phát hiện này có một chút bất ngờ vì rất nhiều dự án có hoạt động ít hơn đáng kể xuất hiện thường xuyên hơn khi tìm kiếm trên web (như CppUnit đã có bản cập nhật cuối cùng vào năm 2013). Tôi đã không nhìn sâu hơn vào điều này vì vậy tôi không thể nói bất cứ điều gì về các chi tiết. Chỉnh sửa (16.12.2015): Gần đây tôi đã thử nó và thấy khung này hơi vụng về và "C-style", đặc biệt là khi sử dụng các lớp giả. Ngoài ra, nó dường như có một loạt các xác nhận nhỏ hơn các khung khác. Tôi nghĩ rằng sức mạnh chính của nó là nó có thể được sử dụng với các dự án C thuần túy.

• QTest: Thư viện thử nghiệm đi kèm với khung Qt. Bảo trì nên được đảm bảo trong một thời gian, nhưng tôi sử dụng nó như là một thư viện hỗ trợ, vì đăng ký kiểm tra là IMO vụng về hơn sau đó trong các khuôn khổ khác. Theo như tôi hiểu, nó buộc bạn phải có một bài kiểm tra cho mỗi lần kiểm tra. Nhưng các chức năng của trình trợ giúp kiểm tra có thể được sử dụng tốt khi kiểm tra mã Qt-Gui. Nó không có giả.

• Catch: Nó có hoạt động gần đây nhưng chủ yếu được phát triển bởi một anh chàng. Điều hay ho của khung này là cách tiếp cận vật cố thay thế cho phép bạn viết mã lịch thi đấu có thể sử dụng lại trong bản thử nghiệm. Nó cũng cho phép bạn đặt tên kiểm tra dưới dạng chuỗi rất hay khi bạn có xu hướng viết cả câu dưới dạng tên kiểm tra. Tôi muốn phong cách này sẽ được trích xuất và đưa vào googleTest ;-)

Khung giả

Số lượng khung giả lập nhỏ hơn nhiều so với số lượng khung kiểm tra nhưng đây là những khung mà tôi thấy có hoạt động gần đây.

• Hippomock : Hoạt động từ đơn vị 2008 bây giờ nhưng chỉ với cường độ thấp.

• FakeIt : Hoạt động từ đơn vị 2013 ngay bây giờ nhưng ít nhiều được phát triển bởi một anh chàng.

Phần kết luận

Nếu cơ sở mã của bạn hoạt động lâu dài, hãy chọn giữa BoostTest + Rùa và GoogleTest + GoogleMock . Tôi nghĩ rằng hai người sẽ có bảo trì dài hạn. Nếu bạn chỉ có một cơ sở mã tồn tại ngắn, bạn có thể thử Catch có một cú pháp hay. Sau đó, bạn sẽ cần phải chọn thêm một khung mô phỏng. Nếu bạn làm việc với Visual Studio, bạn có thể tải xuống bộ điều hợp chạy thử nghiệm cho BoostTest và GoogleTest, điều đó sẽ cho phép bạn chạy thử nghiệm với GUI của trình chạy thử nghiệm được tích hợp vào VS.

Xem thêm câu trả lời cho câu hỏi liên quan chặt chẽ "chọn công cụ / khung kiểm tra đơn vị c ++", tại đây

Ngoài ra còn có TUT , Mẫu-Đơn vị-Kiểm tra, khung dựa trên mẫu. Cú pháp của nó rất khó xử (một số người gọi nó là lạm dụng mẫu), nhưng ưu điểm chính của nó là tất cả được chứa trong một tệp tiêu đề duy nhất .

Bạn sẽ tìm thấy một ví dụ về bài kiểm tra đơn vị được viết bằng TUT tại đây.

Tôi đã thử CPPunit và nó không thân thiện với người dùng lắm.

Cách thay thế duy nhất tôi biết là sử dụng C ++. NET để bọc các lớp C ++ của bạn và viết các bài kiểm tra đơn vị bằng một trong các khung kiểm tra đơn vị .NET (NUnit, MBUnit, v.v.)

CppUTest là một khung công tác nhẹ, tuyệt vời để thử nghiệm đơn vị C và C ++.

Michael Feathers của ObjectMentor là công cụ phát triển cả CppUnit và CppUnitLite.

Bây giờ ông đề xuất CppUnitLite

Hãy xem CUnitWin32 . Nó được viết cho MS Visual C. Nó bao gồm một ví dụ.

Hãy xem cfix ( http://www.cfix-testing.org ), nó chuyên dùng cho phát triển Windows C / C ++ và hỗ trợ cả chế độ người dùng và kiểm tra đơn vị chế độ kernel.

Nếu bạn đang dùng Visual Studio 2008 SP1, tôi khuyên bạn nên sử dụng MSTest để viết bài kiểm tra đơn vị. Sau đó tôi sử dụng Google giả để viết các bản giả. Việc tích hợp với IDE là lý tưởng và cho phép và không mang chi phí hoạt động của CPPunit về mặt chỉnh sửa ba vị trí để bổ sung một bài kiểm tra.

Tôi nghĩ VisualAssert đang làm rất tốt trong việc tích hợp VS. Nó cho phép bạn chạy và gỡ lỗi các thử nghiệm từ VS và bạn không cần phải tạo một tệp thực thi để chạy thử nghiệm.

Kiểm tra fructose: http://sourceforge.net/projects/fructose/

Đó là một khung rất đơn giản, chỉ chứa các tệp tiêu đề và do đó dễ dàng mang theo.

Tôi đang sử dụng MS Test với typemock Isolator ++ . Hãy thử một lần!