البدء مع CppUTest
طائر
14/05/2017
البريد الإلكتروني
1 min read
النقاط الرئيسية
CppUTest هو إطار اختبار خفيف الوزن يتم صيانته بشكل نشط وفق نمط xUnit لاختبار C/C++، مع طبقة تكامل C تعمل بسلاسة حتى في أكواد C الثقيلة.
يمكنك تثبيته عبر مديري الحزم (توزيعات لينوكس، Homebrew) أو استنساخ مستودع GitHub.
يتكون الإعداد الأدنى من:
دليل الإنتاج
src/،دليل الاختبار
t/،قوم بتشغيل الاختبارات (
CommandLineTestRunner)، ووحدات الاختبار باستخدام كتل
TEST_GROUPوTEST().
يوفر CppUTest MakefileWorker.mk كمساعد يبسّط بناء الاختبارات، وربط المكتبات، ومعالجة العلامات.
كشف تسريبات الذاكرة مفعل بشكل افتراضي من خلال إعادة تعريف malloc/free، مما يلتقط التسريبات داخل الكود المصدر المختبر.
تغطية الكود عبر gcov تتكامل بسهولة من خلال تفعيل
CPPUTEST_USE_GCOV=Y، مما ينتج تقارير تغطية كاملة وملخصات HTML.الإطار يتضمن ميزات متقدمة: المحاكاة، الإضافات، نصوص المساعدة، والتعاون المباشر مع C - مفيد للأكواد المعقدة في المؤسسات.
أهم النقاط في الأسئلة والأجوبة
ما هو CppUTest ولماذا نستخدمه؟
إنه إطار اختبار قوي على طراز xUnit لـ C/C++ مع واجهة برمجة تطبيقات واضحة، وماكروهات تأكيد مدمجة، وكشف عن التسرب، وتطوير نشط - مثالي للأنظمة القديمة أو الحديثة.
كيف تُهيكل مشروعًا أساسيًا باستخدام CppUTest؟
src/ code/ code.cpp code.h main.cpp t/ main.cpp (test runner) test.cpp (test suite)
كيف يمكنك تشغيل جميع الاختبارات؟
يستخدم عداء الاختبار:
return CommandLineTestRunner::RunAllTests(ac, av);
كيف تبني اختبارات دون تكوين خيارات المترجم يدويًا؟
استخدم
MakefileWorker.mkمن CppUTest، الذي يتعامل مع الأعلام، والربط، وتنفيذ الاختبارات تلقائيًا.هل يمكن لـ CppUTest اكتشاف تسرب الذاكرة تلقائيًا؟
نعم. إنه يتجاوز malloc/free أثناء عمليات البناء الاختبارية، ويبلغ:
أي اختبار تسرب،
أين حدث،
حجم التسرب ومحتويات الذاكرة.
مثال على نتيجة الفشل:
Memory leak(s) found. Allocated at: code.c line 6 Leak size: 1
كيف يمكنني توليد تغطية الشيفرة؟
تمكين:
CPPUTEST_USE_GCOV=Yتأكد من توفر
filterGcov.shفي$(CPPUTEST_HOME)/scripts/.شغّل: make
gcovهذا ينتج
.gcovونص ملخص وتقارير تغطية بتنسيق HTML.
ماذا يمكن أن تفعل CppUTest بخلاف الاختبارات الأساسية؟
إطار العمل التخيلي
نظام الملحقات
نصوص أتمتة المساعدة
تكامل C الأصلي
ماكروز التأكيد الواسعة
من هو الأنسب لـ CppUTest؟
الفرق التي تعمل مع الأنظمة المدمجة، ومنصات C، وخدمات C++، أو أي بيئة يجب التحقق من موثوقيتها وسلامة الذاكرة فيها بشكل مستمر.
في SparkPost، نولي الكثير من الوقت والجهد لاختبار رمزنا. منصتنا مكتوبة بلغة C، ومؤخراً بحثت في دمج مع إطار اختبار الوحدة الذي يسمى “CppUTest”، والذي يوفر اختباراً بأسلوب xUnit لـ C/C++. هذا الإطار قوي وغني بالميزات، ويخضع لتطوير نشط، مما يجعله خياراً ممتازاً. كما يوفر طبقة تكامل مع C، مما سهّل استخدامه مع رمز C الخاص بمنصتنا على الرغم من أن معظم الإطار مكتوب بلغة C++. تغطي هذه الدورة كيفية البدء باستخدام CppUTest في مشاريعك الخاصة.
في SparkPost، نولي الكثير من الوقت والجهد لاختبار رمزنا. منصتنا مكتوبة بلغة C، ومؤخراً بحثت في دمج مع إطار اختبار الوحدة الذي يسمى “CppUTest”، والذي يوفر اختباراً بأسلوب xUnit لـ C/C++. هذا الإطار قوي وغني بالميزات، ويخضع لتطوير نشط، مما يجعله خياراً ممتازاً. كما يوفر طبقة تكامل مع C، مما سهّل استخدامه مع رمز C الخاص بمنصتنا على الرغم من أن معظم الإطار مكتوب بلغة C++. تغطي هذه الدورة كيفية البدء باستخدام CppUTest في مشاريعك الخاصة.
في SparkPost، نولي الكثير من الوقت والجهد لاختبار رمزنا. منصتنا مكتوبة بلغة C، ومؤخراً بحثت في دمج مع إطار اختبار الوحدة الذي يسمى “CppUTest”، والذي يوفر اختباراً بأسلوب xUnit لـ C/C++. هذا الإطار قوي وغني بالميزات، ويخضع لتطوير نشط، مما يجعله خياراً ممتازاً. كما يوفر طبقة تكامل مع C، مما سهّل استخدامه مع رمز C الخاص بمنصتنا على الرغم من أن معظم الإطار مكتوب بلغة C++. تغطي هذه الدورة كيفية البدء باستخدام CppUTest في مشاريعك الخاصة.
هل ترغب في المزيد؟
هذه ليست سوى قمة الجبل الجليدي عندما يتعلق الأمر بكل الميزات الموجودة في هذه الأداة. بالإضافة إلى الأساسيات التي تم مناقشتها هنا، تحتوي الأداة أيضًا على إطار عمل لمحاكاة، وطبقة تكامل مباشرة مع C، وإطار عمل ملحقات، لنذكر بعضًا من الأسماء المهمة. يحتوي المستودع أيضًا على دليل كامل من البرامج النصية المساعدة التي يمكن أن تساعد في أتمتة بعض الأجزاء الروتينية للعمل مع الإطار.
آمل أن تساعد المعلومات هنا في تحسين جودة كود C/C++ الخاص بك باستخدام هذه الأداة الرائعة!
هذه ليست سوى قمة الجبل الجليدي عندما يتعلق الأمر بكل الميزات الموجودة في هذه الأداة. بالإضافة إلى الأساسيات التي تم مناقشتها هنا، تحتوي الأداة أيضًا على إطار عمل لمحاكاة، وطبقة تكامل مباشرة مع C، وإطار عمل ملحقات، لنذكر بعضًا من الأسماء المهمة. يحتوي المستودع أيضًا على دليل كامل من البرامج النصية المساعدة التي يمكن أن تساعد في أتمتة بعض الأجزاء الروتينية للعمل مع الإطار.
آمل أن تساعد المعلومات هنا في تحسين جودة كود C/C++ الخاص بك باستخدام هذه الأداة الرائعة!
هذه ليست سوى قمة الجبل الجليدي عندما يتعلق الأمر بكل الميزات الموجودة في هذه الأداة. بالإضافة إلى الأساسيات التي تم مناقشتها هنا، تحتوي الأداة أيضًا على إطار عمل لمحاكاة، وطبقة تكامل مباشرة مع C، وإطار عمل ملحقات، لنذكر بعضًا من الأسماء المهمة. يحتوي المستودع أيضًا على دليل كامل من البرامج النصية المساعدة التي يمكن أن تساعد في أتمتة بعض الأجزاء الروتينية للعمل مع الإطار.
آمل أن تساعد المعلومات هنا في تحسين جودة كود C/C++ الخاص بك باستخدام هذه الأداة الرائعة!
تنزيل CppUTest
صفحة مشروع CppUTest متاحة على الموقع الرسمي، والمستودع موجود على github. وهو أيضًا مدرج في مستودعات إدارة الحزم للعديد من توزيعات لينكس، وكذلك homebrew على نظام ماك. الأمثلة التي تلي تم تنفيذها على نظام ماك OS X، لكنها مستمدة من كود تم كتابته لنظام ريدهات، وهو نظام التشغيل الذي يعمل عليه منصتنا.
الأساسيات موثقة بشكل جيد على الصفحة الرئيسية لـ CppUTest. سنقوم بتجاوز ذلك وننتقل إلى بعض الميزات الأكثر إثارة للاهتمام.
صفحة مشروع CppUTest متاحة على الموقع الرسمي، والمستودع موجود على github. وهو أيضًا مدرج في مستودعات إدارة الحزم للعديد من توزيعات لينكس، وكذلك homebrew على نظام ماك. الأمثلة التي تلي تم تنفيذها على نظام ماك OS X، لكنها مستمدة من كود تم كتابته لنظام ريدهات، وهو نظام التشغيل الذي يعمل عليه منصتنا.
الأساسيات موثقة بشكل جيد على الصفحة الرئيسية لـ CppUTest. سنقوم بتجاوز ذلك وننتقل إلى بعض الميزات الأكثر إثارة للاهتمام.
صفحة مشروع CppUTest متاحة على الموقع الرسمي، والمستودع موجود على github. وهو أيضًا مدرج في مستودعات إدارة الحزم للعديد من توزيعات لينكس، وكذلك homebrew على نظام ماك. الأمثلة التي تلي تم تنفيذها على نظام ماك OS X، لكنها مستمدة من كود تم كتابته لنظام ريدهات، وهو نظام التشغيل الذي يعمل عليه منصتنا.
الأساسيات موثقة بشكل جيد على الصفحة الرئيسية لـ CppUTest. سنقوم بتجاوز ذلك وننتقل إلى بعض الميزات الأكثر إثارة للاهتمام.
وضع الأساس
أولاً وقبل كل شيء، دعنا نكتب بعض الأكواد!
سيحتوي مشروع الاختبار الخاص بنا على ملف
أولاً وقبل كل شيء، دعنا نكتب بعض الأكواد!
سيحتوي مشروع الاختبار الخاص بنا على ملف
أولاً وقبل كل شيء، دعنا نكتب بعض الأكواد!
سيحتوي مشروع الاختبار الخاص بنا على ملف
ملف مشروع
سيكون ملف Makefile الخاص بالمشروع على نفس المستوى مثل دلائل ‘src’ و ‘t’ في جذر المشروع. يجب أن يبدو هكذا:
# Makefile SRC_DIR = ./src CODE_DIR = $(SRC_DIR)/code OUT = example TEST_DIR = t test: make -C $(TEST_DIR) test_clean: make -C $(TEST_DIR) clean code.o: gcc -c -I$(CODE_DIR) $(CODE_DIR)/code.cpp -o $(CODE_DIR)/code.o main: code.o gcc -I$(CODE_DIR) $(CODE_DIR)/code.o $(SRC_DIR)/main.cpp -o $(OUT) all: test main clean: test_clean rm $(SRC_DIR)/*.o $(CODE_DIR)/*.o $(OUT)
لاحظ أن هذا يستخدم ‘make -C’ لأهداف الاختبار – مما يعني أنه سيقوم بالاتصال بـ ‘make’ مرة أخرى باستخدام ملف Makefile في دليل الاختبار.
في هذه النقطة يمكننا تجميع كود ‘src’ باستخدام ملف Makefile ورؤية أنه يعمل:
[]$ make main gcc -c -I./src/code ./src/code/code.cpp -o ./src/code/code.o gcc -I./src/code ./src/code/code.o ./src/main.cpp -o example []$ ./example hello world
سيكون ملف Makefile الخاص بالمشروع على نفس المستوى مثل دلائل ‘src’ و ‘t’ في جذر المشروع. يجب أن يبدو هكذا:
# Makefile SRC_DIR = ./src CODE_DIR = $(SRC_DIR)/code OUT = example TEST_DIR = t test: make -C $(TEST_DIR) test_clean: make -C $(TEST_DIR) clean code.o: gcc -c -I$(CODE_DIR) $(CODE_DIR)/code.cpp -o $(CODE_DIR)/code.o main: code.o gcc -I$(CODE_DIR) $(CODE_DIR)/code.o $(SRC_DIR)/main.cpp -o $(OUT) all: test main clean: test_clean rm $(SRC_DIR)/*.o $(CODE_DIR)/*.o $(OUT)
لاحظ أن هذا يستخدم ‘make -C’ لأهداف الاختبار – مما يعني أنه سيقوم بالاتصال بـ ‘make’ مرة أخرى باستخدام ملف Makefile في دليل الاختبار.
في هذه النقطة يمكننا تجميع كود ‘src’ باستخدام ملف Makefile ورؤية أنه يعمل:
[]$ make main gcc -c -I./src/code ./src/code/code.cpp -o ./src/code/code.o gcc -I./src/code ./src/code/code.o ./src/main.cpp -o example []$ ./example hello world
سيكون ملف Makefile الخاص بالمشروع على نفس المستوى مثل دلائل ‘src’ و ‘t’ في جذر المشروع. يجب أن يبدو هكذا:
# Makefile SRC_DIR = ./src CODE_DIR = $(SRC_DIR)/code OUT = example TEST_DIR = t test: make -C $(TEST_DIR) test_clean: make -C $(TEST_DIR) clean code.o: gcc -c -I$(CODE_DIR) $(CODE_DIR)/code.cpp -o $(CODE_DIR)/code.o main: code.o gcc -I$(CODE_DIR) $(CODE_DIR)/code.o $(SRC_DIR)/main.cpp -o $(OUT) all: test main clean: test_clean rm $(SRC_DIR)/*.o $(CODE_DIR)/*.o $(OUT)
لاحظ أن هذا يستخدم ‘make -C’ لأهداف الاختبار – مما يعني أنه سيقوم بالاتصال بـ ‘make’ مرة أخرى باستخدام ملف Makefile في دليل الاختبار.
في هذه النقطة يمكننا تجميع كود ‘src’ باستخدام ملف Makefile ورؤية أنه يعمل:
[]$ make main gcc -c -I./src/code ./src/code/code.cpp -o ./src/code/code.o gcc -I./src/code ./src/code/code.o ./src/main.cpp -o example []$ ./example hello world
اختبارات ملف التكوين
بالنسبة للاختبارات، الأمور أكثر تعقيدًا قليلاً لأننا بحاجة إلى تحميل ودمج مكتبة CppUTest بشكل صحيح.
يوفر مستودع CppUTest ملفًا يسمى “MakefileWorker.mk”. يوفر العديد من الوظائف التي تجعل عملية البناء باستخدام CppUTest بسيطة. يعيش الملف تحت دليل “build” في مستودع git. في هذا البرنامج التعليمي، سنفترض أنه تم نسخه إلى دليل ‘t/’. يمكن استخدامه على النحو التالي:
# we don’t want to use relative paths, so we set these variables PROJECT_DIR=/path/to/project SRC_DIR=$(PROJECT_DIR)/src TEST_DIR=$(PROJECT_DIR)/t # specify where the source code and includes are located INCLUDE_DIRS=$(SRC_DIR)/code SRC_DIRS=$(SRC_DIR)/code # specify where the test code is located TEST_SRC_DIRS=$(TEST_DIR) # what to call the test binary TEST_TARGET=example # where the cpputest library is located CPPUTEST_HOME=/usr/local # run MakefileWorker.mk with the variables defined here include MakefileWorker.mk
لاحظ أن CPPUTEST_HOME يجب أن يُحدد في المكان الذي تم تثبيت CppUTest فيه. إذا قمت بتثبيت حزمة توزيعة، فسيكون هذا عادةً تحت /usr/local على نظام لينيكس/ماك. إذا كنت قد قمت بسحب المستودع بنفسك، فإنه يوجد في أي مكان يكون فيه ذلك السحب.
تم توثيق هذه الخيارات جميعًا في MakefileWorker.mk.
كما يضيف MakefileWorker.mk بضع أهداف Makefile، بما في ذلك ما يلي:
all – يبني الاختبارات المحددة بواسطة Makefile
clean – يزيل جميع ملفات الكائن و gcov التي تم إنشاؤها للاختبارات
realclean – يزيل أي ملفات كائن أو gcov في شجرة الدليل بالكامل
flags – يسرد جميع العلامات المكونة المستخدمة لتجميع الاختبارات
debug – يسرد جميع ملفات المصدر، والأشياء، والاعتمادات، و“الأشياء التي يجب تنظيفها”
المكون | الغرض | الملفات الرئيسية / العلامات | ملاحظات |
|---|---|---|---|
Makefile المشروع | يبني كود المصدر الأساسي | Makefile على مستوى الجذر باستخدام make | يجمع |
Makefile الاختبارات | يبني ويربط الاختبارات مع CppUTest |
| يتعامل مع تجميع الاختبار والربط وعلامات المكتبة |
MakefileWorker.mk | يوفر منطق بناء قابلاً لإعادة الاستخدام | يقع في دليل CppUTest | يضيف أهداف: |
التكامل مع GCov | يمكن من إعداد تقارير تغطية الشفرة |
| ينتج |
الكشف عن تسريبات الذاكرة | يكتشف تسريبات malloc/free |
| مفعل بشكل افتراضي؛ يمكن تعطيله بواسطة |
عداء الاختبار | ينفذ مجموعات الاختبار |
| نقطة الدخول الرئيسية المطلوبة لتنفيذ الاختبارات |
بالنسبة للاختبارات، الأمور أكثر تعقيدًا قليلاً لأننا بحاجة إلى تحميل ودمج مكتبة CppUTest بشكل صحيح.
يوفر مستودع CppUTest ملفًا يسمى “MakefileWorker.mk”. يوفر العديد من الوظائف التي تجعل عملية البناء باستخدام CppUTest بسيطة. يعيش الملف تحت دليل “build” في مستودع git. في هذا البرنامج التعليمي، سنفترض أنه تم نسخه إلى دليل ‘t/’. يمكن استخدامه على النحو التالي:
# we don’t want to use relative paths, so we set these variables PROJECT_DIR=/path/to/project SRC_DIR=$(PROJECT_DIR)/src TEST_DIR=$(PROJECT_DIR)/t # specify where the source code and includes are located INCLUDE_DIRS=$(SRC_DIR)/code SRC_DIRS=$(SRC_DIR)/code # specify where the test code is located TEST_SRC_DIRS=$(TEST_DIR) # what to call the test binary TEST_TARGET=example # where the cpputest library is located CPPUTEST_HOME=/usr/local # run MakefileWorker.mk with the variables defined here include MakefileWorker.mk
لاحظ أن CPPUTEST_HOME يجب أن يُحدد في المكان الذي تم تثبيت CppUTest فيه. إذا قمت بتثبيت حزمة توزيعة، فسيكون هذا عادةً تحت /usr/local على نظام لينيكس/ماك. إذا كنت قد قمت بسحب المستودع بنفسك، فإنه يوجد في أي مكان يكون فيه ذلك السحب.
تم توثيق هذه الخيارات جميعًا في MakefileWorker.mk.
كما يضيف MakefileWorker.mk بضع أهداف Makefile، بما في ذلك ما يلي:
all – يبني الاختبارات المحددة بواسطة Makefile
clean – يزيل جميع ملفات الكائن و gcov التي تم إنشاؤها للاختبارات
realclean – يزيل أي ملفات كائن أو gcov في شجرة الدليل بالكامل
flags – يسرد جميع العلامات المكونة المستخدمة لتجميع الاختبارات
debug – يسرد جميع ملفات المصدر، والأشياء، والاعتمادات، و“الأشياء التي يجب تنظيفها”
المكون | الغرض | الملفات الرئيسية / العلامات | ملاحظات |
|---|---|---|---|
Makefile المشروع | يبني كود المصدر الأساسي | Makefile على مستوى الجذر باستخدام make | يجمع |
Makefile الاختبارات | يبني ويربط الاختبارات مع CppUTest |
| يتعامل مع تجميع الاختبار والربط وعلامات المكتبة |
MakefileWorker.mk | يوفر منطق بناء قابلاً لإعادة الاستخدام | يقع في دليل CppUTest | يضيف أهداف: |
التكامل مع GCov | يمكن من إعداد تقارير تغطية الشفرة |
| ينتج |
الكشف عن تسريبات الذاكرة | يكتشف تسريبات malloc/free |
| مفعل بشكل افتراضي؛ يمكن تعطيله بواسطة |
عداء الاختبار | ينفذ مجموعات الاختبار |
| نقطة الدخول الرئيسية المطلوبة لتنفيذ الاختبارات |
بالنسبة للاختبارات، الأمور أكثر تعقيدًا قليلاً لأننا بحاجة إلى تحميل ودمج مكتبة CppUTest بشكل صحيح.
يوفر مستودع CppUTest ملفًا يسمى “MakefileWorker.mk”. يوفر العديد من الوظائف التي تجعل عملية البناء باستخدام CppUTest بسيطة. يعيش الملف تحت دليل “build” في مستودع git. في هذا البرنامج التعليمي، سنفترض أنه تم نسخه إلى دليل ‘t/’. يمكن استخدامه على النحو التالي:
# we don’t want to use relative paths, so we set these variables PROJECT_DIR=/path/to/project SRC_DIR=$(PROJECT_DIR)/src TEST_DIR=$(PROJECT_DIR)/t # specify where the source code and includes are located INCLUDE_DIRS=$(SRC_DIR)/code SRC_DIRS=$(SRC_DIR)/code # specify where the test code is located TEST_SRC_DIRS=$(TEST_DIR) # what to call the test binary TEST_TARGET=example # where the cpputest library is located CPPUTEST_HOME=/usr/local # run MakefileWorker.mk with the variables defined here include MakefileWorker.mk
لاحظ أن CPPUTEST_HOME يجب أن يُحدد في المكان الذي تم تثبيت CppUTest فيه. إذا قمت بتثبيت حزمة توزيعة، فسيكون هذا عادةً تحت /usr/local على نظام لينيكس/ماك. إذا كنت قد قمت بسحب المستودع بنفسك، فإنه يوجد في أي مكان يكون فيه ذلك السحب.
تم توثيق هذه الخيارات جميعًا في MakefileWorker.mk.
كما يضيف MakefileWorker.mk بضع أهداف Makefile، بما في ذلك ما يلي:
all – يبني الاختبارات المحددة بواسطة Makefile
clean – يزيل جميع ملفات الكائن و gcov التي تم إنشاؤها للاختبارات
realclean – يزيل أي ملفات كائن أو gcov في شجرة الدليل بالكامل
flags – يسرد جميع العلامات المكونة المستخدمة لتجميع الاختبارات
debug – يسرد جميع ملفات المصدر، والأشياء، والاعتمادات، و“الأشياء التي يجب تنظيفها”
المكون | الغرض | الملفات الرئيسية / العلامات | ملاحظات |
|---|---|---|---|
Makefile المشروع | يبني كود المصدر الأساسي | Makefile على مستوى الجذر باستخدام make | يجمع |
Makefile الاختبارات | يبني ويربط الاختبارات مع CppUTest |
| يتعامل مع تجميع الاختبار والربط وعلامات المكتبة |
MakefileWorker.mk | يوفر منطق بناء قابلاً لإعادة الاستخدام | يقع في دليل CppUTest | يضيف أهداف: |
التكامل مع GCov | يمكن من إعداد تقارير تغطية الشفرة |
| ينتج |
الكشف عن تسريبات الذاكرة | يكتشف تسريبات malloc/free |
| مفعل بشكل افتراضي؛ يمكن تعطيله بواسطة |
عداء الاختبار | ينفذ مجموعات الاختبار |
| نقطة الدخول الرئيسية المطلوبة لتنفيذ الاختبارات |
تغطية الكود
لن تكتمل اختبارات الوحدة بدون تقرير تغطية. الأداة المستخدمة لهذا في المشاريع التي تستخدم gcc هي gcov، المتاحة كجزء من المجموعة القياسية من أدوات gcc. يتكامل Cpputest بسهولة مع gcov، كل ما عليك فعله هو إضافة هذا السطر إلى ملف makefile:
CPPUTEST_USE_GCOV=Y
بعد ذلك، نحتاج إلى التأكد من أن نص المرشح filterGcov.sh من هذا المستودع موجود في ‘/scripts/filterGcov.sh’ بالنسبة إلى أي مكان قمت بتعيين ‘CPPUTEST_HOME’ ليكون. كما يحتاج إلى أذونات تنفيذ.
في مثال Makefile، سيتم نشره إلى ‘/usr/local/scripts/filterGcov.sh’. إذا كنت تقوم بتشغيل CppUTest من سحب المستودع، يجب أن يعمل كل شيء بدون تعديل.
مع ذلك في مكانه، يمكنك ببساطة تشغيل ‘make gcov’ وسيتم إنشاء التحليل لك. في حالتنا، سنحتاج إلى ‘make -B’ لإعادة بناء ملفات الكائن مع تمكين gcov:
[]$ make -B gcov < compilation output > for d in /Users/ykuperman/code/blogpost/qa/src/code ; do \ FILES=`ls $d/*.c $d/*.cc $d/*.cpp 2> /dev/null` ; \ gcov --object-directory objs/$d $FILES >> gcov_output.txt 2>>gcov_error.txt ; \ done for f in ; do \ gcov --object-directory objs/$f $f >> gcov_output.txt 2>>gcov_error.txt ; \ done /usr/local/scripts/filterGcov.sh gcov_output.txt gcov_error.txt gcov_report.txt example.txt cat gcov_report.txt 100.00% /Users/ykuperman/code/blogpost/qa/src/code/code.cpp mkdir -p gcov mv *.gcov gcov mv gcov_* gcov See gcov directory for details
سيؤدي هذا إلى إخراج عدد من الملفات إلى مجلد جديد يسمى ‘gcov’. وهذه هي:
code.cpp.gcov – ملف ‘gcov’ الفعلي للشيفرة التي يتم اختبارها
gcov_error.txt – تقرير خطأ (في حالتنا، ينبغي أن يكون فارغًا)
gcov_output.txt – الإخراج الفعلي لأمر gcov الذي تم تشغيله
gcov_report.txt – ملخص عن التغطية لكل ملف قيد الاختبار
gcov_report.txt.html – نسخة html من gcov_report
لن تكتمل اختبارات الوحدة بدون تقرير تغطية. الأداة المستخدمة لهذا في المشاريع التي تستخدم gcc هي gcov، المتاحة كجزء من المجموعة القياسية من أدوات gcc. يتكامل Cpputest بسهولة مع gcov، كل ما عليك فعله هو إضافة هذا السطر إلى ملف makefile:
CPPUTEST_USE_GCOV=Y
بعد ذلك، نحتاج إلى التأكد من أن نص المرشح filterGcov.sh من هذا المستودع موجود في ‘/scripts/filterGcov.sh’ بالنسبة إلى أي مكان قمت بتعيين ‘CPPUTEST_HOME’ ليكون. كما يحتاج إلى أذونات تنفيذ.
في مثال Makefile، سيتم نشره إلى ‘/usr/local/scripts/filterGcov.sh’. إذا كنت تقوم بتشغيل CppUTest من سحب المستودع، يجب أن يعمل كل شيء بدون تعديل.
مع ذلك في مكانه، يمكنك ببساطة تشغيل ‘make gcov’ وسيتم إنشاء التحليل لك. في حالتنا، سنحتاج إلى ‘make -B’ لإعادة بناء ملفات الكائن مع تمكين gcov:
[]$ make -B gcov < compilation output > for d in /Users/ykuperman/code/blogpost/qa/src/code ; do \ FILES=`ls $d/*.c $d/*.cc $d/*.cpp 2> /dev/null` ; \ gcov --object-directory objs/$d $FILES >> gcov_output.txt 2>>gcov_error.txt ; \ done for f in ; do \ gcov --object-directory objs/$f $f >> gcov_output.txt 2>>gcov_error.txt ; \ done /usr/local/scripts/filterGcov.sh gcov_output.txt gcov_error.txt gcov_report.txt example.txt cat gcov_report.txt 100.00% /Users/ykuperman/code/blogpost/qa/src/code/code.cpp mkdir -p gcov mv *.gcov gcov mv gcov_* gcov See gcov directory for details
سيؤدي هذا إلى إخراج عدد من الملفات إلى مجلد جديد يسمى ‘gcov’. وهذه هي:
code.cpp.gcov – ملف ‘gcov’ الفعلي للشيفرة التي يتم اختبارها
gcov_error.txt – تقرير خطأ (في حالتنا، ينبغي أن يكون فارغًا)
gcov_output.txt – الإخراج الفعلي لأمر gcov الذي تم تشغيله
gcov_report.txt – ملخص عن التغطية لكل ملف قيد الاختبار
gcov_report.txt.html – نسخة html من gcov_report
لن تكتمل اختبارات الوحدة بدون تقرير تغطية. الأداة المستخدمة لهذا في المشاريع التي تستخدم gcc هي gcov، المتاحة كجزء من المجموعة القياسية من أدوات gcc. يتكامل Cpputest بسهولة مع gcov، كل ما عليك فعله هو إضافة هذا السطر إلى ملف makefile:
CPPUTEST_USE_GCOV=Y
بعد ذلك، نحتاج إلى التأكد من أن نص المرشح filterGcov.sh من هذا المستودع موجود في ‘/scripts/filterGcov.sh’ بالنسبة إلى أي مكان قمت بتعيين ‘CPPUTEST_HOME’ ليكون. كما يحتاج إلى أذونات تنفيذ.
في مثال Makefile، سيتم نشره إلى ‘/usr/local/scripts/filterGcov.sh’. إذا كنت تقوم بتشغيل CppUTest من سحب المستودع، يجب أن يعمل كل شيء بدون تعديل.
مع ذلك في مكانه، يمكنك ببساطة تشغيل ‘make gcov’ وسيتم إنشاء التحليل لك. في حالتنا، سنحتاج إلى ‘make -B’ لإعادة بناء ملفات الكائن مع تمكين gcov:
[]$ make -B gcov < compilation output > for d in /Users/ykuperman/code/blogpost/qa/src/code ; do \ FILES=`ls $d/*.c $d/*.cc $d/*.cpp 2> /dev/null` ; \ gcov --object-directory objs/$d $FILES >> gcov_output.txt 2>>gcov_error.txt ; \ done for f in ; do \ gcov --object-directory objs/$f $f >> gcov_output.txt 2>>gcov_error.txt ; \ done /usr/local/scripts/filterGcov.sh gcov_output.txt gcov_error.txt gcov_report.txt example.txt cat gcov_report.txt 100.00% /Users/ykuperman/code/blogpost/qa/src/code/code.cpp mkdir -p gcov mv *.gcov gcov mv gcov_* gcov See gcov directory for details
سيؤدي هذا إلى إخراج عدد من الملفات إلى مجلد جديد يسمى ‘gcov’. وهذه هي:
code.cpp.gcov – ملف ‘gcov’ الفعلي للشيفرة التي يتم اختبارها
gcov_error.txt – تقرير خطأ (في حالتنا، ينبغي أن يكون فارغًا)
gcov_output.txt – الإخراج الفعلي لأمر gcov الذي تم تشغيله
gcov_report.txt – ملخص عن التغطية لكل ملف قيد الاختبار
gcov_report.txt.html – نسخة html من gcov_report
كشف تسرب الذاكرة في Cpputest
Cpputest يتيح لك اكتشاف ذاكرة مسربة تلقائيًا عن طريق إعادة تعريف عائلة الدوال القياسية "malloc/free" لاستخدام أغلفته الخاصة بدلاً من ذلك. وهذا يسمح له بالكشف عن التسريبات بسرعة والإبلاغ عنها لكل تنفيذ اختبار. هذه الميزة مفعلة افتراضيًا في MakefileWorker.mk، لذا فهي مفعلّة بالفعل مع الخطوات المذكورة حتى الآن.
لتوضيح ذلك، دعنا نتسبب في تسرب بعض الذاكرة في test_func() !
عند العودة إلى code.c، نضيف malloc() إلى الدالة، كما يلي:
int test_func() { malloc(1); return 1; }
الآن، بعد إعادة التجميع، يتم إنتاج الخطأ التالي:
test.cpp:9: error: Failure in TEST(AwesomeExamples, FirstExample) Memory leak(s) found. Alloc num (4) Leak size: 1 Allocated at: ./code.c and line: 6 Type: "malloc" Memory: <
هذا يوضح أي اختبار تسبب في التسرب، وأين حدث التسرب في الكود المصدر، وما كان في الذاكرة المسربة. مفيد جدًا!
هناك بعض التحذيرات بشأن هذه الميزة:
Cpputest يستخدم ماكرز المعالجة المسبقة لإعادة تعريف جميع الاستدعاءات إلى دوال إدارة الذاكرة القياسية بشكل ديناميكي. وهذا يعني أنه سيعمل فقط لاستدعاءات الكود المصدر تحت الاختبار، حيث أن هذا هو ما يتم تجميعه مع تجاوزات CppUTest. لن يتم كشف التسريبات في المكتبات المرتبطة.
في بعض الأحيان، قد تكون الذاكرة المخصصة للحياة الكاملة للعملية غير مقصود بها أن تُحرر. قد يتسبب هذا في الكثير من الأخطاء العقيمة إذا كنت تختبر وحدة ذات هذا السلوك. لتعطيل اكتشاف التسرب، يمكنك فعل ذلك:
CPPUTEST_USE_MEM_LEAK_DETECTION=N
Cpputest يتيح لك اكتشاف ذاكرة مسربة تلقائيًا عن طريق إعادة تعريف عائلة الدوال القياسية "malloc/free" لاستخدام أغلفته الخاصة بدلاً من ذلك. وهذا يسمح له بالكشف عن التسريبات بسرعة والإبلاغ عنها لكل تنفيذ اختبار. هذه الميزة مفعلة افتراضيًا في MakefileWorker.mk، لذا فهي مفعلّة بالفعل مع الخطوات المذكورة حتى الآن.
لتوضيح ذلك، دعنا نتسبب في تسرب بعض الذاكرة في test_func() !
عند العودة إلى code.c، نضيف malloc() إلى الدالة، كما يلي:
int test_func() { malloc(1); return 1; }
الآن، بعد إعادة التجميع، يتم إنتاج الخطأ التالي:
test.cpp:9: error: Failure in TEST(AwesomeExamples, FirstExample) Memory leak(s) found. Alloc num (4) Leak size: 1 Allocated at: ./code.c and line: 6 Type: "malloc" Memory: <
هذا يوضح أي اختبار تسبب في التسرب، وأين حدث التسرب في الكود المصدر، وما كان في الذاكرة المسربة. مفيد جدًا!
هناك بعض التحذيرات بشأن هذه الميزة:
Cpputest يستخدم ماكرز المعالجة المسبقة لإعادة تعريف جميع الاستدعاءات إلى دوال إدارة الذاكرة القياسية بشكل ديناميكي. وهذا يعني أنه سيعمل فقط لاستدعاءات الكود المصدر تحت الاختبار، حيث أن هذا هو ما يتم تجميعه مع تجاوزات CppUTest. لن يتم كشف التسريبات في المكتبات المرتبطة.
في بعض الأحيان، قد تكون الذاكرة المخصصة للحياة الكاملة للعملية غير مقصود بها أن تُحرر. قد يتسبب هذا في الكثير من الأخطاء العقيمة إذا كنت تختبر وحدة ذات هذا السلوك. لتعطيل اكتشاف التسرب، يمكنك فعل ذلك:
CPPUTEST_USE_MEM_LEAK_DETECTION=N
Cpputest يتيح لك اكتشاف ذاكرة مسربة تلقائيًا عن طريق إعادة تعريف عائلة الدوال القياسية "malloc/free" لاستخدام أغلفته الخاصة بدلاً من ذلك. وهذا يسمح له بالكشف عن التسريبات بسرعة والإبلاغ عنها لكل تنفيذ اختبار. هذه الميزة مفعلة افتراضيًا في MakefileWorker.mk، لذا فهي مفعلّة بالفعل مع الخطوات المذكورة حتى الآن.
لتوضيح ذلك، دعنا نتسبب في تسرب بعض الذاكرة في test_func() !
عند العودة إلى code.c، نضيف malloc() إلى الدالة، كما يلي:
int test_func() { malloc(1); return 1; }
الآن، بعد إعادة التجميع، يتم إنتاج الخطأ التالي:
test.cpp:9: error: Failure in TEST(AwesomeExamples, FirstExample) Memory leak(s) found. Alloc num (4) Leak size: 1 Allocated at: ./code.c and line: 6 Type: "malloc" Memory: <
هذا يوضح أي اختبار تسبب في التسرب، وأين حدث التسرب في الكود المصدر، وما كان في الذاكرة المسربة. مفيد جدًا!
هناك بعض التحذيرات بشأن هذه الميزة:
Cpputest يستخدم ماكرز المعالجة المسبقة لإعادة تعريف جميع الاستدعاءات إلى دوال إدارة الذاكرة القياسية بشكل ديناميكي. وهذا يعني أنه سيعمل فقط لاستدعاءات الكود المصدر تحت الاختبار، حيث أن هذا هو ما يتم تجميعه مع تجاوزات CppUTest. لن يتم كشف التسريبات في المكتبات المرتبطة.
في بعض الأحيان، قد تكون الذاكرة المخصصة للحياة الكاملة للعملية غير مقصود بها أن تُحرر. قد يتسبب هذا في الكثير من الأخطاء العقيمة إذا كنت تختبر وحدة ذات هذا السلوك. لتعطيل اكتشاف التسرب، يمكنك فعل ذلك:
CPPUTEST_USE_MEM_LEAK_DETECTION=N
