زوجان من الأسئلة حول اختبار الوحدة

Question

لنفترض أننا نقوم بتصميم اختبار فئة المكدس الأول (TDD):

public class Stack<T> {
    private T[] elements = new T[16];
    private int size = 0;
    ...
}

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

اخترت أولاً شيئًا من شكل:

Should_Be_Able_To_Correctly_Increase_Its_Inner_Array_Size()

وثم

Should_Handle_More_Items_Than_The_Default_Internal_Array_Size()

لكن بعد التفكير قليلاً ، توصلت إلى استنتاج مفاده أنه ربما يكون هناك شيء مثل التالي أكثر ملاءمة:

Should_Double_Its_Size_Every_Time_Its_Full()

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

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

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

Answer 1

من وجهة نظري (لست متأكدًا من أنني على صواب) ، يجب أن تكون الاختبارات الخاصة بي التفاعلات المحتملة الخاصة بي مع الجزء الخارجي ، وليس على كيفية تنفيذها داخليًا. هل انا على حق؟

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

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

Answer 2

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

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

Answer 3

اسأل نفسك عما أنت على استعداد للالتزام به لهذا الفصل.

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

public Stack<T>(CapacityGrowthStyle capacityGrowthStyle) { ... }

إذا لم يكن الأمر كذلك ، فما عليك سوى كتابة الاختبارات لتوثيق السعة واتركها في ذلك (حيث X فيما يلي حد هيكل البيانات الأساسي الخاص بك):

[Test]
public void Can_Handle_X_Items() { ... }

[Test]
[ExpectedException(typeof(InvalidOperationException))]
public void Cannot_Handle_More_Than_X_Items() { ... }

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

Answer 4

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