Testng: @Test(enabled=false) penjelasan di tingkat kelas harus menonaktifkan semua metode di kelas

Dibuat pada 21 Des 2011  ·  20Komentar  ·  Sumber: cbeust/testng

Disalin dari http://code.google.com/p/testng/issues/detail?id=102

Diuji dengan TestNG 6.3.1 juga

Langkah apa yang akan mereproduksi masalah?
Saya memiliki kelas tes seperti ini:

@Test(diaktifkan = salah)
MyTest kelas publik {
@DataProvider(nama = "bla")
objek pribadi[][] bla() {
kembalikan Objek baru[][] {
Objek baru[] { "bla"}
};
}

@Test(dataProvider = "bla")
public void blastest(String bla) {
System.out.println(bla);
}
}

Apa keluaran yang diharapkan?
Saya berharap metode blastest tidak berjalan dan tidak ada output konsol. Alih-alih menjalankan blast dan mencetak "bla".

Apa versi produk yang Anda gunakan?
Saya telah menguji dengan testng 5.11/6.0.1, berjalan dari maven 2.2.1/3.0.3 dengan plugin surefire 2.7.2.

Harap berikan informasi tambahan apa pun di bawah ini.

Semua 20 komentar

Hai Nicolas,

Anda akan melihat ini jika Anda tidak menggunakan metode @Test pada metode Anda, tetapi segera setelah Anda melakukannya (seperti yang Anda lakukan pada contoh di atas dengan dataProvider) maka atribut enabled akan diganti, dan defaultnya benar, maka perilaku yang Anda lihat.

Apakah ini masuk akal?

Ya, Terima kasih Cedric.

Saya membuat asumsi yang salah bahwa anotasi @test(enabled=false) di kelas mengecualikan sepenuhnya kelas dari eksekusi

Saya setuju ini agak kontra intuitif, tetapi sudah terlambat untuk berubah sekarang, sayangnya ...

Hai, Cedric!
Bagaimana dengan menambahkan parameter baru ke anotasi @Test dan menyebutnya seperti "enabledClass" dan menjadikannya benar secara default? Ini harus digunakan hanya pada tingkat kelas (enabledClass = false) untuk menonaktifkan seluruh kelas terlepas dari anotasi tingkat metode dan diabaikan, jika ditambahkan untuk metode.
Dengan cara ini kami akan mempertahankan kompatibilitas mundur dan menyediakan fungsionalitas yang cukup berguna pada saat yang bersamaan.
Jika Anda mau, saya dapat menerapkannya sendiri dan memberikan permintaan tarik.
Terima kasih sebelumnya!

@andronix83 ,

Saya khawatir ini membuat segalanya lebih membingungkan sekarang karena Anda perlu menjelaskan perbedaan halus antara enabled dan enabledClass .

Perilaku enabled ini bukan yang paling intuitif tetapi tampaknya tidak menjadi masalah secara umum, jika saya menilai dari berapa kali masalah ini diangkat (hampir tidak pernah).

Hai Cedric,

Saya sebenarnya mengalami masalah ini baru-baru ini minggu lalu. Saya sedang mengerjakan server web yang mengandalkan Facebook Graph API. Saya memiliki kelas pengujian yang memiliki beberapa metode pengujian yang mengandalkan kode yang mengenai API Grafik, dengan metode pengujian lain yang tidak perlu bergantung pada layanan itu sama sekali. Kemudian, ada pemadaman global di Facebook secara keseluruhan selama lebih dari satu jam. Hal ini mengakibatkan beberapa tes di kelas ini gagal.

Apa yang saya harapkan untuk dilakukan, untuk menjaga agar tim pengembangan saya tidak diblokir, cukup nonaktifkan semua tes di kelas ini segera, melalui anotasi @Test(enabled=false) di tingkat kelas. Tentu saja, itu tidak berhasil. Sebagai gantinya, saya harus menonaktifkan setiap metode pengujian yang gagal satu per satu, menghabiskan lebih banyak waktu daripada yang saya inginkan, atau bahkan diperlukan untuk menyelesaikan masalah ini.

Idealnya, TestNG mendukung semacam fungsi yang mirip dengan anotasi @Ignore JUnit: http://junit.sourceforge.net/javadoc/org/junit/Ignore.html. Singkat cerita, pengembang memang menginginkan fungsi ini.

Terima kasih.

@ecbrodie Ini sudah didukung (coba!) tetapi ada peringatan: setiap metode individual yang memiliki anotasi @Test akan mengaktifkan kembali pengujian.

@Test(enabled = false)
public class T {
  void f() {} // will not run
}
@Test(enabled = false)
public class T {
  <strong i="10">@Test</strong>
  void f() {} // WILL run!
}

Ini karena semantik bahwa atribut pada tingkat metode menimpa atribut yang ditentukan pada tingkat kelas, sehingga anotasi tingkat metode @Test pada dasarnya mengatakan @Test(enabled = true) karena itu adalah nilai default...

Masuk akal?

Hai @cbeust , terima kasih untuk contoh itu, tapi itu sudah memahami masalahnya, jadi saya pikir Anda mungkin salah paham. Poin yang saya coba sampaikan adalah, mengingat semantik @Test saat ini (enabled=true/false) dan keinginan untuk memiliki cara untuk benar-benar menentukan penggantian yang diaktifkan pada tingkat kelas untuk mengabaikan apa pun yang diatur pada metode level, mungkin ini saatnya untuk mempertimbangkan kembali pendirian Anda untuk tidak menambahkan semacam nilai anotasi enabledClass .

Anda tampaknya menunjukkan beberapa penghinaan terhadap pendekatan asli yang Anda ambil dengan semantik @Test(enabled). Jika memang demikian, mengapa tidak membawa semantiknya ke sesuatu yang Anda rasa lebih intuitif?

Setuju, saya pikir @Test(enabledClass = false) akan masuk akal dan itu satu-satunya cara untuk mengimplementasikan saran Anda tanpa merusak kompatibilitas ke belakang. Seharusnya cukup mudah juga.

Mungkin Anda atau @juherr tertarik untuk mengirimkan PR?

Saya tidak merasa baik. Saya tidak suka ide untuk menambahkan atribut baru yang hanya digunakan di kelas.
Kemudian, saya pikir enable=false adalah praktik yang buruk ketika digunakan dalam sumber karena Anda harus memodifikasi sumber ketika Anda ingin menjalankan tes.
IMO, jika Anda ingin membatalkan pilihan kelas, testng.xml harus digunakan sebagai gantinya.
@ecbrodie Bagaimana Anda menjalankan tes Anda?

BTW, yang saya usulkan sebagai gantinya adalah menyediakan implementasi IAnnotationTransformer yang akan menimpa perilaku default enable=false di kelas.
IAnnotationTransformer baru saja ke enable=false setiap tes jika kelas mereka memiliki enable=false .
Itu tidak akan merusak kompatibilitas mundur dan tidak akan menambahkan parameter tertentu.
@cbeust Bagaimana menurut Anda?

@juherr PR Keren, memang sangat mudah dilakukan dengan IAnnotationTransformer .

Satu-satunya kekhawatiran saya adalah bahwa bagi pengguna, ini sedikit lebih misterius untuk digunakan, dibandingkan dengan atribut enabledClass .

Perhatikan bahwa kita sudah memiliki beberapa atribut yang hanya berlaku di tingkat kelas ( suiteName , testName ).

Seperti yang saya katakan, saya tidak suka use case. Dan saya kira itu akan cukup untuk hanya 2 orang yang menanyakannya dalam 4 tahun terakhir :)

@juherr Cukup adil.

@ecbrodie Apa pendapat Anda tentang PR?

https://github.com/cbeust/testng/pull/816

@cbeust
Hanya penasaran. Bagaimana jika kami menyediakan AnnotationTransformer bawaan yang dapat melakukan ini?

Ya, itulah yang #816 usulkan

@juherr
Terima kasih telah berbagi informasi PR itu. Adakah alasan mengapa ini menunggu untuk digabungkan?

Bagaimana Jika saya memiliki skenario seperti di bawah ini:

@Test(groups = { "regression", "smoke" }, dependsOnGroups = { "Creation" })
public class EditName {

    @Test(dataProvider="SomeTestData",dataProviderClass=SearchData.class)
    public void TC_1(String Msg) throws Exception{
        System.out.println(Msg);
    }

    @Test(dataProvider="SomeTestData",dataProviderClass=SearchData.class, dependsOnMethods = { "TC_1" }))
    public void TC_2(String Msg) throws Exception{
        System.out.println(Msg);
    }
}
  1. Akankah TC_1 dan TC_2 termasuk dalam kelompok regresi dan asap?
  2. Akankah TC_1 dan TC_2 bergantung pada grup "Pembuatan"?
  3. Akankah TC_2 bergantung pada grup "Pembuatan" serta TC_1, atau hanya TC_1?

@Rameshwar-Juptimath Apa hubungan antara sampel Anda dan masalah ini?

Karena perilaku @Test yang tidak intuitif ini di tingkat kelas dan metode.
Apa yang harus direkomendasikan sebagai praktik terbaik?
Haruskah kita menghindari menggunakan keduanya dalam pengujian?
Karena kita kurang lebih menggunakannya pada tingkat metode untuk memiliki penyedia data yang berbeda untuk setiap kasus, kita harus menghindarinya di kelas?
Pikiran?

@aliciatang Perilakunya sama untuk semua atribut anotasi: nilai pada metode akan menimpa nilai pada kelas.

Sejak 6.13 Anda dapat menggunakan @Ignore yang merupakan perilaku yang Anda harapkan. Dokumentasi untuk @Ignore dapat ditemukan di sini

Apakah halaman ini membantu?
0 / 5 - 0 peringkat