سؤال

النظر في مثل هذا الرمز:

class ToBeTested {
public:
  void doForEach() {
    for (vector<Contained>::iterator it = m_contained.begin(); it != m_contained.end(); it++) {
       doOnce(*it);
       doTwice(*it);
       doTwice(*it);
    }
  }
  void doOnce(Contained & c) {
    // do something
  }
  void doTwice(Contained & c) {
    // do something
  }

  // other methods
private:
  vector<Contained> m_contained;
}

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

tobeTested.AddContained(one);
tobeTested.AddContained(two);
tobeTested.AddContained(three);

BEGIN_PROC_TEST()
SHOULD_BE_CALLED(doOnce, 1)
SHOULD_BE_CALLED(doTwice, 2)
SHOULD_BE_CALLED(doOnce, 1)
SHOULD_BE_CALLED(doTwice, 2)
SHOULD_BE_CALLED(doOnce, 1)
SHOULD_BE_CALLED(doTwice, 2)

tobeTested.doForEach()
END_PROC_TEST()

كيف تنصح باختبار هذا؟هل هناك أي وسيلة للقيام بذلك باستخدام أطر عمل CppUnit أو GoogleTest؟ربما يسمح إطار اختبار الوحدة الآخر بإجراء مثل هذه الاختبارات؟

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

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

هل كانت مفيدة؟

المحلول

إذا كنت مهتمًا بالأداء، أنصحك بكتابة اختبار يقيس الأداء.

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

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

ومع ذلك، إذا كنت تريد حقًا اختبار استدعاء أساليبك بترتيب معين، فستحتاج إلى القيام بما يلي:

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

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

نصائح أخرى

يمكنك التحقق من ذلك com.mockpp.

يجب أن تكون قادرًا على استخدام أي إطار عمل ساخر جيد للتحقق من أن الاستدعاءات إلى كائن متعاون تتم بترتيب معين.

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

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

يمكنني تقديم المزيد من المساعدة، ولكن لا أعتقد أن المثال الخاص بك متسق (أين يتم تنفيذ الأسلوب AddContained؟).

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

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

أنا لست مبرمجًا لـ C++، لذا لست على علم بما هو متاح لـ C++، ولكن هذا أحد أنواع الأدوات التي قد تسمح بما تحاول القيام به.

http://msdn.microsoft.com/en-au/magazine/cc301356.aspx

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

في النهاية سوف تكون قادرا على كتابة شيء مثل:CallTracingTtribute ()] تتبع الطبقة العامة:ContextBoundObject {...}

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top