كيفية إجراء اختبار وحدة قاعدة البيانات؟

Question

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

Answer 1

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

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

ما هي المخاوف الأساسية عند إجراء اختبار وحدة DB

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

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

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

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

Answer 2

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

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

إذا تم تنفيذ الاختبار باستخدام TSQLT Framework ، فقد تكون عملية اختبار الوحدة معقدة عند التعامل مع الكثير من قواعد البيانات من مثيلات خادم SQL متعددة. من أجل الحفاظ على اختبارات الوحدة وإدارتها مباشرة من استوديو إدارة SQL Server ، اختبار وحدة APEXSQL يمكن استخدامها كحل

Answer 3

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

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

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

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

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

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

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

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

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

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

Answer 4

أنا سعيد لأنك سألت عن اختبار الوحدة ، وعدم الاختبار بشكل عام.

تحتوي قواعد البيانات على العديد من الميزات التي تحتاج إلى اختبار. بعض الأمثلة:

• أنواع البيانات/مجموعات الأحرف/الأحرف (حاول إدخال اسم سويدي ، أو عناوين URL أو أرقام طويلة من العوالم الحقيقية ، ومعرفة ما إذا كانت تعريفات العمود الخاصة بك على ما يرام)
• محفزات
• موانع (مفاتيح أجنبية ، تفرد ...)
• طرق عرض (تحقق من تضمين/استبعاد/تحويل البيانات بشكل صحيح)
• الإجراءات المخزنة
• UDFs
• أذونات
• ...

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

بشكل عام ، يتم اختبار التكامل. هذا يعني أنه يتم إنشاء مجموعة اختبار بلغة برمجة مثل PHP أو Java ، ويصدر الاختبارات بعض الاستفسارات. ولكن إذا فشل شيء ما ، أو كان هناك بعض الاستثناءات ، فمن الصعب فهم المشكلة ، لسببين:

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

لذلك ، في رأيي ، بالنسبة لقواعد البيانات المعقدة ، تحتاج إلى استخدام إطار اختبار الوحدة المكتوب في SQL (باستخدام الإجراءات والجداول المخزنة). يجب عليك اختياره بعناية ، لأن هذا النوع من الأدوات لا يستخدم على نطاق واسع (وبالتالي لم يتم اختباره على نطاق واسع). على سبيل المثال ، إذا كنت تستخدم MySQL ، فأنا أعرف هذه الأدوات:

• STK/الوحدة http://stk.wikidot.com/stk-unit
• utmysql http://utmysql.sourceforge.net/

Answer 5

يمكنني استخدام اختبارات وحدة قاعدة البيانات Junit/Nunit/Etc و Code Up مع Java أو C#. يمكن بعد ذلك تشغيلها على خادم تكامل ربما باستخدام مخطط منفصل لقاعدة بيانات الاختبار.

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

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

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

Answer 6

ألقِ نظرة على إطار عمل dbtestdriven. إنه يعمل بشكل رائع بالنسبة لنا. قم بتنزيله من Github أو موقع الويب الخاص بهم.

Answer 7

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

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

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