Junit4: يتم تنفيذ الأسلوبParameters قبل تهيئةClassRule. هل يمكن أن يكون الطريق؟

الحل الحالي:

    protected static TemporaryFolder initStaticTemp() {
        try {
            return new TemporaryFolder() { { before(); } };
        } catch (Throwable t) {
            throw new RuntimeException(t);
        }
    }

    public static TemporaryFolder tmp = initStaticTemp();

    <strong i="6">@AfterClass</strong>
    public static cleanup() throws Exception {
        tmp.delete();
    }

إنه يعمل ولكنه يحتاج إلى ذلك التنظيف اليدوي ...

+1

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

<strong i="7">@Parameters</strong>
<strong i="8">@AfterClassRules</strong>
public Object[][] generateParameters() {
    // do stuff
}

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

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

هل سيكون التصميم المقترح في تعليقي السابق مقبولاً من قبل المشرفين؟ إذا كان الأمر كذلك ، فسوف أبدأ العمل في طلب سحب.

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

ربما تكون إجابتي المفضلة هي تمكين شيء مثل DataPoints في النظريات: يمكن أن تكون هناك حقول ثابتة أو طرق ثابتة مسبوقة بـ ParameterSet ، والتي يتم ضمها معًا لإنشاء مجموعة المعلمات الكاملة. لذلك سيكون المثال الخاص بك:

ClassRule public static TemporaryFolder tmp = new TemporaryFolder () ؛
ParameterSet public static Object [] first = new Object [] {0}؛
ParameterSet public static Object [] الثانية () {
إرجاع كائن جديد [] {tmp.getRoot (). getPath ()؛ }
}

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

ما رأيك؟

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

هذا هو الاختبار الذي واجهت فيه المشكلة في الأصل: CryptoAppExecReturnCodeTest.java

dsaff سأفكر في اقتراحك. الانطباع الأولي هو: تقسيم الأزواج إلى مصفوفات منفصلة يحتاج إلى عناية خاصة بمواضع العناصر (عرضة للخطأ قليلاً). لذلك قد ينتهي بي الأمر بملء _ أولاً _ ببعض الأشياء الوهمية (فقط الحفاظ على عدد العناصر) ؛ وفي _second_ - أود الاحتفاظ بالعنصرين بجوار بعضهما البعض:

{ 0, tmp...getPath() },
{ 1, ... }

هل هناك أي شيء آخر يحتاجه المتسابقون غير عدد الاختبارات؟ (على سبيل المثال - ربما اختبار الأسماء؟)

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

<strong i="7">@ClassRule</strong> public static TemporaryFolder tmp = new TemporaryFolder();
<strong i="8">@ParameterSet</strong> public static Object[] only() {
return new Object[] { 0, tmp.getRoot().getPath(); }
}

آمل أن يجعل ذلك نيتي أوضح ؛ آسف على حيرتي الأولية.

(يمر ببعض الأخطاء القديمة)

ربما يتعين علينا إعادة تسمية هذه المشكلة "تمكين شيء مثل DataPoints في النظريات"؟

(يمر ببعض الأخطاء القديمة)

ربما يتعين علينا إعادة تسمية هذه المشكلة "تمكين شيء مثل DataPoints في النظريات"؟

أود أن أقول إن المشكلة تكمن في امتلاك القدرة على استخدام موارد Rule في قائمة المعلمات للاختبارات ذات المعلمات. يبدو أن النهج مع @ParameterSet الذي اقترحه dsaff يبدو قابلاً للتطبيق (بافتراض حدوث التقييمات في مثل هذا التسلسل الذي يتم فيه حل المشكلة الأصلية).
ولكن إذا كان "شيء مثلDataPoints" واضحًا بدرجة كافية ولا يوجد خطر من التباعد في اتجاه ما لا يغطي السيناريو الأصلي: حسنًا بالنسبة لي.
السبب الذي يجعلني أفضل الاختبارات ذات المعايير المحددة على النظريات (التي تستخدم DataPoints) هو أن نتائج هذه الأخيرة لا يتم الإبلاغ عنها بشكل مستقل لكل مجموعة من المعلمات ، وأن هذا الفشل الأول يجهض تنفيذ المعلمات اللاحقة.