كيف يمكنني اختبار طريقة تقوم بملء قائمة من DataReader؟

Question

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

يجب ملء الكود الذي أعمل عليه، دعنا نقول أ List<Foo> من DataReader الذي يُرجع كافة الحقول المطلوبة لملف Foo فعال.ومع ذلك، إذا كنت أرغب في التحقق من أن الكود يقوم في الواقع بإرجاع عنصر قائمة واحد لكل صف واحد من قاعدة البيانات، فأنا أكتب كود اختبار يبدو كالتالي:

Expect.Call(reader.Read()).Return(true);
Expect.Call(reader["foo_id"]).Return((long) 1);
// ....
Expect.Call(reader.Read()).Return(true);
Expect.Call(reader["foo_id"]).Return((long) 2);
// ....
Expect.Call(reader.Read()).Return(false);

وهو أمر ممل إلى حد ما ويمكن كسره بسهولة أيضًا.

كيف يجب أن أتعامل مع هذه المشكلة حتى لا تكون النتيجة فوضى كبيرة من الاختبارات الهشة؟

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

يحرر:أنا أيضًا مقيد حاليًا بـ C# 2.

Answer 1

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

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

Answer 2

فكرت في نشر بعض الأكواد ثم تذكرت دورة Nothin But .NET الخاصة بـ JP Boodhoo.لديه مشروع عينة أنه يقوم بالمشاركة التي تم إنشاؤها خلال أحد فصوله الدراسية.يتم استضافة المشروع على كود جوجل وهو مورد جميل.أنا متأكد من أنه يحتوي على بعض النصائح الرائعة التي يمكنك استخدامها وتعطيك أفكارًا حول كيفية إعادة تصميم الخرائط.تم بناء المشروع بأكمله باستخدام TDD.

Answer 3

يمكنك وضع مثيلات Foo في قائمة ومقارنة الكائنات بما قرأته:

var arrFoos = new Foos[]{...}; // what you expect
var expectedFoos = new List<Foo>(arrFoos); // make a list from the hardcoded array of expected Foos
var readerResult = ReadEntireList(reader); // read everything from reader and put in List<Foo>
Expect.ContainSameFoos(expectedFoos, readerResult); // compare the two lists

Answer 4

كوكوس,

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

Answer 5

فقط للتوضيح، هل تريد أن تكون قادرًا على اختبار مكالمتك في SQL Server التي أعادت بعض البيانات، أو أنه إذا كان لديك بعض البيانات فيمكنك تعيينها مرة أخرى في النموذج؟

إذا كنت ترغب في اختبار مكالمتك في SQL، فقد تم إرجاع بعض البيانات، وتم العثور على إجابتي هنا

Answer 6

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

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