لماذا اختبار التطوير المدفوع (TDD) هو أفضل طريقة لترميز قوي.

أولاً ، اكتب اختبارات الوحدة ، ثم اكتب الرمز.

ائتمانات الصورة: Pexels.com

منذ بضع سنوات ، عندما سمعت لأول مرة عن "تطوير الاختبارات المدفوعة" ، كنت متشككًا.

كانت فكرة "اختبارات وحدة الكتابة الأولى ، ثم كتابة الشفرة" رهيبة بالنسبة لي.

لماذا لا يكون؟ اكتب اختبارات وحدتك أولاً؟ من يفعل شيئاً أخرق هكذا؟

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

لذلك استشرت صديق لي الذي أظهر لي مثالا أساسيا.

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

كان رمز الفصل كما يلي:

CLASS lcl_sum تعريف.
القسم العام.
الطريقة: SUM IMPORTING iv_1 TYPE i
قيمة الإرجاع (rv_sum) النوع i.
ENDCLASS. "lcl_sum تعريف
*
ستارت-OF-اختيار.
* لا شيء هنا حتى الان
*
*
CLASS lcl_sum التنفيذ.
طريقة المجموع.
rv_sum = iv_1 * iv_1. "خطأ متعمد (أتضاعف بدلاً من الإضافة)
ENDMETHOD. "مجموع
ENDCLASS. "lcl_sum التنفيذ.

اختبار الإعداد الصف

الآن قم بإنشاء فصل يعمل كصف اختبار. في SAP ، ستحتاج إلى إضافة الكلمة الأساسية للاختبار عند تحديد الفصل. تفصل هذه الإضافة هذه الفئة عن رمز الإنتاج.

الفئة lcl_test تعريف للاختبار
القسم العام.
الطرق: m_sum للاختبار.
ENDCLASS. "lcl_test التعريف
*
CLASS lcl_test التنفيذ.
طريقة m_sum.
ENDMETHOD. "m_sum
ENDCLASS. "lcl_test التنفيذ

تنفيذ طريقة الاختبار

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

بناءً على قيمة Dummy ، سترسل لك الطريقة النتيجة - النتيجة الفعلية من هذه الطريقة. بناء على قيمة الدمية ، أنت تعرف القيمة المتوقعة. مثلا إذا قمت بتمرير الرقم 3 إلى طريقة SUM ، فستعطيك النتيجة 6 لأنها تضيف إلى 3.

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

CLASS lcl_test التنفيذ.
طريقة m_sum.
البيانات: o_cut TYPE REF TO lcl_sum.
البيانات: lv_result TYPE i.
*
إنشاء كائن o_cut.
lv_result = o_cut-> sum (3).
*
cl_aunit_assert => ASSERT_EQUALS (
خبرة = 6
الفعل = lv_result
msg = "خطأ ما في الإخراج"
).
ENDMETHOD. "m_sum
ENDCLASS. "lcl_test التنفيذ

نتائج اختبار الوحدة

هذا يخبرني أن هناك خطأ في تنفيذ طريقة الإنتاج.

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

كنت مدمن مخدرات إلى TDD. سيكون Flabbergasted الكلمة الصحيحة.

ما كان مذهلاً هو وقت دورة التطوير والاختبار المنخفض للغاية.

لقد اعتدت على كتابة التعليمات البرمجية لفترة أفضل من ساعة قبل محاولة تجميعها أو تشغيلها. ولكن هنا تم تنفيذ التعليمات البرمجية واختبارها كل دقيقتين أو نحو ذلك.

وهكذا ، باختصار ، يتم تحقيق TDD من خلال دورات تطوير قصيرة تتبع القاعدة "اختبارات وحدة الكتابة الأولى ، ثم اكتب الكود ، ثم refactor ، ثم كرر". اختبارات الوحدة عبارة عن اختبارات آلية تحقق ما إذا كانت الوظائف تعمل كما هو متوقع أم لا. يجب أن يفشل اختبار الوحدة الأول نظرًا لأنه مكتوب قبل أن يكون لديك أي قاعدة بيانات.

قمت بإضافة قليلا إلى رمز حالة الاختبار. قمت بإضافة قليلا إلى رمز الإنتاج. تدفقات رمز اثنين تنمو في وقت واحد إلى مكونات تكميلية. تتناسب الاختبارات مع رمز الإنتاج مثل أن الجسم المضاد يناسب المستضد.

يمنع هذا التدبير المطورين من كتابة تعليمات برمجية غير ضرورية لا تتوافق مع الاختبار المحدد.

وهذا النهج المتكامل كله يقدم مجموعة من الفوائد للمطور.

يمكنك إصلاح رمز سيئة دون كسر أي شيء.

كلما رأيت كودًا سيئًا ، فأنت تغمض عينيك وتدعو إلى الله وتلفظ أحد العبارات.

· "هذه فوضى. أعتقد أنني يجب أن إصلاحه بطريقة ما ".

· "أنا لا أتطرق إليها."

في كلتا الحالتين ، هناك عنصر من عناصر الخوف. في الواقع ، عدم اليقين.

ماذا لو كان الكود الخاص بي يكسر الوظائف الحالية؟

TDD يساعدك على وجه التحديد للتغلب على عدم اليقين هذا.

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

وكلما زاد عدد التعليمات البرمجية الخاصة بك ، بذل جهد أقل في فريقك لإضافة ميزات جديدة أو تعديل قاعدة الشفرة الحالية.

TDD يفرض الوثائق.

ضرب ديك براندون ضجة على الظفر عندما لاحظ.

"التوثيق مثل الجنس ؛ عندما يكون جيدًا ، إنه جيد جدًا ، وعندما يكون سيئًا ، يكون أفضل من لا شيء ".

التوثيق هو زيت الخروع للبرمجة. المديرون يعتقدون أنه أمر جيد للمبرمجين والمبرمجين يكرهون ذلك!

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

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

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

TDD يساعد في تحسين التصميم

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

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

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

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

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

وحقيقة كتابة حالات الاختبار مقدمًا تمنع أي أخطاء قد تظهر في وقت لاحق ، مما يوفر الوقت والجهد وحرقة المعدة.

وأخيرا TDD يتبع أفضل ممارسات الترميز.

TDD يعزز مبادئ الترميز الجيدة بما في ذلك DRY ، KISS ، YAGNI و SOLID.

يخبر مبدأ DRY (لا تتكرر نفسك) المطورين بأن يتجنبوا تكرار نفس الكود في أجزاء مختلفة من نفس النظام ، ولهذا السبب يطلق عليه أحيانًا مبدأ DIE (Duplication Is Evil). يوصي DRY بأن يستخدم المطورون الفئات والوظائف لتغليف وظائف النظام والحفاظ على قاعدة بيانات ثابتة.

ينصح مبدأ KISS (Keep it Simple، Stupid!) المطورين بعدم إعادة اختراع العجلة ، ولكن بناء هياكل بسيطة وواضحة. جوهر KISS هو تجنب الحلول المفرطة التصميم.

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

يتكون SOLID من خمسة مبادئ في واحد: المسؤولية الفردية ، استبدال مفتوح ، استبدال Liskov ، فصل الواجهة ، وانعكاس التبعية. باختصار ، تنص SOLID على أن اتباع هذه المبادئ يجعل التطبيقات أسهل في الصيانة والاختبار.

باختصار ، يساعد TDD في إنشاء رمز أنيق وبسيط يسهل الحفاظ عليه.

كما قال روبرت مارتن باقتدار.

"يبدو الرمز النظيف دائمًا كما لو أنه كتبه شخص يهتم".

المراجع

البرمجة المتطرفة: كنت بيك.

رشيقة تطوير البرمجيات: روبرت مارتن

إعادة بيع المباني: مارتن فاولر

عن المؤلف-:

رافي راجان هو مدير عالمي لبرنامج تكنولوجيا المعلومات ومقره مومباي ، الهند. وهو أيضًا مدون متعطش ، وكاتب شعر هايكو ، وعشاق علم الآثار ، وهوس التاريخ. تواصل مع رافي على LinkedIn و Twitter و Medium.

تم نشر هذه القصة في The Startup ، أكبر منشور لريادة الأعمال في Medium ، يليه +383867 شخص.

اشترك لتلقي أهم الأخبار هنا.