الصفحة الرئيسية>كود المصدر JSP>فئات أخرى
تنزيل

Save هو إطار اختبار لخط الأوامر متعدد الأغراض يمكن استخدامه لأدوات الاختبار التي تعمل مع التعليمات البرمجية ، مثل التحليلات والمجموعات الثابتة. إنه تطبيق أصلي بالكامل ، لا يتطلب أي حاجة لتثبيت أي SDK.

ما هو الحفظ؟

إن التحقق من التحليل الثابت والتقييم (SAVE) هو نظام بيئي (انظر أيضًا Save-Cloud) مصمم لتقييم واختبار وإصدار الشهادات من المحللين الثابتين أو المترجمين أو أي أدوات برمجية أخرى. بدلاً من تطوير إطار الاختبار الخاص بك ، يمكنك الاستفادة من Save كتطبيق اختبار سطر الأوامر. الشرط الوحيد هو إعداد موارد الاختبار بالتنسيق المناسب.

مساهمة

نحن بحاجة إلى مساعدتك! سنكون سعداء إذا كنت ستستخدم أو تختبر أو تساهم في هذا المشروع. في حال لم يكن لديك الكثير من الوقت لهذا - على الأقل امنحنا نجمًا لجذب المساهمين الآخرين! شكرًا! ؟

بداية سريعة: سيناريوهات المستخدم

1. التحليل الثابت ، التحذيرات ، بالتتابع

  • تقوم أداة تحليل التعليمات البرمجية الخاصة بي بمعالجة الملفات بالتتابع ، واحد تلو الآخر ؛
  • وهي تنتج تحذيرات وتخرجها إلى stdout ؛
  • أريد مقارنة التحذيرات الفعلية مع التحذيرات المتوقعة المحددة ضمن رمز مورد الاختبار .

2. التحليل الثابت ، التحذيرات ، معالجة المشروع بأكمله

  • لدي أيضًا أداة تحليل الكود ، لكنها تعالج المشروع بأكمله في وقت واحد ويدرك جميع علاقات الكود. ؛
  • وهي تنتج تحذيرات وتخرجها إلى stdout ؛
  • أريد مقارنة التحذيرات الفعلية مع التحذيرات المتوقعة المحددة ضمن رمز مورد الاختبار .

3. إصلاح الرمز الآلي أو توليد

  • تتلاعب أدواتي بالرمز الأصلي ، على سبيل المثال ، عن طريق تحديده تلقائيًا ؛
  • أرغب في التحقق من كيفية إصلاح الأداة الخاصة بي من خلال مقارنته بالنتيجة المتوقعة ؛
  • بالإضافة إلى ذلك ، يمكن استخدامه من قبل المجمعين للتحقق من صحة توليد الكود ، والانتقال من المصدر الأصلي
  • رمز للتمثيل الوسيط (IR) ، لغة برمجة أخرى ، أو حتى التجميع.

4. التحذيرات المتوقعة في ملف منفصل

  • لا أريد تحديد تحذيراتي المتوقعة في الكود ؛
  • أفضل استخدام ملف منفصل في SARIF أو أي تنسيق آخر.

كيفية الجري

  1. قم بتنزيل أحدث إصدار مناسب لنظام التشغيل والهندسة المعمارية.
  2. قم بإعداد وتكوين قاعدة الاختبار الخاصة بك بتنسيق حفظ الصحيح. ارجع إلى Test_Detection و Plugins للتوجيه.
  3. قم بتنفيذ الأمر التالي (قم بتعديله وفقًا للهندسة المعمارية ونظام التشغيل): save "/my/path/to/tests"

تأكد من أن دليل tests يحتوي على ملف تكوين save.toml .

حفظ قطع الأشجار

لتصحيح تصحيح التنفيذ ، يمكنك استخدام الوسيطة التالية: --log=TYPE ، حيث يمكن أن يكون TYPE أحد ما يلي:

  • all - قطع الأشجار الشاملة التي تتضمن جميع المعلومات من Save Execution ، حتى أكثر تفصيلًا من التصحيح (أقرب إلى التتبع).
  • debug - يعرض النتائج والتحذيرات ومعلومات التصحيح.
  • warnings - تظهر النتائج والتحذيرات الحرجة.
  • results_only - يعرض النتائج فقط.

الإضافات مع أمثلة

فيما يلي قائمة بالمكونات الإضافية القياسية:

  • Warn Plugin: هذا هو لأدوات الاختبار التي تكتشف المشكلات في الكود المصدري وتحذيرات.
  • إصلاح البرنامج المساعد: يتم استخدام هذا لاختبار أدوات المحلل الثابتة التي تعدل النص.
  • المكوّن الإضافي للإصلاح والحار: تحسين السيناريوهات حيث تريد تصحيح ملف وبعد ذلك تحقق من التحذيرات التي لم تتمكن الأداة من معالجتها في تشغيل واحد.

إذا كنت تريد أن تعمل مكونات إضافية متعددة في الدليل الخاص بك باستخدام نفس ملفات الاختبار (الموارد) ، فما عليك سوى إضافتها جميعًا إلى تكوين save.toml : 

 [general]
...

[fix]
...

[warn]
...

[other plugin]
...

حفظ التحذيرات DSL

حفظ cli يمكنك قراءة المزيد عن warn plugin هنا

كيفية التكوين

يحتوي Save على واجهة سطر الأوامر تتيح لك تشغيل كل من الإطار والقابل للتنفيذ. تتمثل مهمتك الرئيسية في تكوين إخراج المحلل الثابت الخاص بك بحيث يمكن أن يتحقق حفظ ما إذا كان قد تم وضع علامة على الخطأ المناسب في السطر الصحيح لرمز الاختبار.

للتأكد من أن التحذير دقيق للحفظ ، يجب على المحلل الثابت الخاص بك إخراج النتيجة إما إلى Stderr/stdout أو ملف سجل مخصص (على سبيل المثال بتنسيق SARIF).

يمكنك تكوين سلوك Save's General باستخدام وسيطات سطر الأوامر أو باستخدام ملف تكوين يسمى save.properties . يجب أن يكون هذا الملف موجودًا في نفس الدليل مثل تكوين اختبار الجذر ، save.toml .

للحصول على قائمة شاملة بالخيارات التي يمكن تمريرها لحفظها عبر سطر الأوامر أو ملف save.properties ، راجع جدول الخيارات أو تنفيذ أمر save --help . يرجى العلم أن الخيارات مع الخيارات حساسة للحالة.

سيقوم إطار Save Conferency تلقائيًا باكتشاف الاختبارات الخاصة بك ، وتشغيل محللك عليها ، وحساب معدل النجاح ، ونتائج اختبار الإرجاع بالتنسيق المتوقع.

اكتشاف الاختبار وملف Save.Toml

لتمكين حفظ لاكتشاف أجنحة الاختبار الخاصة بك ، يجب عليك وضع ملف save.toml في كل دليل يحتوي على أجنحة اختبار . من المهم أن نلاحظ أن ملفات التكوين هذه ترث تكوينات من الدلائل الأم.

على الرغم من أنه يمكن ترك معظم الحقول غير محددة في المستويات المنخفضة ويمكن أن ترث قيمًا من المستويات العليا ، يجب أن تكون حذراً. بعض الحقول في قسم [general] إلزامي للتنفيذ ، لذلك تحتاج إلى تحديدها في ملف تكوين واحد على الأقل في سلسلة الميراث للاختبارات التي تهدف إلى التشغيل. تحقق من الحقول إلزامية.

على سبيل المثال ، مع التسلسل الهرمي للدليل التالي: 

 | A
  | save.toml
  | B
    | save.toml

سوف يرث save.toml في الدليل B الإعدادات والخصائص من الدليل A.

ضع في اعتبارك أن SAVE سوف يكتشف جميع الملفات باستخدام "اختبار" postfix وسيستخدم تلقائيًا التكوينات من ملف save.toml الموجود في نفس الدليل (أو الموروثة من الأصل). تتم تسمية الاختبارات وفقًا لاسم مورد ملف الاختبار ، باستثناء لاحقة "الاختبار". إذا كان Save يكتشف ملفًا مع "اختبار" postfix في موارد الاختبار ولا يمكن تحديد موقع أي تكوينات save.toml في التسلسل الهرمي للدليل ، فسوف يلقي خطأ.

على سبيل المثال ، السيناريو أدناه غير صالح وسيؤدي إلى خطأ ، حيث لا يمكن لـ Save Framework تحديد موقع ملف تكوين save.toml : 

 | A
  | B
  | myTest.java

كما ذكرنا سابقًا ، يعد save.toml ضروريًا لتكوين الاختبارات. من الناحية المثالية ، يجب أن يكون هناك ملف تكوين واحد لكل دليل يحتوي على اختبارات ، وإنشاء علاقة فردية. نشير إلى هذه الدلائل كأجنحة test suites .

يتمثل الأساس المنطقي وراء وجود ملف تكوين واحد لجناح اختبار واحد هو تجنب التكوينات الزائدة داخل نفس جناح الاختبار.

حفظ. ملف تكوين

يستخدم تكوين الحفظ تنسيق TOML الذي يعمل بواسطة مشروع KTOML. كما ذكر أعلاه ، يمكن موروث save.toml من التسلسل الهرمي للدليل (أدلة الوالدين).

يحتوي ملف التكوين على جدول [general] وجدول [plugins] . لمزيد من المعلومات حول الإضافات ، راجع قسم الإضافات.

في هذا القسم ، سنقدم معلومات فقط حول الجدول [general] ، والذي يمكن استخدامه عبر جميع الإضافات. 

 [general]
# Your custom tags that will be used to detect groups of tests (required)
tags = ["parsing", "null-pointer", "etc"]

# Custom free text that describes the test suite (required)
description = "My suite description"

# Simple suite name (required)
suiteName = "DocsCheck", "CaseCheck", "NpeTests", "etc" 

# Execution command (required at least once in the configuration hierarchy)
# By the default these binaries should be in the same directory of where SAVE is run 
# or should have full or relational path (root - is the directory with save executable)
execCmd="./ktlint -R diktat-0.4.2.jar"

# Excluded tests in the suite (optional). Here, you can list the names of excluded tests, separated by commas. By default, no tests are excluded.
# To exclude tests, use the relative path to the root of the test project (to the root directory of `save.toml`)
excludedTests = ["warn/chapter1/GarbageTest.kt", "warn/otherDir/NewTest.kt", "etc"]

# Command execution time for one test (in milliseconds)
timeOutMillis = 10000

# Language for tests
language = "Kotlin"

تنفيذ اختبارات محددة

في بعض الأحيان ، قد ترغب في تنفيذ مجموعة محددة فقط من الاختبارات بدلاً من إجراء جميع الاختبارات ضمن تكوين save.toml معين. لتحقيق ذلك ، تمرير المسار النسبي إلى ملف الاختبار بعد جميع خيارات التكوين (الجذر - هو الدليل مع حفظ ثنائي): 

$ save [options] /path/to/tests/Test1

يمكنك أيضًا تقديم قائمة بالمسارات النسبية لاختبار الملفات (مفصولة بالمسافات): 

$ save [options] /path/to/tests/Test1 /path/to/tests/Test2

سوف يكتشف Save تلقائيًا أقرب ملف save.toml واستخدام التكوين منه.

Note: على Windows ، تذكر استخدام \ \ فاصل المسار.

حفظ الإخراج

يدعم حفظ العديد من التنسيقات لإخراج تقرير الاختبار:

  • PLAIN : جدول يشبه التخفيضات يوضح جميع نتائج الاختبار.
  • PLAIN_FAILED : على غرار PLAIN ، ولكن يعرض فقط الاختبارات الفاشلة.
  • JSON : تمثيل منظم لنتيجة التنفيذ.

يمكن تحديد التنسيق المطلوب باستخدام خيار- --report-type=PLAIN .

الغرض من مشروع التحقق من التحليل الثابت والتقييم (SAVE)

الغرض من مشروع التحقق من التحليل الثابت والتقييم (SAVE)

الغرض من حفظ

مقدمة

يعد استخدام المحللين الثابتين جزءًا لا يتجزأ من عملية التطوير لكل منتج برمجي. في حين أن مطوري البرامج قد يكتبون اختبارات مختلفة ويحققون تغطية اختبار جيدة ، إلا أن الخطأ البشري يظل أمرًا لا مفر منه. يمكن أن تؤدي هذه الأخطاء إلى خسائر مالية كبيرة للشركات. يساعد تحليل البرنامج الثابت في تحديد وتصحيح الأخطاء والمشكلات التي قد لا يمكن اكتشافها من خلال صحة التحويلات البرمجية وحدها.

يأتي التحليل الثابت في أشكال مختلفة ويخدم أغراض مختلفة. قد يتضمن تحليلًا بسيطًا باستخدام AST (شجرة بناء الجملة التجريدية) أو الخوض في إجراءات أكثر تعقيدًا مثل CFA (تحليل تدفق التحكم) ، أو التحليل المتداخل ، أو التحليل الحساس للسياق. يمكن للمحللين الثابتين تقييم نمط الكود ، وتحديد مشكلات وقت التشغيل المحتملة في منطق التطبيق ، واكتشاف الروائح الكود ، واقتراح أفضل الممارسات. ومع ذلك ، لا يزال هناك نقص في الوضوح حول الوظائف الأساسية للمحللين الثابتة. كيف يمكن قياس فعاليتها؟ ما هي المعايير التي تحدد قبولهم؟ ما هي الوظائف الضرورية للمطورين إنشاء محلل جديد؟ على الرغم من سنوات من تطوير المحلل الثابت ، لا تزال هذه الأسئلة دون إجابة إلى حد كبير.

المشاكل

في بداية رحلة التطوير الخاصة بهم ، يبدأ كل منشئ محلل ثابت بتحديد أنواع القضايا التي ستستهدفها أدائهم. يستلزم ذلك في كثير من الأحيان البحث عن القوائم الحالية للمشكلات المحتملة أو حزم الاختبار التي يمكنها توجيه عملية التطوير ، خاصةً إذا اتبع نهج TDD (التنمية التي تعتمد على الاختبار). في حين أن المجالات الأخرى في برمجة النظام وضعت معايير ومجموعات الاختبارات ، مثل معايير spec.org المستخدمة عالميا لتقييم مختلف مكونات البرامج والأجهزة ، لا توجد مثل هذه المعايير لتحديد المشكلات في لغات البرمجة الشعبية. بينما تم إنشاء إرشادات للترميز في C/C ++ بواسطة Misra ، لا توجد معادلات للغات المستخدمة على نطاق واسع مثل Python و JVM. هناك أجنحة اختبار متوفرة في NIST ، ولكن إطار عملها ونظامها الإيكولوجي مقيدان إلى حد ما.

بالنظر إلى هذا السيناريو ، غالبًا ما يجد المطورون أنفسهم يقومون بإعادة إنشاء آليات للتحليل الثابت أو تطوير أطر اختبار جديدة ، مما يؤدي إلى عمل متكرر. قد يختار البعض الإرشادات الحالية مثل نمط رمز Google أو قواعد PMD ، ولكن بغض النظر عن النهج ، يتم قضاء وقت كبير دائمًا على اختبارات التصور والكتابة وتصحيح الأخطاء.

تطوير

يبني

يستخدم المشروع Gradle كنظام بناء الخاص به ويمكن بناؤه باستخدام Command ./gradlew build .

لتجميع القطع الأثرية الأصلية ، يجب عليك تثبيت المتطلبات الأساسية كما هو موضح في الوثائق Kotlin/Native.

للوصول إلى التبعيات المستضافة في سجل حزمة GitHub ، أضف ما يلي إلى gradle.properties أو ~/.gradle/gradle.properties : 

 gprUser =<GH username>
gprKey =<GH personal access token>

يمكن إنشاء رمز الوصول الشخصي على https://github.com/settings/tokens/new. تأكد من أن الرمز المميز له نطاق يتضمن read:packages .

نظرًا للرمز الذي تم إنشاؤه ، تحتاج إلى تشغيل البناء مرة واحدة لاستيراد المشروع بشكل صحيح إلى IDE مع الواردات التي تم حلها.

يوسع
معلومات إضافية
تطبيقات ذات صلة
نوصي لك
أخبار ذات صلة الكل