هل يعد إجراء الاختبارات على قاعدة بيانات بدلاً من المستودعات المزيفة ممارسة سيئة؟

Question

أعرف ما هي المزايا وأستخدم بيانات مزيفة عندما أعمل مع أنظمة أكثر تعقيدًا.

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

هل لا يزال من المهم إنشاء بيانات مزيفة أم يمكنني أن أنسى الترميز الإضافي وأنتقل مباشرةً إلى البيانات الحقيقية؟

عندما قلت قاعدة بيانات حقيقية، لا أقصد قاعدة بيانات إنتاجية، بل أقصد قاعدة بيانات اختبارية، ولكن باستخدام نظام إدارة قواعد البيانات المباشر الحقيقي ونفس مخطط قاعدة البيانات الحقيقية.

Answer 1

أسباب استخدام البيانات المزيفة بدلاً من قاعدة البيانات الحقيقية هي:

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

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

Answer 2

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

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

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

وأما وقد قلت ذلك، إذا كنت تريد حقا لاختبار على قاعدة البيانات الخاصة بك يمكنك. هناك أدوات التي تساعد على إنشاء وهدم قاعدة بيانات، مثل dbunit .

ورأيت الناس في محاولة لخلق وحدة اختبار من هذا القبيل، ولكن دائما تقريبا اتضح أن الكثير من العمل ثم هو في الواقع يستحق. الأكثر التخلي عنها في منتصف الطريق من خلال المشروع، ومعظم التخلي عن TTD تماما أثناء تنفيذ المشروع، والتفكير في نقل الخبرة لاختبار وحدة في العام.

وهكذا أوصي حفظ اختبارات بسيطة ومعزولة وتغليف التعليمات البرمجية جيدة بما فيه الكفاية يصبح من الممكن اختبار التعليمات البرمجية في العزلة.

Answer 3

واعتقد ان ذلك يتوقف على ما إذا كان يتم إصلاح استفساراتكم داخل مستودع (الخيار الأفضل، IMO)، أو ما إذا كان مستودع يعرض الاستفسارات composable. على سبيل المثال - إذا كان لديك طريقة المستودع:

IQueryable<Customer> GetCustomers() {...}

وثم UI الخاصة بك يمكن أن يطلبوا:

var foo = GetCustomers().Where(x=>SomeUnmappedFunction(x));

bool SomeUnmappedFunction(Customer customer) {
   return customer.RegionId == 12345 && customer.Name.StartsWith("foo");
}

وهذا سوف تمر لالريبو وهمية الكائن مقرها، ولكن ستفشل ل<م> الفعلية تطبيقات ديسيبل. بالطبع، يمكنك إلغاء ذلك عن طريق وجود مستودع التعامل مع جميع الاستفسارات داخليا (أي تكوين خارجي)؛ على سبيل المثال:

Customer[] GetCustomers(int? regionId, string nameStartsWith, ...) {...}

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

Answer 4

وهذا يعتمد بدلا من ذلك على ما إذا كان DB يتم تلقائيا من قبل الاختبار، وأيضا ما إذا كان عزل قاعدة البيانات من مطورين آخرين.

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

Answer 5

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

وأنت لا <م> الحاجة استخدام DI / IOC أو لديك وحدة الاختبارات أو يسخر من الوصول ديسيبل إذا كان كل ما كنت أكتب هو بسيط "اتصل بنا" النموذج. ومع ذلك، من أين نرسم الخط الفاصل بين التطبيق "بسيط" واحد "معقدة" أمر صعب.

وبعبارة أخرى، استخدم حكمك حيث لا يوجد بجد وتحديد الأجوبة على ذلك.

Answer 6

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

وأما الآخرين كما أشار إلى أنه من الصعب وضع حد لمجمع معقد / غير، وكنت عادة الآن عندما فوات الأوان :( إذا كنت تستخدم بالفعل إلى القيام بها، وأنا متأكد من أنك فاز ' ر الحصول على الكثير من النفقات العامة وإذا لم يكن الأمر كذلك، هل يمكن أن نتعلم منها:)

Answer 7

وبقدر ما يتعلق الأمر ريال DB لا تحصل في طريقك، ويمكنك الذهاب أسرع بهذه الطريقة، وأود أن تكون واقعية والذهاب لذلك.

في وحدة الاختبار، و"اختبار" هو أكثر أهمية من "وحدة".

Answer 8

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

ولكن هناك عدد قليل من العيوب:

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

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

Answer 9

وميزة واحدة من مستودعات وهمية هي أن لديك اختبار الانحدار / وحدة يتسق منذ يمكنك أن تتوقع نفس النتائج لنفس استفسار. وهذا يجعل من الاسهل لبناء بعض الاختبارات وحدة.

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

وبالإضافة إلى ذلك، يتم تنظيم بعض قواعد البيانات عن طريق قوانين الخصوصية، وذلك حسب العقد الخاص بك والذي يمتلك DB الرئيسي، قد أو قد لا يسمح قانونا للوصول إلى بيانات حقيقية.

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

Answer 10

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

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

Answer 11

وسلبيات لتشغيل الاختبارات ضد قاعدة البيانات الخاصة بك هو عدم وجود السرعة والتعقيد لإقامة الدولة قاعدة البيانات الخاصة بك قبل تشغيل الاختبارات.

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