تسريع إنشاء اختبار الوحدة وتحسين جودة التعليمات البرمجية

لقد أتيحت لي الفرصة مؤخرًا للتعمق في برنامج Early، وهو وكيل ذكاء اصطناعي مصمم لإنشاء اختبار الوحدة تلقائيًا. باعتباري شخصًا يعمل بانتظام مع TypeScript وExpressoTS Framework، كنت حريصًا على رؤية كيف يمكن لـ Early تبسيط سير العمل الخاص بي. قررت اختبار ملحق vscode الذي قاموا ببنائه على مكتبة NPM الجديدة التي كنت أقوم بتطويرها والتي تسمى @expressots/share.

الانطباعات الأولية

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

توفير الوقت وزيادة التغطية

في 8.5 ساعة فقط، تمكنت من:

• إنشاء اختبارات الوحدة لما يقرب من 3000 سطر من التعليمات البرمجية.
• إصلاح المشكلات وتحسين قابلية اختبار التعليمات البرمجية.
• حقق تغطية إجمالية للكود بنسبة 88% من خلال 96 اختبارًا.

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

نتائج إيجابية

الإنشاء التلقائي لاختبارات حالة الحافة. على سبيل المثال، تم إنشاء اختبارات الوحدة للسيناريوهات التي تتضمن سلاسل فارغة، حتى عندما كانت المعلمات مطلوبة:

export function printSuccess(message: string, component: string): void {
  stdout.write(chalk.green(`${message}:`, chalk.bold(chalk.white(`[${component}] ✔️\n`))));
}

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

الكشف عن المشكلات المحتملة

أثناء تحسين الاختبارات التي تم إنشاؤها، واجهت مشكلة عدم تطابق النوع:

المشكلة: jest.fn()‎ لا تُرجع أيًا منها، لكن Process.exit لا تُرجع أبدًا، مما يؤدي إلى عدم تطابق النوع في TypeScript.
الحل: قم بتعديل النموذج ليتوافق مع توقيعprocess.exit، مع ضمان صحة النوع.
دفعني هذا الاكتشاف إلى تعديل الكود الخاص بي لتحسين أمان الكتابة، مع تسليط الضوء على كيف يمكن لـ Early المساعدة في تحديد المشكلات الدقيقة التي قد تمر دون أن يلاحظها أحد.

مجالات التحسين

على الرغم من التجربة الإيجابية بشكل عام، واجهت بعض التحديات التي، إذا تمت معالجتها، يمكن أن تعزز سهولة استخدام Early:

• توافق إصدار المكتبة. الاختبارات التي تم إنشاؤها مبكرًا باستخدام أساليب Jest المهملة في بعض الحالات، على سبيل المثال:

استخدام Jest 29.7

expect(Compiler.loadConfig()).rejects.toThrowError("process.exit() was called with code 1");

// نسخة مصححة

expect(Compiler.loadConfig()).rejects.toThrow("process.exit() was called with code 1");

• خيارات التخصيص لإنشاء الاختبار على الرغم من أن إنشاء اختبارات لحالات الحافة كان مفيدًا، إلا أنه في بعض السيناريوهات، قد لا يكون ضروريًا:

ملاحظة: قد يكون إنشاء اختبارات لكل إدخال ممكن، بما في ذلك السلاسل الفارغة، أمرًا مبالغًا فيه في بعض الأحيان.

اقتراح: تقديم خيارات لتخصيص مستوى إنشاء الاختبار، مما يسمح للمطورين بالاشتراك في اختبارات البرمجة الدفاعية حسب الحاجة.

• تحسينات واجهة المستخدم في ملحق VSCODE أبرز التنقل بين الأدوات المبكرة والأدوات الأخرى بعض قيود واجهة المستخدم:

رؤية نتائج الاختبار: اضطررت إلى التبديل بين Early وJest لمعرفة الاختبارات التي نجحت أو فشلت.

حالة شجرة الملف: ينهار التسلسل الهرمي للمشروع في وقت مبكر عند التبديل مرة أخرى من التطبيقات الأخرى، مما يتطلب مني إعادة فتح المجلدات بشكل متكرر.
اقتراح: قم بتحسين واجهة المستخدم لعرض نتائج الاختبار في وقت مبكر، مما يعكس بنية Jest. سيؤدي الحفاظ على حالة شجرة الملفات أيضًا إلى تحسين تجربة المستخدم.

• السخرية وسلامة النوع تشير مشكلة إرجاع jest.fn() إلى الحاجة إلى استهزاء أكثر دقة:

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

خاتمة

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

مجالات التحسين بسيطة نسبيًا وتدور حول تحسين سهولة الاستخدام والتخصيص. معالجة هذه الأمور من شأنها أن تجعل الأداة حليفًا أكثر قوة في تطوير البرمجيات.

مجد للفريق المبكر على عملهم الممتاز! أنا متحمس لرؤية كيفية تطور الأداة وسأكون سعيدًا بمواصلة تقديم التعليقات للمساعدة في تحسينها بشكل أكبر.