التركيبات والسيلينيوم والقضبان (يا بلدي؟)

Question

ما هي البيانات التي تستخدمها مع اختبارات السيلينيوم على تطبيقات Rails؟ هل تحميل من التركيبات؟ هل تستخدم DEV DB موجود؟ هل تستخدم ديسيبل منفصل (غير محدود)؟

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

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

تعديل: كنت أنوي في الأصل تحميل التركيبات قبل كل اختبار وتفريغها بعد كل اختبار ، مثل اختبارات القضبان العادية. لكن الأمر يستغرق حوالي 15 دقيقة لتحميل التركيبات بسبب بيانات التقارير هذه. هناك 200 اختبار ، ويتم تشغيل الجناح كل 12 ساعة. أنا cannae bend spacetime captain!

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

حتى لو كانت مجموعة صغيرة من البيانات ، على الرغم من أنها لا تزال مجموعة أخرى للحفاظ على تنسيق مع تغييرات المخطط. (لدينا مجموعة منفصلة وأصغر للوحدة والوظيفية و [القضبان] اختبارات التكامل.)

ما الذي يعيدني إلى سؤالي الأصلي - هل هناك خيارات أخرى إلى جانب القيام بذلك باليد ، أو تذكر تجديدها في كل مرة؟

Answer 1

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

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

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

يقوم Rails بعمل جيد مع هذا بالفعل مع الترحيل ، لذلك استفد منها! دون معرفة وضعك ، سأتساءل عمومًا عن الحاجة إلى إجراء اختبارات السيلينيوم مقابل مجموعة من DB الكاملة. يمكن تقطير معظم DBS (أو يجب) إلى أقل من 1 ميغابايت للاختبار الآلي ، مما يجعل ترحيل المخطط الآلي وإعادة ضبط البيانات أكثر كفاءة.

المرة الوحيدة التي رأيت فيها سببًا "صالحًا" ل DBS الضخمة لاختبارات السيلينيوم هو عندما يحتوي DB نفسه على أجزاء كبيرة من "بيانات المنطق" التي تؤثر عليها البيانات على تدفق التطبيق (فكر: واجهة المستخدم التي تعتمد على البيانات).

Answer 2

أعتقد أنك تطرح سؤالين هنا متشابكين ، لذا إذا كنت سأقوم بتفكيكه:

• تريد الحصول على بيانات الاختبار داخل وخارج DB بسرعة وأن المباريات لا تفعل ذلك من أجلك.
• لقد تم إحراقك بسبب تغيير المخطط وتريد التأكد من أن كل ما تفعله لا يتطلب ثمانية تكرارات تحت عنوان "العبث ببيانات الاختبار ... :) :)

لقد حصلت على بديلة هنا والتي قمت بتوضيحها أدناه. نظرًا لأنك ذكرت Oracle أنا أستخدم Oracle Technologies هنا ولكن الشيء نفسه صحيح بالنسبة لمنصات DB الأخرى (مثل PostgreSQL):

1. Rake Tesks التي تستدعي البرامج النصية PL/SQL لإنشاء البيانات ، فكرة شريرة مروعة ، لا تفعل ذلك إلا إذا لم يكن هناك خيار آخر. لقد فعلت ذلك في مشروع واحد يحتاج إلى تحميل بمليارات الصفوف لبعض اختبارات بنية البنية التحتية. ما زلت أزعجها.
2. الحصول على DB الخاص بك في تنسيق تفريغ. لمقالب الثنائية السريعة ، تحقق من مرافق EXP/IMP ومضخة البيانات. سيتيح لك هذا الإعداد السريع والدموع من DB الخاص بك. بالتأكيد في مشروع Rails الذي عملت عليه ، استخدمنا مهام Rake لـ EXP/IMP قاعدة بيانات تضم حوالي 300 ألف سجل في أقل من دقيقة. تحقق أيضا من SQLالمحمل الذي هو أداة تفريغ منطقية ، باعتبارها منطقية أبطأ وتتطلب منك أن يكون لديك نصوص تحكم لمساعدة SQLLoader فهم المقالب. ومع ذلك ، فإن فائدة التفريغ المنطقي هي أنه يمكنك تشغيل البرامج النصية للتحويل عليها لتدليك البيانات في أحدث تنسيق. للأسف ، على الرغم من مثل المباريات ، فإن كل هذه الأدوات حساسة للغاية للتغيير في المخطط.
3. استخدم البرنامج المساعد مثل الميكانيكي أو فتاة المصنع لجعل توليد البيانات أجمل. ما زلت تتحمل عقوبة استخدام ActivereCord لإعداد DB ، لكن مولدات الكائنات المزيفة هذه ستساعدك على البقاء على مقربة من الترحيل وأقل مشكلة في الحفاظ عليها من التركيبات.
4. الجمع بين الأساليب 2 و 3. ما يحدث هنا هو إجراء بعض بيانات الاختبار مع Machinst Say. تقوم بتصدير بيانات الاختبار هذه إلى تفريغ ثم إعادة تحميل التفريغ أثناء كل عملية اختبار. عندما يغير المخطط تحديث التكوين الميكانيكي وإعادة التصدير.

امل ان يساعد.

Answer 3

أنا حاليًا في مشروع مع مجموعة اختبار سيلينيوم هائلة-في الواقع ، تمت كتابة شبكة السيلينيوم الواحدة-وتستخدم اختباراتنا كمية صغيرة من البيانات المرجعية (على الرغم من أننا لا نستخدم تجهيزات Yaml Rails) ومصانع الكائنات لبيانات لمرة واحدة اللازمة لاختبارات معينة.

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

انظر على سبيل المثال بول جروس أشعل النار مهام ارتكاب على جيثب.