Mã kiểm tra đơn vị C [đóng]

Tôi đã làm việc trên một hệ thống nhúng vào mùa hè này được viết bằng chữ C. Đó là một dự án hiện có mà công ty tôi làm việc đã tiếp quản. Tôi đã trở nên khá quen thuộc với việc viết các bài kiểm tra đơn vị bằng Java bằng JUnit nhưng không biết cách nào là tốt nhất để viết các bài kiểm tra đơn vị cho mã hiện có (cần tái cấu trúc) cũng như mã mới được thêm vào hệ thống.

Có dự án nào ngoài đó làm cho việc kiểm thử đơn vị mã C đơn giản dễ như kiểm tra đơn vị mã Java với JUnit không? Bất kỳ cái nhìn sâu sắc nào sẽ áp dụng cụ thể cho phát triển nhúng (biên dịch chéo sang nền tảng arm-linux) sẽ được đánh giá rất cao.

Một khung kiểm tra đơn vị trong C là Kiểm tra ; một danh sách các khung kiểm tra đơn vị trong C có thể được tìm thấy ở đây và được sao chép dưới đây. Tùy thuộc vào có bao nhiêu chức năng thư viện tiêu chuẩn mà thời gian chạy của bạn có, bạn có thể hoặc không thể sử dụng một trong số đó.

AceUnit

AceUnit (Advanced C và Embedded Unit) tự lập hóa đơn như một khung kiểm tra đơn vị mã C thoải mái. Nó cố gắng bắt chước JUnit 4.x và bao gồm các khả năng giống như phản chiếu. AceUnit có thể được sử dụng trong các môi trường ràng buộc tài nguyên, ví dụ như phát triển phần mềm nhúng và quan trọng là nó chạy tốt trong các môi trường nơi bạn không thể bao gồm một tệp tiêu đề duy nhất và không thể gọi một hàm C tiêu chuẩn duy nhất từ ​​các thư viện ANSI / ISO C. Nó cũng có một cổng Windows. Nó không sử dụng dĩa để bẫy tín hiệu, mặc dù các tác giả đã bày tỏ sự quan tâm đến việc thêm tính năng như vậy. Xem trang chủ AceUnit .

GNU Autounit

Cũng giống như Kiểm tra, bao gồm cả việc chạy thử nghiệm đơn vị trong một không gian địa chỉ riêng biệt (trên thực tế, tác giả ban đầu của Kiểm tra đã mượn ý tưởng từ GNU Autounit). GNU Autounit sử dụng GLib rộng rãi, điều đó có nghĩa là liên kết và những thứ đó cần các tùy chọn đặc biệt, nhưng điều này có thể không phải là vấn đề lớn đối với bạn, đặc biệt nếu bạn đã sử dụng GTK hoặc GLib. Xem trang chủ GNU Autounit .

cUnit

Cũng sử dụng GLib, nhưng không rẽ nhánh để bảo vệ không gian địa chỉ của các bài kiểm tra đơn vị.

CUnit

Tiêu chuẩn C, với các kế hoạch triển khai GUI Win32. Hiện tại không phân nhánh hoặc bảo vệ không gian địa chỉ của các bài kiểm tra đơn vị. Trong giai đoạn đầu phát triển. Xem trang chủ CUnit .

CuTest

Một khung đơn giản chỉ với một tệp .c và một tệp .h mà bạn thả vào cây nguồn của mình. Xem trang chủ CuTest .

CppUnit

Khung thử nghiệm đơn vị hàng đầu cho C ++; bạn cũng có thể sử dụng nó để kiểm tra mã C. Nó ổn định, được phát triển tích cực và có giao diện GUI. Lý do chính không sử dụng CppUnit cho C trước tiên là nó khá lớn và thứ hai bạn phải viết các bài kiểm tra của mình trong C ++, có nghĩa là bạn cần một trình biên dịch C ++. Nếu những điều này nghe có vẻ không đáng lo ngại, thì chắc chắn đáng để xem xét, cùng với các khung thử nghiệm đơn vị C ++ khác. Xem trang chủ CppUnit .

embUnit

embUnit (Embedded Unit) là một khung kiểm tra đơn vị khác cho các hệ thống nhúng. Cái này dường như được thay thế bởi AceUnit. Trang chủ đơn vị nhúng .

MinUnit

Một bộ macro tối thiểu và đó là nó! Vấn đề là chỉ ra cách dễ dàng để kiểm tra mã của bạn. Xem trang chủ MinUnit .

CUnit cho ông Ando

Một triển khai CUnit còn khá mới và dường như vẫn còn trong giai đoạn đầu phát triển. Xem CUnit cho trang chủ của ông Ando .

Danh sách này được cập nhật lần cuối vào tháng 3 năm 2008.

Thêm khung:

CMocka

CMocka là một khung kiểm tra cho C với sự hỗ trợ cho các đối tượng giả. Thật dễ dàng để sử dụng và thiết lập.

Xem trang chủ CMocka .

Tiêu chuẩn

Tiêu chí là khung kiểm tra đơn vị C đa nền tảng hỗ trợ đăng ký kiểm tra tự động, kiểm tra tham số, lý thuyết và có thể xuất ra nhiều định dạng, bao gồm TAP và JUnit XML. Mỗi thử nghiệm được chạy trong quy trình riêng của nó, vì vậy tín hiệu và sự cố có thể được báo cáo hoặc kiểm tra nếu cần.

Xem trang chủ Tiêu chí để biết thêm thông tin.

CTNH

HWUT là một công cụ Kiểm tra đơn vị chung với sự hỗ trợ tuyệt vời cho C. Nó có thể giúp tạo Makefiles, tạo các trường hợp thử nghiệm lớn được mã hóa trong các 'bảng lặp' tối thiểu, đi dọc theo các máy trạng thái, tạo c-C và hơn thế nữa. Cách tiếp cận chung là khá độc đáo: Các phán quyết dựa trên st thiết bị xuất chuẩn tốt / thiết bị xuất chuẩn xấu '. Các chức năng so sánh, mặc dù, là linh hoạt. Vì vậy, bất kỳ loại kịch bản có thể được sử dụng để kiểm tra. Nó có thể được áp dụng cho bất kỳ ngôn ngữ nào có thể tạo ra đầu ra tiêu chuẩn.

Xem trang chủ của HWUT .

CGreen

Một khung kiểm tra đơn vị hiện đại, di động, đa ngôn ngữ cho C và C ++. Nó cung cấp một ký hiệu BDD tùy chọn, một thư viện giả, khả năng chạy nó trong một quy trình duy nhất (để làm cho việc gỡ lỗi dễ dàng hơn). Một người chạy thử nghiệm tự động phát hiện các chức năng kiểm tra có sẵn. Nhưng bạn có thể tạo lập trình của riêng bạn.

Tất cả các tính năng đó (và hơn thế nữa) được giải thích trong hướng dẫn CGreen .

Wikipedia cung cấp một danh sách chi tiết các khung thử nghiệm đơn vị C trong Danh sách các khung thử nghiệm đơn vị: C

Cá nhân tôi thích khung Google Test .

Khó khăn thực sự trong việc kiểm tra mã C là phá vỡ sự phụ thuộc vào các mô-đun bên ngoài để bạn có thể cô lập mã theo đơn vị. Điều này có thể đặc biệt có vấn đề khi bạn đang cố gắng để có được các bài kiểm tra xung quanh mã kế thừa. Trong trường hợp này, tôi thường thấy mình sử dụng trình liên kết để sử dụng các hàm sơ khai trong các bài kiểm tra.

Đây là những gì mọi người đang đề cập đến khi họ nói về " đường nối ". Trong C, tùy chọn duy nhất của bạn thực sự là sử dụng bộ xử lý trước hoặc trình liên kết để giả lập các phụ thuộc của bạn.

Một bộ thử nghiệm điển hình trong một trong các dự án C của tôi có thể trông như thế này:

#include "myimplementationfile.c"
#include <gtest/gtest.h>

// Mock out external dependency on mylogger.o
void Logger_log(...){}

TEST(FactorialTest, Zero) {
    EXPECT_EQ(1, Factorial(0));
}

Lưu ý rằng bạn thực sự bao gồm tệp C chứ không phải tệp tiêu đề . Điều này mang lại lợi thế truy cập cho tất cả các thành viên dữ liệu tĩnh. Ở đây tôi giả định logger của tôi (có thể là trong logger.o và đưa ra một triển khai trống. Điều này có nghĩa là tệp thử nghiệm biên dịch và liên kết độc lập với phần còn lại của cơ sở mã và thực hiện cách ly.

Đối với việc biên dịch mã chéo, để làm việc này, bạn cần các phương tiện tốt trên mục tiêu. Tôi đã thực hiện điều này với cross googletest được biên dịch sang Linux trên kiến ​​trúc PowerPC. Điều này có ý nghĩa bởi vì bạn có một vỏ và os đầy đủ để thu thập kết quả của bạn. Đối với các môi trường ít phong phú hơn (mà tôi phân loại là bất cứ thứ gì không có hệ điều hành đầy đủ), bạn chỉ nên xây dựng và chạy trên máy chủ. Dù sao thì bạn cũng nên làm điều này để có thể chạy thử nghiệm tự động như một phần của bản dựng.

Tôi thấy việc kiểm tra mã C ++ nói chung dễ dàng hơn nhiều do thực tế là mã OO nói chung ít được kết hợp hơn nhiều so với thủ tục (tất nhiên điều này phụ thuộc rất nhiều vào phong cách mã hóa). Ngoài ra, trong C ++, bạn có thể sử dụng các thủ thuật như tiêm phụ thuộc và ghi đè phương thức để đưa các đường nối vào mã được gói gọn.

Michael Feathers có một cuốn sách tuyệt vời về thử nghiệm mã di sản . Trong một chương, anh ấy đề cập đến các kỹ thuật xử lý mã không phải OO mà tôi rất khuyến khích.

Chỉnh sửa : Tôi đã viết một bài đăng trên blog về mã thủ tục kiểm tra đơn vị, với nguồn có sẵn trên GitHub .

Chỉnh sửa : Có một cuốn sách mới được phát hành từ các Lập trình viên thực dụng , đặc biệt đề cập đến mã C thử nghiệm đơn vị mà tôi rất khuyến khích .

Minunit là một khung kiểm tra đơn vị cực kỳ đơn giản. Tôi đang sử dụng nó để kiểm tra mã vi điều khiển c cho avr.

Tôi hiện đang sử dụng khung kiểm tra đơn vị CuTest:

http://cutest.sourceforge.net/

Đó là lý tưởng cho các hệ thống nhúng vì nó rất nhẹ và đơn giản. Tôi không gặp vấn đề gì khi làm cho nó hoạt động trên nền tảng đích cũng như trên máy tính để bàn. Ngoài việc viết bài kiểm tra đơn vị, tất cả những gì cần thiết là:

• một tệp tiêu đề bao gồm bất cứ nơi nào bạn gọi các thói quen CuTest
• một tệp 'C' bổ sung được biên dịch / liên kết vào hình ảnh
• một số mã đơn giản được thêm vào main để thiết lập và gọi các bài kiểm tra đơn vị - Tôi chỉ có điều này trong một hàm main () đặc biệt được biên dịch nếu UNITTEST được xác định trong quá trình xây dựng.

Hệ thống cần hỗ trợ một đống và một số chức năng stdio (mà không phải tất cả các hệ thống nhúng đều có). Nhưng mã này đủ đơn giản để bạn có thể làm việc thay thế cho các yêu cầu đó nếu nền tảng của bạn không có chúng.

Với một số cách sử dụng hợp lý các khối "C" {} bên ngoài, nó cũng hỗ trợ kiểm tra C ++ tốt.

Tôi nói gần giống như ratkok nhưng nếu bạn có một bước ngoặt được nhúng vào các bài kiểm tra đơn vị thì ...

Unity - Khung được khuyến nghị cao để kiểm tra đơn vị mã C.

Các ví dụ trong cuốn sách được đề cập trong chủ đề này TDD cho C được nhúng được viết bằng Unity (và CppUTest).

Bạn cũng có thể muốn xem libtap , khung thử nghiệm C tạo ra Giao thức kiểm tra mọi thứ (TAP) và do đó tích hợp tốt với nhiều công cụ được phát hành cho công nghệ này. Nó chủ yếu được sử dụng trong thế giới ngôn ngữ động, nhưng nó dễ sử dụng và trở nên rất phổ biến.

Một ví dụ:

#include <tap.h>

int main () {
    plan(5);

    ok(3 == 3);
    is("fnord", "eek", "two different strings not that way?");
    ok(3 <= 8732, "%d <= %d", 3, 8732);
    like("fnord", "f(yes|no)r*[a-f]$");
    cmp_ok(3, ">=", 10);

    done_testing();
}

Có một khung kiểm tra đơn vị thanh lịch cho C với sự hỗ trợ cho các đối tượng giả được gọi là cmocka . Nó chỉ yêu cầu thư viện C tiêu chuẩn, hoạt động trên một loạt các nền tảng điện toán (bao gồm cả nhúng) và với các trình biên dịch khác nhau.

Nó cũng có hỗ trợ cho các định dạng đầu ra thông báo khác nhau như Subunit, Test Anything Protocol và jUnit XML báo cáo.

cmocka đã được tạo để hoạt động trên các nền tảng nhúng và cũng có hỗ trợ Windows.

Một thử nghiệm đơn giản trông như thế này:

#include <stdarg.h>
#include <stddef.h>
#include <setjmp.h>
#include <cmocka.h>

/* A test case that does nothing and succeeds. */
static void null_test_success(void **state) {
    (void) state; /* unused */
}

int main(void) {
    const struct CMUnitTest tests[] = {
        cmocka_unit_test(null_test_success),
    };
    return cmocka_run_group_tests(tests, NULL, NULL);
}

Các API được ghi chép đầy đủ và một số ví dụ là một phần của mã nguồn.

Để bắt đầu với cmocka, bạn nên đọc bài viết trên LWN.net: Kiểm tra đơn vị với các đối tượng giả trong C

cmocka 1.0 đã được phát hành vào tháng 2 năm 2015.

Tôi đã không kiểm tra được một ứng dụng C cũ trước khi tôi bắt đầu tìm cách giả định các chức năng. Tôi rất cần phải giả lập để cô lập tệp C mà tôi muốn kiểm tra từ những người khác. Tôi đã thử cmock và tôi nghĩ rằng tôi sẽ chấp nhận nó.

Cmock quét các tệp tiêu đề và tạo các hàm giả dựa trên các nguyên mẫu mà nó tìm thấy. Mocks sẽ cho phép bạn kiểm tra tệp C trong sự cô lập hoàn hảo. Tất cả bạn sẽ phải làm là liên kết tệp thử nghiệm của bạn với giả thay vì các tệp đối tượng thực sự của bạn.

Một ưu điểm khác của cmock là nó sẽ xác nhận các tham số được truyền cho các hàm được mô phỏng và nó sẽ cho phép bạn chỉ định giá trị trả về nào mà các giả sẽ cung cấp. Điều này rất hữu ích để kiểm tra các luồng thực thi khác nhau trong các chức năng của bạn.

Các thử nghiệm bao gồm các hàm testA (), testB () điển hình trong đó bạn xây dựng các kỳ vọng, các hàm gọi để kiểm tra và kiểm tra các xác nhận.

Bước cuối cùng là tạo ra một người chạy cho các bài kiểm tra của bạn với sự thống nhất. Cmock được gắn với khung kiểm tra thống nhất. Unity dễ học như bất kỳ khung kiểm tra đơn vị nào khác.

Rất đáng để thử và khá dễ nắm bắt:

http://sourceforge.net/apps/trac/cmock/wiki

Cập nhật 1

Một khung khác tôi đang điều tra là Cmockery.

http://code.google.com.vn/p/cmockery/

Nó là một khung C thuần túy hỗ trợ thử nghiệm đơn vị và chế nhạo. Nó không phụ thuộc vào ruby ​​(trái với Cmock) và nó có rất ít sự phụ thuộc vào libs bên ngoài.

Nó đòi hỏi một chút công việc thủ công hơn để thiết lập các bản giả vì nó không tạo mã. Điều đó không đại diện cho nhiều công việc cho một dự án hiện tại vì các nguyên mẫu sẽ không thay đổi nhiều: một khi bạn có giả, bạn sẽ không cần thay đổi chúng trong một thời gian (đây là trường hợp của tôi). Gõ thêm cung cấp kiểm soát hoàn toàn của giả. Nếu có điều gì đó bạn không thích, bạn chỉ cần thay đổi bản giả của mình.

Không cần một người chạy thử đặc biệt. Bạn chỉ cần tạo một mảng các bài kiểm tra và chuyển nó đến một hàm run_tests. Thêm một chút công việc thủ công ở đây nữa nhưng tôi chắc chắn thích ý tưởng về một khung tự trị khép kín.

Thêm vào đó, nó chứa một số thủ thuật C tiện lợi mà tôi không biết.

Nhìn chung, Cmockery cần thêm một chút hiểu biết về giả để bắt đầu. Ví dụ sẽ giúp bạn vượt qua điều này. Có vẻ như nó có thể thực hiện công việc với cơ chế đơn giản hơn.

Là một người mới sử dụng C, tôi thấy các slide được gọi là phát triển theo hướng Test trong C rất hữu ích. Về cơ bản, nó sử dụng tiêu chuẩn assert()cùng với &&việc truyền tải một thông điệp mà không có bất kỳ sự phụ thuộc bên ngoài nào. Nếu ai đó đã quen với khung kiểm tra ngăn xếp đầy đủ, điều này có thể sẽ không xảy ra :)

Chúng tôi đã viết CHEAT (được lưu trữ trên GitHub ) để dễ sử dụng và tính di động.

Nó không có phụ thuộc và không yêu cầu cài đặt hoặc cấu hình. Chỉ cần một tệp tiêu đề và một trường hợp thử nghiệm là cần thiết.

#include <cheat.h>

CHEAT_TEST(mathematics_still_work,
    cheat_assert(2 + 2 == 4);
    cheat_assert_not(2 + 2 == 5);
)

Các thử nghiệm biên dịch thành một tệp thực thi, đảm nhiệm việc chạy các thử nghiệm và báo cáo kết quả của chúng.

$ gcc -I . tests.c
$ ./a.out
..
---
2 successful of 2 run
SUCCESS

Nó cũng có màu sắc đẹp.

Có CUnit

Và Embedded Unit là khung thử nghiệm đơn vị cho Hệ thống nhúng C. Thiết kế của nó đã được sao chép từ JUnit và CUnit và hơn thế nữa, sau đó được điều chỉnh phần nào cho Hệ thống nhúng C. Đơn vị nhúng không yêu cầu lib lib std. Tất cả các đối tượng được phân bổ cho khu vực const.

Và Tessy tự động hóa việc kiểm tra đơn vị phần mềm nhúng.

Tôi không sử dụng khung, tôi chỉ sử dụng hỗ trợ mục tiêu "kiểm tra" tự động. Thực hiện một "chính" và sử dụng khẳng định.

Bài kiểm tra của tôi Makefile.am (s) trông giống như:

check_PROGRAMS = test_oe_amqp

test_oe_amqp_SOURCES = test_oe_amqp.c
test_oe_amqp_LDADD = -L$(top_builddir)/components/common -loecommon
test_oe_amqp_CFLAGS = -I$(top_srcdir)/components/common -static

TESTS = test_oe_amqp

Cuốn sách "Làm việc hiệu quả với Bộ luật kế thừa" của Michael Feather trình bày rất nhiều kỹ thuật dành riêng cho thử nghiệm đơn vị trong quá trình phát triển C.

Có những kỹ thuật liên quan đến tiêm phụ thuộc dành riêng cho C mà tôi chưa thấy ở bất kỳ nơi nào khác.

CppUTest - Khung được khuyến nghị cao để kiểm tra mã C đơn vị.

Các ví dụ trong cuốn sách được đề cập trong chủ đề này TDD cho C được nhúng được viết bằng CppUTest.

Tôi sử dụng CxxTest cho môi trường c / c ++ nhúng (chủ yếu là C ++).

Tôi thích CxxTest hơn vì nó có tập lệnh perl / python để xây dựng trình chạy thử. Sau một độ dốc nhỏ để thiết lập nó (vẫn nhỏ hơn vì bạn không phải viết trình chạy thử), nó khá dễ sử dụng (bao gồm các mẫu và tài liệu hữu ích). Công việc quan trọng nhất là thiết lập 'phần cứng' mã truy cập để tôi có thể kiểm tra đơn vị / mô-đun một cách hiệu quả. Sau đó, thật dễ dàng để thêm các trường hợp thử nghiệm đơn vị mới.

Như đã đề cập trước đây, nó là một khung kiểm tra đơn vị C / C ++. Vì vậy, bạn sẽ cần một trình biên dịch C ++.

Hướng dẫn sử dụng CxxTest Wiki CxxTest

khác với sự thiên vị rõ ràng của tôi

http://code.google.com.vn/p/seatest/

là một cách đơn giản để kiểm tra mã C đơn vị. bắt chước xUnit

Sau khi đọc Minunit, tôi nghĩ rằng một cách tốt hơn là dựa trên thử nghiệm trong macro khẳng định mà tôi sử dụng rất nhiều như kỹ thuật chương trình phòng thủ. Vì vậy, tôi đã sử dụng cùng một ý tưởng về Minunit trộn với khẳng định tiêu chuẩn. Bạn có thể thấy khuôn khổ của tôi (một tên hay có thể là NoMinunit) trong blog của k0ga

cmockery tại http://code.google.com.vn/p/cmockery/

Google có khung thử nghiệm tuyệt vời. https://github.com/google/googletest/blob/master/googletest/docs/primer.md

Và vâng, theo như tôi thấy thì nó sẽ hoạt động với C đơn giản, tức là không yêu cầu các tính năng C ++ (có thể không cần trình biên dịch C ++, không chắc chắn).

Cmockery là một dự án được ra mắt gần đây bao gồm một thư viện C rất đơn giản để sử dụng để viết bài kiểm tra đơn vị.

Đầu tiên, xem tại đây: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C

Công ty tôi có một thư viện C khách hàng của chúng tôi sử dụng. Chúng tôi sử dụng CxxTest (thư viện kiểm tra đơn vị C ++) để kiểm tra mã. CppUnit cũng sẽ hoạt động. Nếu bạn bị kẹt trong C, tôi khuyên dùng RCUNIT (nhưng CUnit cũng tốt).

Nếu bạn quen thuộc với JUnit thì tôi khuyên dùng CppUnit. http://cppunit.sourceforge.net/cppunit-wiki

Đó là giả sử bạn có trình biên dịch c ++ để thực hiện các bài kiểm tra đơn vị. nếu không thì tôi phải đồng ý với Adam Rosenfield rằng kiểm tra là những gì bạn muốn.

Tôi đã sử dụng RCUNIT để thực hiện một số thử nghiệm đơn vị cho mã nhúng trên PC trước khi thử nghiệm trên mục tiêu. Sự trừu tượng hóa giao diện phần cứng tốt là điều quan trọng khác về tuổi thọ và các thanh ghi ánh xạ bộ nhớ sẽ giết chết bạn.

hãy thử - http://code.google.com.vn/p/lcut

API Sanity Checker - khung kiểm tra cho các thư viện C / C ++:

Trình tạo tự động các bài kiểm tra đơn vị cơ bản cho thư viện C / C ++ được chia sẻ. Nó có thể tạo dữ liệu đầu vào hợp lý (trong hầu hết, nhưng không may là tất cả các trường hợp) cho các tham số và soạn các trường hợp kiểm tra đơn giản ("sanity" hoặc "nông") cho mọi chức năng trong API thông qua phân tích khai báo trong tiêu đề các tập tin.

Chất lượng của các thử nghiệm được tạo cho phép kiểm tra không có lỗi nghiêm trọng trong các trường hợp sử dụng đơn giản. Công cụ này có thể xây dựng và thực hiện các thử nghiệm được tạo và phát hiện sự cố (segfaults), hủy bỏ, tất cả các loại tín hiệu phát ra, mã trả về chương trình khác không và treo chương trình.

Ví dụ:

• Bộ kiểm tra cho fontconfig 2.8.0
• Bộ kiểm tra cho FreeType 2.4.8

Một kỹ thuật để sử dụng là phát triển mã kiểm tra đơn vị với khung C ++ xUnit (và trình biên dịch C ++), trong khi duy trì nguồn cho hệ thống đích dưới dạng các mô đun C.

Hãy chắc chắn rằng bạn thường xuyên biên dịch nguồn C của mình dưới trình biên dịch chéo, tự động với các bài kiểm tra đơn vị của bạn nếu có thể.

LibU ( http://koanlogic.com/libu ) có một mô-đun thử nghiệm đơn vị cho phép kiểm tra rõ ràng bộ / trường hợp phụ thuộc, cách ly kiểm tra, thực hiện song song và một định dạng báo cáo tùy biến (định dạng mặc định là xml và txt).

Thư viện được cấp phép BSD và chứa nhiều mô-đun hữu ích khác - kết nối mạng, gỡ lỗi, cấu trúc dữ liệu thường được sử dụng, cấu hình, v.v. - nếu bạn cần chúng trong các dự án của mình ...

Tôi ngạc nhiên khi không ai nhắc đến Cutter (http://cutter.sourceforge.net/) Bạn có thể kiểm tra C và C ++, nó tích hợp liền mạch với autotools và có sẵn một hướng dẫn rất hay.

Trong trường hợp bạn đang nhắm mục tiêu nền tảng Win32 hoặc chế độ nhân NT, bạn nên xem qua mã .

Nếu bạn vẫn đang săn lùng các khung kiểm tra, CUnitWin32 là một cho nền tảng Win32 / NT.

Điều này giải quyết một vấn đề cơ bản mà tôi gặp phải với các khung thử nghiệm khác. Cụ thể là các biến toàn cục / tĩnh ở trạng thái xác định vì mỗi thử nghiệm được thực hiện như một quy trình riêng biệt.