database - كيف نفعل اختبار وحدة قاعدة البيانات؟




unit-testing database-testing (5)

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


ما هي أفضل الممارسات في اختبار وحدة قاعدة البيانات؟

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

ما هي الاهتمامات الرئيسية عند القيام باختبار وحدة ديسيبل

  • إنشاء مخطط محدث ، وإدارة تغييرات المخطط
  • إعداد البيانات (البيانات المرجعية وبيانات الاختبار) والحفاظ على بيانات الاختبار
  • حفظ الاختبارات مستقلة
  • السماح للمطورين بالعمل بشكل متزامن
  • السرعة (عادةً ما تكون الاختبارات التي تتضمن قاعدة بيانات أبطأ وستجعل البناء بالكامل يستغرق وقتًا أطول)

وكيف نفعل ذلك "صحيح"؟

كما هو تلميح ، اتبع الممارسات الجيدة المعروفة واستخدم أدوات / أطر عمل مخصصة:

  • تفضل في قاعدة بيانات الذاكرة إن أمكن (للسرعة)
  • استخدام مخطط واحد لكل مطور أمر ضروري (للسماح بالعمل المتزامن)
  • استخدم أداة "ترحيل قاعدة البيانات" (à la RoR) لإدارة تغييرات المخطط وتحديث المخطط إلى الإصدار النهائي
  • قم بإنشاء أو استخدام أداة اختبار تسمح بوضع قاعدة البيانات في حالة معروفة قبل كل اختبار وتنفيذ التأكيدات ضد البيانات بعد التنفيذ (أو لتشغيل الاختبارات داخل معاملة تقوم باسترجاعها في نهاية الاختبار).

ألق نظرة على هذا الرابط . يتخطى بعض الأساسيات لإنشاء وحدة اختبار procs المخزنة في SQL Server وكذلك أنواع مختلفة من اختبارات الوحدة ومتى يجب عليك استخدامها. لست متأكدًا من قواعد البيانات التي تستخدمها ولكن من الواضح أن هذه المقالة موجهة نحو SQL Server.

سرقت من المقال:

اختبارات الميزة

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

اختبارات المخطط

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

اختبارات الأمن

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

اختبارات بيانات الأسهم

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


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

وبالتالي ، يمكن إعادة إنتاج حالة الوصول إلى قاعدة البيانات للاختبار ، وبدون وجود DB الهدف: لا يوجد تعقيد لعزل الاختبار / البيانات ، مما يسهل التكامل المستمر.

إطار عمل Acolyte الخاص بي هو إطار عمل مفيد بهذه الطريقة (بما في ذلك أداة واجهة المستخدم الرسومية في الاستوديو لتسجيل نتائج قاعدة البيانات): https://github.com/cchantep/acolyte


قائمة بالعناصر التي يجب مراجعتها والنظر فيها عند بدء اختبار وحدة قاعدة البيانات

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

إذا تم تطبيق الاختبار باستخدام إطار عمل tSQLt ، فقد تكون عملية اختبار الوحدة معقدة عند التعامل مع الكثير من قواعد البيانات من مثيلات SQL Server متعددة. من أجل الحفاظ على وتنفيذ اختبارات الوحدة مباشرة من SQL Server Management Studio ، يمكن استخدام ApexSQL Unit Test كحل


يمكنني استخدام junit / nunit / etc واختبار كود وحدة قاعدة البيانات مع جافا أو c #. يمكن بعد ذلك تشغيلها على خادم تكامل ربما باستخدام مخطط منفصل لقاعدة بيانات الاختبار.

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

الممارسات الجيدة تشبه اختبارات الوحدة العادية:

  • وضع الاختبارات تحت سيطرة المصدر
  • قم بإجراء اختبارات سريعة - لا تختبر الكثير في وقت واحد
  • جعل الاختبارات الخاصة بك استنساخه






database-testing