Junit4: Metode @Parameters dijalankan sebelum inisialisasi @ClassRule. Mungkinkah sebaliknya?

Dibuat pada 2 Mei 2013  ·  9Komentar  ·  Sumber: junit-team/junit4

Saya memiliki masalah berikut (menggunakan _junit 4.11_):

    <strong i="6">@ClassRule</strong>
    public static TemporaryFolder tmp = new TemporaryFolder();
    ...
    <strong i="7">@Parameters</strong>
    public static Collection<Object[]> data() throws Exception {
        return java.util.Arrays.asList(new Object[][] {
            {0, tmp.getRoot().getPath()}
        });
    }

Ini menghasilkan inisialisasiError

java.lang.IllegalStateException: the temporary folder has not yet been created
    at org.junit.rules.TemporaryFolder.getRoot(TemporaryFolder.java:127)

Jadi sepertinya metode _@Parameters_ dijalankan sebelum fase inisialisasi _ClassRule_ yang membuat skenario seperti di atas sedikit rumit.

Komentar yang paling membantu

Solusi saat ini:

    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();
    }

Ini berfungsi tetapi perlu pembersihan manual ...

Semua 9 komentar

Solusi saat ini:

    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();
    }

Ini berfungsi tetapi perlu pembersihan manual ...

+1

Memikirkannya sedikit, saya kira cara yang baik untuk mengimplementasikan ini adalah dengan memperkenalkan anotasi untuk ini:

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

Ini akan memastikan bahwa kedua varian masih dapat digunakan, dan kode yang ada tidak rusak. Jika desain ini dapat diterima oleh pengelola, saya akan mulai mengerjakan permintaan tarik untuk ini.

Saya menulis komentar tambahan karena saya tidak yakin apakah pembaruan pada komentar memicu pemberitahuan.

Apakah desain yang diusulkan dalam komentar saya sebelumnya dapat diterima oleh pengelola? Jika demikian, saya akan mulai mengerjakan permintaan tarik.

Ada masalah arsitektur yang cukup sulit di sini: JUnit menjanjikan pelari seperti Eclipse bahwa ia dapat menghitung berapa banyak tes yang ada sebelum tes dijalankan, tetapi juga ingin meminimalkan sumber daya yang dikonsumsi selama fase perencanaan ini. Jadi kami benar-benar ingin tahu berapa banyak parameter yang akan ada sebelum kami, misalnya, membuat folder sementara, atau melakukan hal yang lebih drastis yang muncul di ClassRules, seperti memulai server.

Mungkin jawaban favorit saya adalah mengaktifkan sesuatu seperti @DataPoints in Theories: mungkin ada bidang statis atau metode statis yang diawali dengan @ParameterSet , yang digabungkan untuk membuat set parameter lengkap. Jadi contoh Anda adalah:

@ClassRule public static TemporaryFolder tmp = new TemporaryFolder();
@ParameterSet public static Object[] pertama = new Object[] { 0 };
@ParameterSet objek statis publik[] detik() {
kembalikan Objek baru[] { tmp.getRoot().getPath(); }
}

Intinya di sini adalah bahwa kita dapat menghitung metode "kedua" tanpa benar-benar menjalankannya.

Bagaimana menurutmu?

Hm, saya kira sekarang saya memikirkannya, masalahnya sebenarnya lebih pada bau dalam kode pengujian saya. Saya terhubung ke layanan jarak jauh dan menjalankan tes tergantung pada cara konfigurasinya. Alih-alih, saya mungkin harus memperbaiki konfigurasi yang diharapkan dalam pengujian saya.

Inilah tes di mana saya awalnya menghadapi masalah: CryptoAppExecReturnCodeTest.java

@dsaff Saya akan memikirkan saran Anda. Kesan awal adalah: memisahkan pasangan menjadi larik terpisah membutuhkan perhatian khusus pada posisi elemen (sedikit rawan kesalahan). Jadi saya mungkin akan mengisi _first_ dengan beberapa barang tiruan (hanya mempertahankan jumlah elemen); dan dalam _second_ - Saya ingin menyimpan elemen pasangan di samping satu sama lain:

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

Apakah ada hal lain yang dibutuhkan pelari selain jumlah tes? (Misalnya - mungkin nama tes?)

@javornikolov , saya baru menyadari bahwa saya salah membaca posting awal Anda, jadi tanggapan saya kemungkinan membingungkan. Saya membaca pengujian Anda sebagai dua contoh berbeda dari kelas pengujian yang dibuat dengan satu parameter; sekarang setelah saya membacanya lagi, sebenarnya ini adalah salah satu instantiasi dari kelas pengujian yang dibangun dengan dua parameter. Untuk menyesuaikan proposal saya, kode yang disarankan adalah:

<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(); }
}

Saya harap itu membuat niat saya lebih jelas; maaf atas kebingungan awal saya.

(melalui beberapa bug lama)

Mungkin kita harus mengganti nama masalah ini "Aktifkan sesuatu seperti @DataPoints in Theories"?

(melalui beberapa bug lama)

Mungkin kita harus mengganti nama masalah ini "Aktifkan sesuatu seperti @DataPoints in Theories"?

Saya akan mengatakan masalahnya adalah memiliki kemampuan untuk menggunakan sumber daya Rule dalam daftar parameter untuk tes parametrized. Pendekatan dengan @ParameterSet yang diusulkan oleh @dsaff tampaknya layak bagi saya (dengan asumsi evaluasi terjadi dalam urutan sedemikian rupa sehingga masalah asli diselesaikan).
Tetapi jika "Sesuatu seperti @DataPoints" cukup jelas dan tidak ada risiko untuk menyimpang ke beberapa arah yang tidak mencakup skenario asli: OK untuk saya.
Alasan saya lebih memilih tes Parametrized daripada Theories (yang menggunakan DataPoints) adalah karena hasil yang terakhir tidak dilaporkan secara independen untuk setiap set params, dan kegagalan pertama membatalkan eksekusi params berikutnya.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat