اختبارات الوحدة وقاعدة البيانات

Question

هذا السؤال حول اختبارات الوحدة أثار شيء آخر كان يزعجني. لقد ذهبت ذهابًا وإيابًا على ثلاث طرق لإجراء اختبارات الوحدة عند ضرب قاعدة بيانات.

1. قم بإنشاء كائنات وهمية وقم بتوصيلها. هذا له ميزة عدم الحاجة إلى قاعدة بيانات ، لكنها مضيعة للوقت ولست متأكدًا من مقدار العائد على الاستثمار الذي أحصل عليه. لقد دخلت إلى IOC و MOQ قليلاً ، لكن لا يزال يبدو مؤلمًا.
2. قم بإنشاء نصوص قاعدة بيانات الإعداد والدموع لإنشاء حالات معروفة ، واختبار تلك. مرة أخرى ، يمكن أن تكون كثيفة الوقت ، ولكن لا تزال أسهل في إنشاء الأشياء الوهمية معظم الوقت. وغيرهم من الأشخاص في العمل لا يزال بإمكانهم تشغيله على افتراض أن لديهم SQL Server على مضيفهم المحلي.
3. تحقق يدويًا من قاعدة بيانات DEV وتعديل اختبارات الوحدة. العمل اليدوي بشكل مكثف ، ولكن إذا كان لدي "مجموعة اختبار" لا تتغير ، فيبدو أنه يعمل بشكل جيد. على جهازي ، على الأقل :-).

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

إذا كان السياق يساعد ، فأنا في متجر C# ، أكتب التطبيقات الداخلية ، فقط عدد قليل من المطورين.

Answer 1

لا ينبغي أن يكون الأول بهذه الصعوبة إذا كان لديك طبقة وصول للبيانات تكشف عن حفنة من IQueryable<T> طُرق. هناك خدعة لطيفة يمكنك استخدامها للبيانات المزيفة: ما عليك سوى تخزين كائنات الكيان في أ List<T> والاستخدام AsQueryable. أجد هذا أسهل من MOQ لقطع غيار البيانات.

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

Answer 2

بالتأكيد سأستمر في استخدام اختبارات الوحدة الحقيقية (الخيار 1). أنا أحب نصيحة ستيفن لهذا.

يمكنك أيضًا العثور على اختبارات تكامل مع قاعدة بيانات فعلية (الخيار 2) من الضروري لاستخدام كذلك (الخيار 2). لماذا ا؟ نظرًا لأن جزءًا من ما تحتاج إلى اختباره (رسم الخرائط O/R ، لا يتم تغطية التوافق مع مخطط DB الفعلي ، وما إلى ذلك) من خلال اختبارات الوحدة الحقيقية.

أما بالنسبة للإعداد والمنطق ، فإن الوراثة من هذا عادة ما تكون كافياً (باستخدام .NET و NUNIT و SQLServer لقاعدة البيانات):

using System.Transactions;
using NUnit.Framework;
namespace Crown.Util.TestUtil
{
    [TestFixture]
    public class PersistenceTestFixture
    {
        public TransactionScope TxScope { get; private set; }

        [SetUp]
        public void SetUp()
        {
            TxScope = new TransactionScope();
        }

        [TearDown]
        public void TearDown()
        {
            if (TxScope != null)
            {
                TxScope.Dispose();
                TxScope = null;
            }
        }
    }
}

سهل مثل الفطيرة.

Answer 3

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

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

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

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

Answer 4

ما الذي تختبره حقًا مما يجعلك تشعر أن هذا صعب؟

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

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