إتقان مبادئ التطوير القائم على الاختبار (TDD)

في عملية تطوير البرمجيات، يعد الاختبار أحد أهم العناصر في عملية تطوير البرمجيات. وللتأكيد على أهمية الاختبار، هناك تقنية لتطوير البرمجيات تسمى TDD أو التطوير المدفوع بالاختبار. تشجع هذه التقنية على كتابة متطلبات البرمجيات كاختبارات كخطوة أولية في تطوير الكود. الفكرة هنا بسيطة. يجب أن ينصب اهتمامك على الاختبار أولاً. عندما تستخدم مؤسستك تقنية TDD، يجب عليك أولاً استخدام الاختبار لشرح سلوك البرنامج ثم يجب عليك التحقق منه واكتشاف أي أخطاء محتملة. فقط بعد الانتهاء من الاختبار، يمكنك المضي قدمًا في التنفيذ الحقيقي لتلبية احتياجات الاختبار. قبل أن تفهم مبادئ التطوير المدفوع بالاختبار، من الأفضل أن تفهم أولاً أساسيات تقنية تطوير البرمجيات هذه.
التطوير المدفوع بالاختبار – المعنى:
يُطلق عليه باختصار وبشكل شائع TDD، وهو ليس سوى ممارسة لتطوير البرمجيات من خلال كتابة الاختبارات في البداية ثم المضي قدمًا بأقل قدر من التعليمات البرمجية اللازمة لتجاوز الاختبارات. بعبارات بسيطة، عندما تستخدم هذه التقنية، سيكون عليك أولاً كتابة متطلباتك بوضوح. بعد ذلك، يجب عليك كتابة الأكواد التي يمكن أن تساعدك على تلبية تلك المتطلبات.
بالإضافة إلى ذلك، فإن تقنية التطوير المدفوع بالاختبار تحفز أيضًا الممارسات الجيدة الأخرى مثل كتابة التعليمات البرمجية الوظيفية كلما أمكن ذلك. حتى أنها توصي باستخدام حقن التبعية. والسبب هو أن هذه الممارسات ستجعل من السهل اختبار التعليمات البرمجية الخاصة بك. حتى أن هذا الاستخدام سيكون مفيدًا في جعل التعليمات البرمجية الخاصة بك أكثر قابلية لإعادة الاستخدام، في حين أن الاختبار سيجعل عمليات إعادة الهيكلة المستقبلية أقل إرهاقًا إلى حد كبير.
تعرّف على القواعد الثلاث لـ TDD
في هذه العملية لتعلم مبادئ TDD، يجب أن تكون على دراية بالقواعد الثلاث لمنهجية تطوير البرمجيات هذه:
1. إذا فشل اختبار الوحدة، يجب عليك كتابة كود المنتج فقط لاجتياز اختبار الوحدة.
2. يجب ألا تكتب المزيد من اختبارات الوحدة. يجب أن تكتب فقط تلك الأرقام التي يمكنك إدارتها إذا كان هناك فشل.
3. يجب عليك عدم كتابة المزيد من أكواد الإنتاج مقارنةً بما هو مطلوب لاجتياز اختبار وحدة واحد فاشل.
خطوات التطوير القائم على الاختبار:
قبل إلقاء بعض الضوء على مبادئ TDD Agile، من الأفضل أن تفهم أولاً الخطوات الخمس التي ينطوي عليها تدفق التطوير المدفوع بالاختبار:
1. أول شيء عليك القيام به هو قراءة وفهم طلب الخطأ أو الميزة من العملاء.
2. بمجرد فهم المتطلبات بدقة، ترجمها من خلال إنشاء اختبار وحدة. في حال كان لديك إعداد إعادة تحميل ساخن، سيفشل اختبار الوحدة عند تشغيله. هل يمكنك الحكم على السبب؟ نعم، يفشل لأنه لم يتم تنفيذ أي شيفرة حتى الآن.
3. الآن، اكتب الآن ونفذ الشيفرة التي تلبي المتطلبات. ثم، قم بتشغيل جميع الاختبارات والآن يجب أن تنجح. إذا لم تنجح بعد، فسيتعين عليك تكرار الخطوات حتى تنجح.
4. بمجرد اجتيازها، نظف شفرتك البرمجية. يمكنك القيام بذلك عن طريق إعادة الهيكلة.
5. أخيرًا، اشطفها ثم اغسلها واتبع الخطوات مرة أخرى.
يمكنك فهم العملية بشكل أفضل من خلال الصورة أدناه:
يُعرف سير العمل في الصورة أعلاه باسم إعادة الهيكلة باللون الأحمر والأخضر. إنها نتيجة لحالة الاختبارات داخل الدورة. هنا، تشير المرحلة الحمراء هنا إلى أن الشيفرة لا تعمل. المرحلة الخضراء هي إشارة إلى أن كل شيء يعمل. ومع ذلك، فهي لا تعمل على النحو الأمثل. تشير المرحلة الزرقاء إلى أن المختبِر يقوم بإعادة هيكلة الكود. ومع ذلك، فإن المختبر واثق من أن الكود الخاص به مغطى بالاختبارات. وبهذه الثقة، يكون لدى المختبر القدرة على تغيير أو تحسين الكود حسب الحاجة.
ما الذي يجعل تطوير TDD أسهل وأسرع؟
إن مبادئ التطوير المدفوع بالاختبار لا تجعل التطوير TDD أسهل وأسرع فحسب بل تجعلها أسرع أيضًا.
وقد اكتسبت TDD شعبية كتقنية مفيدة لتصميم وتطوير البرمجيات للتأكد من اختبار قاعدة التعليمات البرمجية بشكل كافٍ ورصدت الاختبارات سلوكها أيضًا.
الشكوى الأكثر شيوعًا من مستخدمي TDD هي أنهم يواجهون صعوبات في الحفاظ على التعليمات البرمجية. على سبيل المثال، يواجهون مشاكل في إعادة الهيكلة، وإصلاح الأخطاء، وإضافة ميزات جديدة، وما إلى ذلك. المشكلة التي يواجهونها هي أن هناك الكثير من الاختبارات وبالتالي يضطرون لقضاء معظم ساعات عملهم في إصلاح الاختبارات.
وقد يحدث هذا في بعض الأحيان عندما تحاول الاختبارات التقاط المزيد من السلوكيات مقارنةً بما يجب أن تكون عليه. في الواقع، يجب تحسين تصميم التطبيق لتحديد حدود الصلاحيات التي يمكن اختبارها بسهولة. إن أفضل حالة يمكن تحقيقها هي الحالة التي تلتقط فيها اختباراتك كامل سلوك البرنامج دون أي تضحية في صيانة الكود بحيث يمكن لفرق التطوير أن تتوجه بسرعة.
عند الانخراط في تطوير البرمجيات باستخدام نهج TDD، فإنك ستقوم بتصميم البرنامج باستخدام مبادئ تصميم SOLID لـ TDD والتي ستؤدي إلى اختبارات أقل بشكل عام والتي ستكون في وضع أفضل لالتقاط سلوك البرامج التي تقوم بتطويرها.
مبادئ SOLID للتطوير المدفوع بالاختبار – ماذا يعني ذلك؟
ربما تكون قد سمعت عن البرمجة القصوى إذا كنت تعمل في مجال تطوير البرمجيات. TDD هو أحد المستلزمات الرئيسية لـ XP، والذي اكتسب شعبية هائلة في مجال تطوير البرمجيات.
إذا كنت ترغب في معرفة مبادئ TDD، يجب أن تعرف عن SOLID. إنه ليس سوى اختصار لخمسة مبادئ تصميم رئيسية تجعل من السهل فهم الكود واختباره وصيانته. والأهم من ذلك أن هذه المبادئ ستجعل الكود أكثر مرونة أيضًا. مبادئ SOLID مذكورة أدناه:
1. مسؤولية واحدة
2. مفتوحة/مغلقة
3. استبدال ليسكوف
4. الفصل البيني
5. حقن التبعية
دعونا نفهم بعض مبادئ TDD الرشيقة هذه هنا:
1. مبدأ المسؤولية الواحدة:
بناءً على هذا المبدأ، يجب أن يتضمن الفصل مسؤولية واحدة. هذا المبدأ سيجعل كل فئة بسيطة جداً للاختبار. من من منظور التطوير المدفوع بالاختبار، يجعل هذا المبدأ من السهل شرح سلوك كل فئة تستخدم الاختبارات.
الهدف من هذا المبدأ هو إنشاء اختبارات تحدد السلوك الفريد لكل فئة يتم تنفيذها. سيساعد ذلك في تقليل اختبار السلوك الزائد عن الحاجة عبر طبقات أو أجزاء مختلفة من البرنامج.
2. مبدأ مفتوح/مغلق:
وفقًا لهذا المبدأ، يجب أن تبقى كيانات البرنامج الذي يتم تطويره مفتوحة للإضافات. ولكن، يجب أن تبقى مغلقة للتعديلات. ويصر هذا المبدأ على أن المطورين يجب أن يكونوا قادرين على إضافة ميزات جديدة إلى البرنامج دون إجراء أي تغييرات على الكود الموجود بالفعل.
من وجهة نظر TDD، سيتعين علينا فقط إنشاء اختبارات وحدة لاختبار واكتشاف سلوك الميزة الجديدة. لا نحتاج إلى إضافة أي اختبارات جديدة لاختبارها لأن السلوك يبقى دون تغيير لهذه الفئة.
3. مبدأ استبدال ليسكوف:
استنادًا إلى هذا المبدأ، يجب أن تكون الكائنات في البرنامج قابلة للاستبدال بنماذج من أنواعها الفرعية. ولكن، يجب أن يكون ذلك ممكنًا دون إجراء أي تغييرات على صحة البرنامج. يرتبط هذا المبدأ بمبدأ الفتح/الإغلاق الذي تمت مناقشته أعلاه. وللدقة فإنه ينص على أن أجزاء الفئة الفرعية يجب أن تكون قابلة للاستبدال بكائنات من فئاتها الفرعية دون أن يؤدي ذلك إلى كسر التطبيق. هذا يتطلب أن تتفاعل كائنات الفئات الفرعية بنفس الطريقة التي تتفاعل بها أجزاء الفئة الفائقة. يشير هذا المبدأ، من وجهة نظر TDD، إلى أن اختبارات الوحدة يجب أن تُكتب فقط للميزة الجديدة. والسبب في ذلك هو عدم المخاطرة بكسر الأجزاء الأخرى من البرنامج.
4. مبدأ فصل الواجهة:
في مقابل واجهة واحدة للأغراض العامة، فإن العديد من الواجهات الخاصة بالعميل هي الأفضل وفقًا لهذا المبدأ. وفقًا لهذا المبدأ، يجب تقسيم البرنامج عن طريق شرح واجهة جديدة مقابل إضافة تقنية جديدة إلى الواجهة الحالية.
5. مبدأ حقن التبعية:
وفقًا لهذا المبدأ، يجب ألا تعتمد العناصر عالية المستوى على العناصر منخفضة المستوى. يجب أن تعتمد العناصر عالية المستوى ومنخفضة المستوى على العناصر التجريدية. لا يجب أن تعتمد التجريدات على التفاصيل. وبدلاً من ذلك، يجب أن تعتمد التفاصيل على التجريدات.
نقاط التعلم الرئيسية:
من النقاط المهمة التي يجب تذكرها حول TTD هو ابتعاده بالكامل عن تقنيات تطوير البرمجيات التقليدية. نعم، فمقابل كتابة جميع الأكواد في البداية وتشغيل الاختبارات في النهاية، فإن الهدف الأساسي من TDD هو السماح للاختبارات بالقيام بمهمة قيادة بنية الكود. أحد الأشياء المثيرة للاهتمام حول TDD هو طبيعته التكرارية والاعتماد المستمر لحلقة الأحمر والأخضر وإعادة التصحيح التي تساعد الشركات على اكتشاف أي أخطاء أو مشكلات في وقت مبكر من العملية.
كيف يتناسب TDD مع التطوير الرشيق؟
يصر التطوير الرشيق على التغذية الراجعة المنتظمة. في المقابل، يمكن تطوير المنتج المتوقع بإتقان. نظرًا لطبيعة التطوير الرشيق هذه، يُطلق عليه أيضًا التطوير المدفوع بالتغذية الراجعة. تكون احتمالية احتياج المشروع للتغيير أثناء دورة سباق التطوير أكثر. وللتعامل مع ذلك ولتطوير منتجات تتماشى مع المتطلبات المتغيرة للعملاء، يجب أن تحصل الفرق على تغذية راجعة مستمرة لمنع إصدار تطبيقات لا يمكن استخدامها. مع TDD، من الممكن الحصول على هذه الملاحظات في وقت مبكر من دورة التطوير.
علاوة على ذلك، يساعد نهج الاختبار أولاً في TDD في التخفيف من العوائق الحاسمة التي تعترض طريق تسليم جودة التطبيق الذي يتم تطويره. مع إصلاحات الأخطاء المستمرة والتعليقات والميزات الإضافية، يتحسن النظام للتأكد من أن كل شيء يعمل وفقًا للتوقعات. يعمل TDD على تحسين الارتباط بين أعضاء الفريق من فريقي ضمان الجودة والتطوير وحتى مع العميل. علاوة على ذلك، نظرًا لأن الاختبارات يتم إنشاؤها مسبقًا، لا تحتاج الفرق إلى قضاء الوقت في إعادة إنشاء نصوص اختبار شاملة.
SPOTO هي إحدى الشركات الرائدة في مجال التدريب الاحترافي في العالم التي تقدم دورات متعددة تتعلق بمنهجيات أجايل. نحن نقدم العديد من الدورات التدريبية المتعلقة بالأجايل مثل التدريب على شهادة Scrum Master (CSM)®، والتدريب على شهادة مالك منتج Scrum المعتمد (CSPO)®، والتدريب على شهادة مطور Scrum المعتمد (CSD)، والتدريب على شهادة Agile and Scrum، والتدريب على شهادة PMI-ACP®، والتدريب على شهادة PMI-ACP®، والتدريب على شهادة Scrum الاحترافية مع Kanban™ (PSK)، والتدريب على شهادة محترف Scrum® – مالك المنتج (CSP®-PO)، والتدريب على إدارة المبيعات الرشيقة، والتدريب على التطوير المدفوع بالسلوك (BDD) وغيرها الكثير. تقدم SPOTO التدريب لكل من الأفراد ومجموعات الشركات من خلال الفصول الدراسية التي يقودها مدربون والجلسات الافتراضية عبر الإنترنت.