وحدة اختبار كود C [مغلق]
https://stackoverflow.com/questions/65820
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
لقد عملت على نظام مضمن هذا الصيف مكتوبًا بلغة C المستقيمة.لقد كان مشروعًا قائمًا استحوذت عليه الشركة التي أعمل بها.لقد اعتدت تمامًا على كتابة اختبارات الوحدة في Java باستخدام JUnit ولكني كنت في حيرة من أمري بشأن أفضل طريقة لكتابة اختبارات الوحدة للتعليمات البرمجية الموجودة (والتي تحتاج إلى إعادة البناء) بالإضافة إلى التعليمات البرمجية الجديدة المضافة إلى النظام.
هل هناك أي طريقة لجعل اختبار الوحدة لرمز C العادي أمرًا سهلاً مثل اختبار الوحدة لكود Java، على سبيل المثال، JUnit؟أي فكرة من شأنها أن تنطبق بشكل خاص على التطوير المضمن (التجميع المتداخل لمنصة Arm-linux) ستكون موضع تقدير كبير.
المحلول
إطار اختبار وحدة واحدة في C هو يفحص;يمكن العثور على قائمة بأطر اختبار الوحدة في لغة C هنا ويرد أدناه.اعتمادًا على عدد وظائف المكتبة القياسية في وقت التشغيل لديك، قد تتمكن أو لا تتمكن من استخدام واحدة منها.
وحدة الآس
تعتبر AceUnit (وحدة C المتقدمة والمضمنة) نفسها بمثابة إطار عمل مريح لاختبار وحدة كود C.يحاول تقليد JUnit 4.x ويتضمن إمكانات تشبه الانعكاس.يمكن استخدام AceUnit في البيئات ذات الموارد المحدودة، على سبيل المثال.تطوير البرامج المضمنة، والأهم من ذلك أنه يعمل بشكل جيد في البيئات التي لا يمكنك فيها تضمين ملف رأس قياسي واحد ولا يمكنك استدعاء وظيفة C قياسية واحدة من مكتبات ANSI / ISO C.كما أن لديها منفذ ويندوز.وهي لا تستخدم الشوكات لاحتجاز الإشارات، على الرغم من أن المؤلفين أبدوا اهتمامًا بإضافة مثل هذه الميزة.انظر الصفحة الرئيسية لوحدة الآس.
وحدة جنو التلقائية
يشبه إلى حد كبير نفس خطوط Check، بما في ذلك التفرع لتشغيل اختبارات الوحدة في مساحة عنوان منفصلة (في الواقع، استعار المؤلف الأصلي لـ Check الفكرة من GNU Autounit).تستخدم GNU Autounit GLib على نطاق واسع، مما يعني أن الارتباط وما شابه ذلك يحتاج إلى خيارات خاصة، لكن هذا قد لا يمثل مشكلة كبيرة بالنسبة لك، خاصة إذا كنت تستخدم GTK أو GLib بالفعل.انظر الصفحة الرئيسية لوحدة GNU.
cUnit
يستخدم أيضًا GLib، لكنه لا يتفرع لحماية مساحة العنوان لاختبارات الوحدة.
وحدة
Standard C، مع خطط لتطبيق Win32 GUI.لا يعمل حاليًا على تفرع أو حماية مساحة عنوان اختبارات الوحدة.في التطور المبكر.انظر الصفحة الرئيسية لـCUnit.
CuTest
إطار عمل بسيط يحتوي على ملف .c وملف .h واحد فقط تقوم بإسقاطهما في شجرة المصدر الخاصة بك.انظر الصفحة الرئيسية لبرنامج CuTest.
وحدة المعالجة المركزية
إطار اختبار الوحدة الرئيسي لـ C++؛يمكنك أيضًا استخدامه لاختبار كود C.إنه مستقر ومطور بشكل نشط ويحتوي على واجهة المستخدم الرسومية.الأسباب الرئيسية لعدم استخدام CppUnit لـ C هي أولاً أنها كبيرة جدًا، وثانيًا عليك كتابة اختباراتك بلغة C++، مما يعني أنك بحاجة إلى مترجم C++.إذا لم تكن هذه مخاوف، فمن المؤكد أنها تستحق النظر فيها، جنبًا إلى جنب مع أطر اختبار وحدة C++ الأخرى.انظر الصفحة الرئيسية لـ CppUnit.
embUnit
embUnit (الوحدة المضمنة) هو إطار اختبار وحدة آخر للأنظمة المدمجة.يبدو أن هذا قد تم استبداله بـ AceUnit. الصفحة الرئيسية للوحدة المدمجة.
MinUnit
مجموعة صغيرة من وحدات الماكرو وهذا كل شيء!الهدف هو إظهار مدى سهولة وحدة اختبار التعليمات البرمجية الخاصة بك.انظر الصفحة الرئيسية لـ MinUnit.
وحدة CU للسيد.أندو
تطبيق CUnit جديد إلى حد ما، ويبدو أنه لا يزال في مرحلة التطوير المبكرة.انظر وحدة CU للسيد.الصفحة الرئيسية لأندو.
تم آخر تحديث لهذه القائمة في مارس 2008.
المزيد من الأطر:
كموكا
CMocka هو إطار اختبار للغة C مع دعم للكائنات الوهمية.إنه سهل الاستخدام والإعداد.
معيار
Criterion عبارة عن إطار عمل اختبار وحدة C عبر الأنظمة الأساسية يدعم تسجيل الاختبار التلقائي، والاختبارات ذات المعلمات، والنظريات، والتي يمكن إخراجها إلى تنسيقات متعددة، بما في ذلك TAP وJUnit XML.يتم تشغيل كل اختبار في عمليته الخاصة، لذلك يمكن الإبلاغ عن الإشارات والأعطال أو اختبارها إذا لزم الأمر.
انظر الصفحة الرئيسية للمعيار للمزيد من المعلومات.
هووت
HWUT هي أداة اختبار وحدة عامة مع دعم كبير لـ C.يمكن أن يساعد في إنشاء ملفات Makefiles، وإنشاء حالات اختبار ضخمة مشفرة في الحد الأدنى من "جداول التكرار"، والسير على طول أجهزة الحالة، وإنشاء بذرة C والمزيد.النهج العام فريد جدًا:تستند الأحكام على "stdout جيد / stdout سيئ".ومع ذلك، فإن وظيفة المقارنة مرنة.وبالتالي، يمكن استخدام أي نوع من البرامج النصية للتحقق.يمكن تطبيقه على أي لغة يمكنها إنتاج مخرجات قياسية.
جأخضر
إطار عمل حديث ومحمول ومتعدد اللغات لاختبار الوحدات ومحاكاة لغة C وC++.وهو يوفر تدوين BDD اختياريًا، ومكتبة ساخرة، وإمكانية تشغيله في عملية واحدة (لتسهيل تصحيح الأخطاء).يتوفر عداء اختبار يكتشف وظائف الاختبار تلقائيًا.ولكن يمكنك إنشاء بنفسك برمجيا.
تم شرح كل هذه الميزات (والمزيد) في دليل سي جرين.
تقدم ويكيبيديا قائمة مفصلة بأطر اختبار وحدة C ضمن قائمة أطر اختبار الوحدة:ج
نصائح أخرى
شخصيا أحب إطار اختبار جوجل.
تكمن الصعوبة الحقيقية في اختبار كود C في كسر التبعيات على الوحدات الخارجية حتى تتمكن من عزل الكود في الوحدات.قد يكون هذا مشكلة بشكل خاص عندما تحاول إجراء اختبارات حول التعليمات البرمجية القديمة.في هذه الحالة غالبًا ما أجد نفسي أستخدم الرابط لاستخدام وظائف بذرة في الاختبارات.
وهذا ما يشير إليه الناس عندما يتحدثون عن "طبقات".في لغة C، خيارك الوحيد هو استخدام المعالج المسبق أو الرابط للتخلص من تبعياتك.
قد تبدو مجموعة الاختبار النموذجية في أحد مشاريعي في لغة C كما يلي:
#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));
}
لاحظ أنك تقوم بالفعل بتضمين ملف C وليس ملف الرأس.وهذا يعطي ميزة الوصول إلى جميع أعضاء البيانات الثابتة.أنا هنا أسخر من المسجل الخاص بي (والذي قد يكون موجودًا في logger.o وأعطي تطبيقًا فارغًا.وهذا يعني أن ملف الاختبار يتم تجميعه وربطه بشكل مستقل عن بقية قاعدة التعليمات البرمجية ويتم تنفيذه بشكل منفصل.
أما بالنسبة للتجميع المتبادل للكود، لكي ينجح هذا، فأنت بحاجة إلى تسهيلات جيدة على الهدف.لقد قمت بذلك باستخدام googletest cross المترجم إلى Linux على بنية PowerPC.وهذا أمر منطقي لأنه يوجد لديك نظام تشغيل كامل ونظام تشغيل لجمع النتائج.بالنسبة للبيئات الأقل ثراءً (والتي أصنفها على أنها أي شيء لا يحتوي على نظام تشغيل كامل)، يجب عليك فقط البناء والتشغيل على المضيف.يجب عليك القيام بذلك على أي حال حتى تتمكن من تشغيل الاختبارات تلقائيًا كجزء من عملية الإنشاء.
أجد أن اختبار كود C++ أسهل بكثير بشكل عام نظرًا لحقيقة أن كود OO بشكل عام أقل اقترانًا بكثير من الإجرائي (بالطبع هذا يعتمد كثيرًا على أسلوب الترميز).يمكنك أيضًا في لغة C++ استخدام حيل مثل حقن التبعية وتجاوز الطريقة للحصول على طبقات في التعليمات البرمجية التي يتم تغليفها بطريقة أخرى.
مايكل فيذرز لديه كتاب ممتاز عن اختبار الكود القديم.يغطي في أحد الفصول تقنيات التعامل مع التعليمات البرمجية غير التابعة لـ OO والتي أوصي بها بشدة.
يحرر:لقد كتبت أ مشاركة مدونة حول وحدة اختبار التعليمات البرمجية الإجرائية، مع المصدر متاح على جيثب.
يحرر:هناك كتاب جديد يخرج من المبرمجين البراغماتيين الذي يتناول على وجه التحديد رمز C الذي يختبر الوحدة أنصح بشدة.
وحدة صغيرة هو إطار اختبار وحدة بسيط بشكل لا يصدق.أنا أستخدمه لوحدة اختبار رمز وحدة التحكم الدقيقة لـ avr.
أستخدم حاليًا إطار عمل اختبار وحدة CuTest:
http://cutest.sourceforge.net/
إنها مثالية للأنظمة المدمجة لأنها خفيفة الوزن وبسيطة للغاية.لم أواجه أي مشكلة في تشغيله على النظام الأساسي المستهدف وكذلك على سطح المكتب.بالإضافة إلى كتابة اختبارات الوحدة، كل ما هو مطلوب هو:
- تم تضمين ملف رأس أينما كنت تتصل بأفضل الروتين
- يتم تجميع ملف "C" إضافي واحد ليتم تجميعه/ربطه بالصورة
- تم إضافة بعض التعليمات البرمجية البسيطة إلى MAIN لإعداد اختبارات الوحدة والاتصال بها - لدي هذا في وظيفة رئيسية خاصة () يتم تجميعها إذا تم تعريف غير محدد أثناء البناء.
يحتاج النظام إلى دعم الكومة وبعض وظائف stdio (التي لا تتوفر في جميع الأنظمة المدمجة).لكن الكود بسيط بما يكفي بحيث يمكنك على الأرجح العمل على بدائل لتلك المتطلبات إذا لم يكن نظامك الأساسي مزودًا بها.
مع بعض الاستخدام الحكيم للكتل "C"{} الخارجية، فإنه يدعم أيضًا اختبار C++ جيدًا.
أقول تقريبًا نفس راتكوك ولكن إذا كان لديك تطور مضمن في اختبارات الوحدة ثم ...
وحدة - إطار موصى به للغاية لاختبار الوحدة كود C.
الأمثلة الموجودة في الكتاب المذكور في هذا الموضوع TDD لـ C المضمن مكتوبة باستخدام الوحدة (و CppUTest).
قد ترغب أيضًا في إلقاء نظرة على libtap, ، إطار اختبار C الذي ينتج بروتوكول اختبار أي شيء (TAP) وبالتالي يتكامل بشكل جيد مع مجموعة متنوعة من الأدوات التي تظهر لهذه التكنولوجيا.يتم استخدامه غالبًا في عالم اللغات الديناميكي، ولكنه سهل الاستخدام ويحظى بشعبية كبيرة.
مثال:
#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 مع دعم للكائنات الوهمية التي تسمى com.cmocka.فهو يتطلب فقط مكتبة C القياسية، ويعمل على مجموعة من منصات الحوسبة (بما في ذلك المضمنة) ومع مترجمات مختلفة.
كما أن لديها دعمًا لتنسيقات إخراج الرسائل المختلفة مثل الوحدة الفرعية واختبار أي شيء بروتوكول وتقارير jUnit XML.
تم إنشاء cmocka للعمل أيضًا على الأنظمة الأساسية المضمنة ويحظى أيضًا بدعم Windows.
اختبار بسيط يبدو مثل هذا:
#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);
}
ال واجهة برمجة التطبيقات تم توثيقه بالكامل والعديد من الأمثلة هي جزء من الكود المصدري.
للبدء باستخدام cmocka، يجب عليك قراءة المقالة على LWN.net: اختبار الوحدة باستخدام كائنات وهمية في لغة C
تم إصدار cmocka 1.0 في فبراير 2015.
لم أتمكن من اختبار تطبيق C القديم قبل أن أبدأ في البحث عن طريقة للسخرية من الوظائف.كنت بحاجة ماسة إلى نماذج وهمية لعزل ملف C الذي أريد اختباره عن الآخرين.لقد قمت بتجربة cmock وأعتقد أنني سأعتمده.
يقوم Cmock بمسح ملفات الرأس وإنشاء وظائف وهمية بناءً على النماذج الأولية التي يجدها.سوف تسمح لك Mocks باختبار ملف C في عزلة تامة.كل ما عليك فعله هو ربط ملف الاختبار الخاص بك بملفات وهمية بدلاً من ملفات الكائنات الحقيقية.
ميزة أخرى لـ cmock هي أنها ستتحقق من صحة المعلمات التي تم تمريرها إلى الوظائف التي تم الاستهزاء بها، وسوف تتيح لك تحديد قيمة الإرجاع التي يجب أن توفرها النماذج.يعد هذا مفيدًا جدًا لاختبار تدفقات التنفيذ المختلفة في وظائفك.
تتكون الاختبارات من وظائف testA() وtestB() النموذجية التي تقوم من خلالها ببناء التوقعات واستدعاء الوظائف للاختبار والتحقق من التأكيدات.
الخطوة الأخيرة هي إنشاء عداء لاختباراتك بالوحدة.يرتبط Cmock بإطار اختبار الوحدة.الوحدة سهلة التعلم مثل أي إطار عمل آخر لاختبار الوحدة.
تستحق المحاولة وسهلة الفهم:
http://sourceforge.net/apps/trac/cmock/wiki
تحديث 1
إطار عمل آخر أقوم بالتحقيق فيه هو Cmockery.
http://code.google.com/p/cmockery/
إنه إطار C خالص يدعم اختبار الوحدة والسخرية.لا يعتمد على روبي (على عكس Cmock) ولا يعتمد كثيرًا على libs الخارجية.
يتطلب الأمر المزيد من العمل اليدوي لإعداد النماذج لأنه لا يقوم بإنشاء تعليمات برمجية.لا يمثل هذا الكثير من العمل لمشروع حالي نظرًا لأن النماذج الأولية لن تتغير كثيرًا:بمجرد حصولك على نماذجك، لن تحتاج إلى تغييرها لفترة من الوقت (هذه هي حالتي).توفر الكتابة الإضافية تحكمًا كاملاً في المحاكاة.إذا كان هناك شيء لا يعجبك، فما عليك سوى تغيير صورتك.
لا حاجة لعداء اختبار خاص.ما عليك سوى إنشاء مجموعة من الاختبارات وتمريرها إلى وظيفة run_tests.المزيد من العمل اليدوي هنا أيضًا ولكني بالتأكيد أحب فكرة وجود إطار عمل مستقل قائم بذاته.
بالإضافة إلى أنه يحتوي على بعض حيل C الرائعة التي لم أكن أعرفها.
بشكل عام، يحتاج Cmockery إلى مزيد من الفهم للنماذج للبدء.يجب أن تساعدك الأمثلة في التغلب على هذا.يبدو أنه يمكنه القيام بالمهمة باستخدام آليات أبسط.
باعتباري مبتدئًا في لغة C، وجدت أن الشرائح تسمى التطوير القائم على الاختبار في C مفيد جدا.في الأساس، فإنه يستخدم المعيار assert() معا مع && لتسليم رسالة، دون أي تبعيات خارجية.إذا كان شخص ما معتادًا على إطار عمل اختبار المكدس الكامل، فمن المحتمل ألا يكون هذا كافيًا :)
هنالك وحدة
و الوحدة المدمجة هو إطار اختبار الوحدة لنظام C المضمن.تم نسخ تصميمه من JUnit وCUnit والمزيد، ثم تم تكييفه إلى حد ما مع نظام C المضمن.لا تتطلب الوحدة المضمنة مكتبة STD C.يتم تخصيص كافة الكائنات إلى منطقة const.
و تيسي أتمتة اختبار وحدة البرامج المدمجة.
لا أستخدم إطار عمل، بل أستخدم فقط الأدوات التلقائية "للتحقق" من دعم الهدف.قم بتنفيذ "رئيسي" واستخدم التأكيد (التأكيدات).
يبدو الاختبار الخاص بي Makefile.am(s) كما يلي:
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
كتبنا يغش (استضافت على جيثب) لسهولة الاستخدام وقابلية النقل.
ليس له أي تبعيات ولا يتطلب أي تثبيت أو تكوين.هناك حاجة فقط إلى ملف رأس وحالة اختبار.
#include <cheat.h>
CHEAT_TEST(mathematics_still_work,
cheat_assert(2 + 2 == 4);
cheat_assert_not(2 + 2 == 5);
)
يتم تجميع الاختبارات في ملف قابل للتنفيذ يعتني بتشغيل الاختبارات والإبلاغ عن نتائجها.
$ gcc -I . tests.c
$ ./a.out
..
---
2 successful of 2 run
SUCCESS
ولها ألوان جميلة أيضا.
يقدم كتاب مايكل فيذر "العمل بفعالية مع الكود القديم" الكثير من التقنيات الخاصة باختبار الوحدة أثناء تطوير لغة C.
هناك تقنيات تتعلق بحقن التبعية خاصة بلغة C والتي لم أرها في أي مكان آخر.
CppUTest - إطار موصى به للغاية لاختبار الوحدة كود C.
الأمثلة الموجودة في الكتاب المذكور في هذا الموضوع TDD لـ C المضمن تتم كتابتها باستخدام CppUTest.
أنا أستعمل com.CxxTest لبيئة c/c++ المضمنة (C++ في المقام الأول).
أفضّل CxxTest لأنه يحتوي على برنامج نصي Perl/python لإنشاء مشغل الاختبار.بعد منحدر صغير لإعداده (أصغر من ذلك لأنك لا تحتاج إلى كتابة مشغل الاختبار)، فهو سهل الاستخدام جدًا (يتضمن عينات ووثائق مفيدة).كان معظم العمل هو إعداد "الأجهزة" التي يصل إليها الكود حتى أتمكن من اختبار الوحدة/الوحدة بشكل فعال.بعد ذلك يصبح من السهل إضافة حالات اختبار وحدة جديدة.
كما ذكرنا سابقًا، فهو إطار اختبار وحدة C/C++.لذلك سوف تحتاج إلى مترجم C++.
بخلاف تحيزي الواضح
http://code.google.com/p/seatest/
هي طريقة بسيطة وجميلة لاختبار وحدة كود C.يحاكي xUnit
بعد قراءة Minunit، اعتقدت أن الطريقة الأفضل هي إجراء الاختبار في تأكيد الماكرو الذي أستخدمه كثيرًا مثل أسلوب البرنامج الدفاعي.لذلك استخدمت نفس فكرة Minunit الممزوجة بالتأكيد القياسي.يمكنك رؤية إطار العمل الخاص بي (يمكن أن يكون الاسم الجيد NoMinunit) فيه مدونة k0ga
كمسخرة في http://code.google.com/p/cmockery/
لدى Google إطار اختبار ممتاز. https://github.com/google/googletest/blob/master/googletest/docs/primer.md
ونعم، بقدر ما أرى أنه سيعمل مع لغة C البسيطة، أي.لا يتطلب ميزات C++ (قد يتطلب مترجم C++، لست متأكدًا).
استهزاء هو مشروع تم إطلاقه مؤخرًا ويتكون من مكتبة C سهلة الاستخدام لكتابة اختبارات الوحدة.
أولا أنظر هنا: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C
تمتلك شركتي مكتبة C يستخدمها عملاؤنا.نستخدم CxxTest (مكتبة اختبار وحدة C++) لاختبار الكود.ستعمل CppUnit أيضًا.إذا كنت عالقًا في لغة C، فإنني أوصي بـ RCUNIT (ولكن CUnit جيد أيضًا).
إذا كنت معتادًا على JUnit فإنني أوصي بـ CppUnit.http://cppunit.sourceforge.net/cppunit-wiki
هذا على افتراض أن لديك مترجم c++ لإجراء اختبارات الوحدة.إذا لم يكن الأمر كذلك، فيجب أن أتفق مع آدم روزنفيلد على أن الشيك هو ما تريده.
إستعملت RCUNIT لإجراء بعض اختبارات الوحدة للتعليمات البرمجية المضمنة على جهاز الكمبيوتر قبل الاختبار على الهدف.يعد التجريد الجيد لواجهة الأجهزة أمرًا مهمًا وإلا فإن السجلات المعينة للذاكرة ستقتلك.
جرب lcut!- http://code.google.com/p/lcut
مدقق سلامة API — إطار اختبار لمكتبات C/C++:
مولد تلقائي لاختبارات الوحدة الأساسية لمكتبة C/C++ مشتركة.إنه قادر على إنشاء بيانات إدخال معقولة (في معظم الحالات، ولكن للأسف ليس كلها) للمعلمات وإنشاء حالات اختبار بسيطة ("العقلانية" أو "السطحية") لكل وظيفة في واجهة برمجة التطبيقات (API) من خلال تحليل الإعلانات في الرأس ملفات.
تسمح جودة الاختبارات التي تم إنشاؤها بالتحقق من عدم وجود أخطاء فادحة في حالات الاستخدام البسيطة.الأداة قادرة على إنشاء وتنفيذ الاختبارات التي تم إنشاؤها واكتشاف الأعطال (الأخطاء الفردية)، والإجهاض، وجميع أنواع الإشارات المنبعثة، ورمز إرجاع البرنامج غير الصفري، وتعليق البرنامج.
أمثلة:
- حزمة اختبار لتكوين الخطوط 2.8.0
- حزمة اختبار لـ FreeType 2.4.8
إحدى التقنيات التي يجب استخدامها هي تطوير كود اختبار الوحدة باستخدام إطار عمل C++ xUnit (والمترجم C++)، مع الحفاظ على مصدر النظام المستهدف كوحدات C.
تأكد من تجميع مصدر C الخاص بك بانتظام ضمن المترجم المتقاطع الخاص بك، تلقائيًا مع اختبارات الوحدة الخاصة بك إن أمكن.
ليبو (http://koanlogic.com/libu) يحتوي على وحدة اختبار الوحدة التي تسمح بتبعيات مجموعة/حالة الاختبار الصريحة وعزل الاختبار والتنفيذ المتوازي ومنسق التقارير القابل للتخصيص (التنسيقات الافتراضية هي xml وtxt).
المكتبة مرخصة من BSD وتحتوي على العديد من الوحدات المفيدة الأخرى - الشبكات، وتصحيح الأخطاء، وهياكل البيانات شائعة الاستخدام، والتكوين، وما إلى ذلك.- إذا كنت في حاجة إليها في مشاريعك ...
أنا مندهش أنه لم يذكر أحد القاطع (http://cutter.sourceforge.net/)يمكنك اختبار C وC++، فهو يتكامل بسلاسة مع الأدوات التلقائية ويتوفر به برنامج تعليمي رائع حقًا.
في حال كنت تستهدف منصات Win32 أو وضع NT kernel، يجب عليك إلقاء نظرة على ذلك cfix.
إذا كنت لا تزال تبحث عن أطر عمل الاختبار، CUnitWin32 هو واحد للنظام الأساسي Win32/NT.
وهذا يحل مشكلة أساسية واحدة واجهتها مع أطر الاختبار الأخرى.وهي المتغيرات العالمية/الثابتة التي تكون في حالة حتمية لأنه يتم تنفيذ كل اختبار كعملية منفصلة.
