نموذج كائن المكون (COM) هو نمط تصميم يسمح لك بتنظيم الاختبارات في مشاريع الأتمتة الاختبارية. مستلهم من نمط نموذج كائن الصفحة الشهير (POM)، يتجاوز COM التعامل مع صفحات بأكملها ويركز على مكونات واجهة المستخدم الخاصة، مثل الأزرار، حقول النص، قوائم السحب، أو عناصر أخرى قابلة لإعادة الاستخدام.
في هذا البرنامج التعليمي، سنشرح كيفية تنفيذ COM لاختبار تطبيق ويب باستخدام مشغل Selenium وCucumber وكيف يمكن لهذا النهج جعل اختباراتك أكثر مرونة وقابلية للتوسيع، وأسهل في الصيانة.
ما هو نموذج كائن المكون؟
نموذج كائن المكون (COM) هو تطور لنموذج POM. بدلاً من تصميم صفحة بأكملها ككائن يتفاعل مع جميع عناصر الصفحة، يقسم COM واجهة المستخدم إلى مكونات فردية، مثل:
- أزرار
- حقول نص
- قوائم السحب
- أشرطة البحث
- جداول
كل مكون محاط في فئة جافا، وتتم إدارة تفاعلاته بواسطة طرق محددة، مما يسمح بالحفاظ على كل عنصر واختباره بشكل مستقل. هذا يحسن من إعادة استخدام الكود، والصيانة، والمرونة في الاختبارات.
لماذا نستخدم COM بدلاً من POM؟
1. زيادة قابلية التعديل
مع COM، كل مكون (مثل زر أو حقل نصي) هو كيان مستقل. إذا تغير مكون (على سبيل المثال، تغير نص الزر)، تحتاج فقط إلى تعديل فئة المكون دون التأثير على المكونات أو الصفحات الأخرى. هذا يسمح بمرونة عالية ويمنع الحاجة إلى تعديل صفحات كاملة لتعديلات بسيطة.
2. إعادة الاستخدام والمرونة
يمكن إعادة استخدام المكونات عبر صفحات متعددة من التطبيق، مما يقلل من تكرار الكود. على سبيل المثال، يمكن استخدام ButtonComponent في أي صفحة يظهر فيها الزر، مما يقلل من التكرار ويزيد من مرونة الاختبار.
3. صيانة مبسطة
الصيانة أسهل مع COM. إذا تغير مكون (على سبيل المثال، زر أو حقل نصي)، تحتاج فقط إلى تعديل الفئة التي تمثل ذلك المكون. سيتم تحديث جميع الاختبارات التي تستخدم ذلك المكون تلقائيًا دون الحاجة إلى مراجعة كل سيناريو اختبار.
4. متكيف مع الواجهات الديناميكية
التطبيقات الحديثة غالبًا ما تكون ديناميكية، مع واجهات تتغير بشكل متكرر. COM هو مثالي لمثل هذه التطبيقات لأنه يسمح باختبار المكونات بشكل مستقل عن الواجهة. يمكنك تعديل أو إضافة مكونات دون التأثير على الاختبارات لأجزاء أخرى من التطبيق.
5. تسريع عمليات الاختبار التلقائي
يسرع COM عمليات الاختبار التلقائي. من خلال تركيز التفاعلات مع المكونات في فئات قابلة لإعادة الاستخدام، لا يحتاج فاحصون إلى إعادة تعريف الإجراءات لكل صفحة أو مكون. على سبيل المثال، تعريف خطوة واحدة لإجراء “نقر على زر” يمكن استخدامه في جميع الاختبارات في المشروع، مما يقلل بشكل كبير من الوقت اللازم لتلقين الاختبارات تلقائيًا.
6. تجنب تكرار العمل بين الفاحصين
مع COM، لم يعد الفاحصون بحاجة لتكرار نفس العمل في كل اختبار. يمكن استخدام تعريفات الخطوات المركزية للإجراءات الشائعة، مثل “نقر على زر” أو “إدخال نص”، من قبل جميع الفاحصين في المشروع. يضمن ذلك توحيد الاختبارات مع تجنب التكرارات غير الضرورية، مما يعزز الكفاءة والتعاون بين الفاحصين.
هندسة مشروع COM
تتمحور هندسة مشروع قائم على COM حول ثلاث عناصر رئيسية: المكونات، تعريفات الخطوات، و المشغل.
1. المكونات
كل مكون يمثل عنصر واجهة مستخدم، مثل زر، مجال نصي، أو قائمة منسدلة. تقوم هذه الفصول بتجسيد جميع التفاعلات الممكنة مع العنصر.
ها هو مثال عن فئة ButtonComponent:
public class ButtonComponent {
private WebDriver driver;
public ButtonComponent(WebDriver driver) {
this.driver = driver;
}
public void clickButton(String buttonText) {
WebElement button = driver.findElement(By.xpath("//button[text()='" + buttonText + "']"));
button.click();
}
}
2. تعريفات الخطوة
تعريفات الخطوةتربط الخطوات المعرفة في ملفات Gherkin بالأساليب في المكونات. إنها مسؤولة عن التفاعل مع المكونات وتنفيذ الإجراءات المحددة في سيناريو الاختبار.
ها هو مثال عن ButtonStepDefinition:
public class ButtonStepDefinition {
private ButtonComponent buttonComponent;
public ButtonStepDefinition(WebDriver driver) {
this.buttonComponent = new ButtonComponent(driver);
}
@When("I click on the button {string}")
public void iClickOnTheButton(String buttonText) {
buttonComponent.clickButton(buttonText);
}
}
3. المشغل
فئة المشغل مسؤولة عن تشغيل الاختبارات باستخدام JUnit أو TestNG. يقوم بتكوين Cucumber لتحميل سيناريوهات الاختبار المعرفة في ملفات .feature وتشغيلها باستخدام تعريفات الخطوة.
ها هو مثال عن TestRunner:
@RunWith(Cucumber.class)
@CucumberOptions(
features = "src/test/resources/features",
glue = "com.componentObjectModel.stepDefinitions",
plugin = {"pretty", "html:target/cucumber-reports.html"}
)
public class TestRunner {
}
كتابة وشرح سيناريو Gherkin
إحدى عناصر الأساسية للتحكم التلقائي بـ Cucumber هي استخدام لغة Gherkin لكتابة سيناريوهات الاختبار. تتيح لك Gherkin وصف الاختبارات بطريقة قابلة للقراءة والفهم، حتى لغير المتخصصين تقنيًا.
لنفترض سيناريوًا حيث نريد اختبار التفاعل مع زر باستخدام ButtonComponent الذي قمنا بتعريفه سابقًا. هكذا قد يُكتب بلغة Gherkin:
Scenario: User clicks on the "Submit" button Given I am on the login page When I click on the button "Submit" Then I should be redirected to the homepage
شرح السيناريو
السيناريو
يصف هذا السيناريو الإجراء الذي يقوم به المستخدم عند النقر على زر “إرسال” في صفحة تسجيل الدخول ويضمن أنه يتم توجيهه إلى الصفحة الرئيسية بعد النقر.
- بما أنني على صفحة تسجيل الدخول: الحالة الأولية للاختبار هي أن المستخدم على صفحة تسجيل الدخول.
- عندما أنقر على الزر “إرسال“: الإجراء الذي يتم تنفيذه في الاختبار هو النقر على زر “إرسال”.
- ثم، يجب أن يتم توجيهي إلى الصفحة الرئيسية: التحقق المتوقع هو أن يتم توجيه المستخدم إلى الصفحة الرئيسية بعد النقر على الزر.
رابط مع COM
كل خطوة في هذا السيناريو مرتبطة بتعريف خطوة step definition في ButtonStepDefinition، حيث يتم التعامل مع إجراء النقر بواسطة ButtonComponent، مما يجعل الاختبار modular وسهل الصيانة.
شرح إضافي
لاحظ أن الخطوات تأخذ النص المعروض على الأزرار (أو العناصر النائبة في حقول الإدخال، إلخ) كمعلمات. يجعل هذا السيناريوهات أكثر قراءة وعمومية. على سبيل المثال، في السيناريو أعلاه، يتم استخدام نص زر “إرسال” مباشرة في الخطوة “عندما أنقر فوق الزر ‘إرسال’.” بهذه الطريقة، يمكن إعادة استخدام نفس تعريف الخطوة لاختبار زر آخر، مثل “تسجيل الدخول،” من خلال ببساطة تغيير النص في سيناريو Gherkin. يحسن هذا من إمكانية إعادة استخدام كود الاختبار مع جعل السيناريوهات أكثر بديهية ومرنة.
قابلية إعادة الاستخدام للخطوات مع COM
إحدى المزايا الرئيسية لـ COM هي إمكانية إعادة استخدام تعاريف الخطوات لأزرار مختلفة. على سبيل المثال، يمكن استخدام نفس الخطوة عندما أنقر على الزر {string} لجميع الأزرار، بغض النظر عن النص المعروض على الزر. يسمح النهج COM لك بتحديد المعلمات ديناميكيًا لإجراء النقر بناءً على نص الزر.
لننظر إلى سيناريو آخر يتضمن زرًا مختلفًا:
سيناريو
User clicks on the "Login" button
Given I am on the login page
When I click on the button "Login"
Then, I should be redirected to the dashboard
في كلا الحالتين، سيتم استخدام نفس الطريقة انقر_الزر في مكون_الزر، ولكن سيتغير نص الزر اعتمادًا على السيناريو. يظهر هذا كيف يسمح COM بإعادة استخدام نفس المكون وتعريف الخطوة، مما يجعل الاختبارات مرنة وقابلة للتعديل.
كيف يحسن COM الأتمتة في الاختبار
تحسن COM أتمتة الاختبار بعدة طرق:
- تقليل تكرار الكود: من خلال استخدام مكونات قابلة لإعادة الاستخدام، تقلل من تكرار الكود في الاختبارات. على سبيل المثال، مكون
ButtonComponentالمستخدم في عدة صفحات من التطبيق يلغي الحاجة لكتابة اختبارات متكررة. - اختبارات أكثر قراءة وقابلية للتعديل: الاختبارات أكثر وضوحًا وأسهل في الفهم حيث أنها مفصولة عن تفاصيل التنفيذ الخاصة بالصفحات. يمكنك التركيز على التفاعل مع المكونات دون القلق بشأن بنية الصفحة الأساسية.
- سهولة الصيانة: أي تعديل على مكون (مثل تغيير نص الزر) يؤثر فقط على فئة المكون، وليس على الاختبارات. هذا يجعل الصيانة أبسط وأسرع بكثير.
- اختبارات أكثر مرونة: يمكن بسهولة تكييف الاختبارات مع واجهات المستخدم المتغيرة، حيث أن المكونات مستقلة عن بعضها البعض. يمكنك اختبار مكونات جديدة أو استبدال المكونات الموجودة دون التأثير على اختبارات أخرى.
متى يُوصى بنمط تصميم COM؟
يُوصى بهذا النمط التصميمي إذا كانت تطبيقات الويب التي يتم اختبارها تستخدم نظام تصميم موحد لجميع المكونات. على سبيل المثال، إذا تم إعلان جميع الأزرار بنفس الطريقة، مع هيكل متسق لجميع عناصر واجهة المستخدم. في مثل هذه الحالات، يسمح لك استخدام COM بتركيز التفاعلات مع كل نوع من المكونات (مثل الأزرار، حقول النص، إلخ)، مما يجعل الاختبارات أكثر وحدوية، قابلة لإعادة الاستخدام، وأسهل في الصيانة.
إعادة استخدام تعاريف الخطوات عبر عدة منتجات
إذا كنت تقوم بتطوير واختبار عدة منتجات تستخدم نفس نظام التصميم، يمكنك إنشاء مكتبة تضم جميع تعاريف الخطوات والإجراءات (أو معظمها) لكل مكون. يتيح هذا للمحققين التركيز فقط على كتابة سيناريوهات Gherkin، وستتم الاختبارات تلقائيًا. نظرًا لأن جميع عناصر الويب مكتوبة بنفس الطريقة (HTML)، ستتصرف المكونات مثل الأزرار وحقول النص وعناصر واجهة المستخدم الأخرى بشكل متسق عبر جميع المشاريع.
ونتيجة لذلك، لم يعد المحققون بحاجة إلى تكرار نفس المهام – تعريف تعاريف الخطوات والإجراءات للمكونات المتطابقة عبر عدة مشاريع. يوفر هذا النهج الوقت ويعزز قابلية الصيانة. إذا تم تعديل عنصر الويب (على سبيل المثال، إذا تغير XPath)، يجب عليك فقط تحديث ذلك العنصر في المكتبة المشتركة، وسيتم تطبيق التعديل تلقائيًا على جميع مشاريع الأتمتة. يقلل هذا من مخاطر الأخطاء ويجعل التحديثات أكثر كفاءة عبر منتجات مختلفة.
الاستنتاج
نموذج الكائن المكون (COM) هو نمط تصميم قوي لتنظيم الاختبارات التلقائية. من خلال التركيز على المكونات القابلة لإعادة الاستخدام، يتيح COM لك إنشاء اختبارات أكثر تعددًا وقابلية للصيانة والتوسع. يكون هذا النمط مفيدًا بشكل خاص للتطبيقات الحديثة، حيث تتغير واجهة المستخدم بسرعة، وحيث التفاعل مع المكونات المستقلة أمر ضروري.
مع الاختبارات القابلة لإعادة الاستخدام، والصيانة المبسطة، والعمارة المرنة، COM هو الحل المثالي لأتمتة الاختبارات في مشاريع Selenium و Cucumber.
Source:
https://dzone.com/articles/com-design-pattern-selenium-and-cucumber