لماذا اتجهت إلى البرمجة الموجهة بالأختبار؟

خلال فترة تدريبي وعملي المدة الماضية، قمت بتعلم ومتابعة دروس بمنصة laracasts عن البرمجة الموجهة للإختبار بإطار العمل laravel الذي أيضا يستخدم إطار العمل phpunit لكتابة الاختبارات والتي كانت شاملة لعدة مواضيع Unit Testing، feature testing or regression testing Mocking, وغيرها من المواضيع التقنية، كنت قبلها قد بدأت بمحاولات بسيطة لتعلمها ولكني لم أنشئ تطبيق كامل باستخدام البرمجة الموجهة للإختبار TDD، فكانت هذه هي بدايتي بها والتي وأود من من خلال هذه المقالة مشاركة هذه التجربة وما تعلمته منها وبالطبع سأشارك معكم مزاياها التي جعلتني أقرر الإتجاه إلى البرمجة بالإختبار.

ماهي البرمجة الموجهة بالإختبار TDD؟

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

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

1- ترسم لك الطريق لبداية كتابة الكود.

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

/**
 *@test
*/
   function user_can_not_delete_a_post()
   {
       $post = create('App\Post);

       $this->signIn(create(User::class, ['is_admin' => 0]));

       $this->delete('/posts/' . $post->id)
           ->assertRedirect('/home');

       $this->assertDatabaseHas(posts, $post->toArray());
   }

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

2. تقليل Bugs

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

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

• يستطيع المستخدم العادي عرض كل المقالات
• يستطيع المستخدم العادي تعديل مقالاته فقط
• يستطيع المدير عرض كل المقالات
• لا يستطيع المدير تعديل مقالات مستخدمين آخرين فهكذا نحن نقوم بكتابة دوال اختبار لتغطية كافة الاحتمالات التي تخطر على بالنا، والذي بالتأكيد سيقلل من نسبة الأخطاء بالتطبيق.
  
  4. يعطيك الثقة

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

5. يعتبر بمثابة توثيق للكود البرمجي

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

6. إضافة طلبات الزبون براحة ودون القلق

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