Haruskah saya memiliki unit test untuk cacat yang diketahui?


37

Jika kode saya berisi cacat yang diketahui yang harus diperbaiki, tetapi belum, dan tidak akan diperbaiki untuk rilis saat ini, dan mungkin tidak diperbaiki dalam waktu dekat, haruskah ada unit test gagal untuk bug di kamar uji? Jika saya menambahkan tes unit, itu akan (jelas) gagal, dan membiasakan diri dengan tes gagal sepertinya ide yang buruk. Di sisi lain, jika itu adalah cacat yang diketahui, dan ada kasus gagal yang diketahui, tampaknya aneh untuk tetap keluar dari ruang uji, karena pada titik tertentu harus diperbaiki, dan tes sudah tersedia.


6
Saya tidak berpikir begitu nyamuk, saya secara khusus bertanya tentang unit test
Martijn

3
tes untuk cacat yang dikenal dikenal sebagai tes regresi , ini tidak ada hubungannya dengan tes unit ... tepatnya, yang terakhir tergantung pada pendapat pengembang - pertanyaan Anda mungkin bukan duplikat setelah semua, melainkan jajak pendapat untuk pendapat. Sangat menonjol bahwa jawaban yang Anda terima sama sekali tidak menggunakan istilah "tes unit", tetapi sebaliknya secara wajar menyebut ini "tes gagal yang diketahui" berbeda
agas

3
Terima kasih Michael, itu membantu cara menandai tes seperti itu di JUnit, tetapi tidak benar-benar pada praktik pengujian. Agas, saya masih tidak mengerti bagaimana Anda melihat unit test gagal sebagai tes regresi. Saya juga mendapatkan getaran pasif / agresif yang bermusuhan dari komentar Anda. Jika Anda pikir saya harus mengajukan pertanyaan secara berbeda, tolong katakan demikian, karena saya tidak dapat mengatasi masalah Anda jika Anda mengucapkannya seperti ini.
Martijn

3
@gnat: jujur, IMHO tidak masalah jika kita menyebut tes di sini "unit" atau "regresi" tes - pertanyaan yang Anda tautkan juga memiliki fokus yang berbeda, dan jawaban di sana tidak berlaku di sini.
Doc Brown

Jawaban:


51

Jawabannya adalah ya, Anda harus menulisnya dan menjalankannya.

Kerangka kerja pengujian Anda memerlukan kategori "tes gagal yang diketahui" dan Anda harus menandai tes ini sebagai bagian dari kategori itu. Bagaimana Anda melakukannya tergantung pada framework.

Anehnya, tes gagal yang tiba-tiba lulus bisa sama menariknya dengan tes lulus yang tiba-tiba gagal.


7
Contoh fitur di atas dalam kerangka unittest Python: docs.python.org/3.3/library/…
Jace Browning

5

Saya pikir Anda harus memiliki unit test dengan perilaku saat ini dan di komentar, tambahkan tes yang tepat dan perilaku yang benar. Contoh:

@Test
public void test() {
  // this is wrong, it should be fixed some time
  Assert.assertEquals(2, new Calculator().plus(2,2));
  // this is the expected behaviour, replace the above test when the fix is available
  // Assert.assertEquals(4, new Calculator().plus(2, 2));
}

Dengan cara ini, ketika perbaikan tersedia, build akan gagal, memperhatikan Anda tes yang gagal. Ketika Anda akan melihat tes, Anda akan tahu bahwa Anda mengubah perilaku dan tes harus diperbarui.

EDIT: Seperti yang dikatakan Kapten Man, dalam proyek-proyek besar, ini tidak akan diperbaiki dalam waktu dekat tetapi demi dokumentasi, jawaban aslinya lebih baik daripada tidak sama sekali.

Cara yang lebih baik untuk melakukannya adalah menduplikasi tes saat ini, membuat klon menyatakan hal yang benar dan @Ignoredengan pesan, misalnya

@Test
public void test() {
  Assert.assertEquals(2, new Calculator().plus(2,2));
}

@Ignore("fix me, Calculator is giving the wrong result, see ticket BUG-12345 and delete #test() when fixed")
@Test
public void fixMe() {
  Assert.assertEquals(4, new Calculator().plus(2, 2));
}

Ini disertai dengan konvensi dalam tim Anda untuk mengurangi jumlah @Ignoretes d. Cara yang sama yang akan Anda lakukan dengan memperkenalkan atau mengubah tes untuk mencerminkan bug, kecuali Anda tidak gagal membangun jika ini sangat penting untuk tim Anda, seperti OP mengatakan bahwa perbaikan bug tidak akan dimasukkan dalam rilis saat ini .


1
Ini saran yang buruk. Tidak ada yang akan berusaha memperbaikinya. Orang-orang hanya akan membuka unit test lama jika ada masalah kompilasi atau kegagalan tes.
Kapten Man

@ Kapten Man Saya setuju, saya telah memperbarui jawaban saya untuk memberikan cara yang lebih baik dari tim pengembang menyadari adanya bug tanpa gagal membangun. Downvote Anda dibenarkan untuk jawaban asli yang saya posting 3 tahun yang lalu, saya yakin jawaban saat ini lebih tepat. Apakah Anda akan melakukannya dengan cara lain?
Silviu Burcea

Ini hampir persis apa yang saya lakukan pada kesempatan langka saya tidak dapat memperbaiki bug sekarang karena beberapa alasan. Saya ingin mendengar bagaimana Anda menangani situasi ini. KaptenMan
RubberDuck

@RubberDuck Sebenarnya tidak ada situasi yang ideal di sini (selain memperbaiki bug sekarang haha). Bagi saya, setidaknya melihat dalam hasil tes "10 berlalu, 0 gagal, 1 dilewati" adalah setidaknya beberapa indikasi ada sesuatu yang mencurigakan bagi orang yang tidak terbiasa dengannya. Saya lebih suka @Ignorependekatannya. Alasan menggunakan hanya komentar sepertinya bukan ide yang baik bagi saya adalah karena saya tidak berpikir orang akan sering membuka unit test untuk memeriksanya (kecuali jika mereka gagal, atau (semoga) ketika mereka bertanya-tanya mengapa ada sesuatu yang diabaikan ).
Kapten Man

@RubberDuck Sebenarnya tidak ada situasi yang ideal di sini (selain memperbaiki bug sekarang haha). Bagi saya, setidaknya melihat dalam hasil tes "10 berlalu, 0 gagal, 1 dilewati" adalah setidaknya beberapa indikasi ada sesuatu yang mencurigakan bagi orang yang tidak terbiasa dengannya. Saya lebih suka @Ignorependekatannya. Alasan menggunakan hanya komentar sepertinya bukan ide yang baik bagi saya adalah karena saya tidak berpikir orang akan sering membuka unit test untuk memeriksanya (kecuali jika mereka gagal, atau (mudah-mudahan) ketika mereka bertanya-tanya mengapa ada sesuatu yang dilompati ).
Kapten Man

3

Bergantung pada alat tes Anda dapat menggunakan omitatau pendfungsi.

Contoh dalam ruby:

gem 'test-unit', '>= 2.1.1'
require 'test/unit'

MYVERSION = '0.9.0' #Version of the class you test 


class Test_omit < Test::Unit::TestCase
  def test_omit
    omit('The following assertion fails - it will be corrected in the next release')
    assert_equal(1,2)
  end

  def test_omit_if
    omit_if(MYVERSION < '1.0.0', "Test skipped for version #{MYVERSION}")
    assert_equal(1,2)
  end

end

The omitperintah melompat tes, yang omit_ifmenggabungkan dengan tes - dalam contoh saya saya uji nomor versi dan melaksanakan tes hanya untuk versi mana saya berharap kesalahan dipecahkan.

Output dari contoh saya adalah:

Loaded suite test
Started
O
===============================================================================
The following assertion fails - it will be corrected in the next release [test_omit(Test_omit)]
test.rb:10:in `test_omit'
===============================================================================
O
===============================================================================
Test skipped for version 0.9.0 [test_omit_if(Test_omit)]
test.rb:15:in `test_omit_if'
===============================================================================


Finished in 0.0 seconds.

2 tests, 0 assertions, 0 failures, 0 errors, 0 pendings, 2 omissions, 0 notifications
0% passed

Jadi jawaban saya: Ya, laksanakan tes. Tapi jangan bingung penguji dengan kesalahan, di mana Anda tahu itu akan gagal.


2

Jika bug itu segar di pikiran Anda dan Anda punya waktu untuk menulis tes unit sekarang, maka saya akan menulisnya sekarang dan memberi tanda sebagai kegagalan yang diketahui sehingga tidak membuat build itu sendiri. Pelacak bug Anda harus diperbarui untuk mencerminkan bahwa ada unit test yang saat ini gagal untuk bug ini sehingga orang yang ditugaskan untuk memperbaikinya akhirnya tidak menulisnya lagi. Ini mengandaikan bahwa kode kereta tidak perlu banyak refactoring dan bahwa API berubah secara signifikan - jika itu masalahnya maka Anda mungkin lebih baik tidak menulis tes unit sampai Anda memiliki ide yang lebih baik tentang bagaimana tes harus ditulis .


1

Jawabannya adalah TIDAK. Anda tidak boleh menambahkan unit test untuk bug sampai Anda mulai mengerjakan perbaikan untuk bug dan daripada Anda akan menulis tes yang membuktikan bug dan ketika tes itu gagal sesuai dengan laporan bug ( s) Anda akan pergi dan memperbaiki kode aktual untuk membuat tes lulus dan bug akan dipecahkan dan akan dibahas setelah itu.

Di dunia saya, kami akan memiliki kasus uji manual bahwa QE gagal sampai bug diperbaiki. Dan kami sebagai pengembang akan menyadarinya melalui manual gagal TC dan melalui pelacak bug.

Alasan untuk tidak menambahkan UT yang gagal adalah sederhana. UT adalah untuk umpan balik langsung dan validasi dari apa yang saya sebagai pengembang saat ini bekerja. Dan UT digunakan dalam sistem CI untuk memastikan saya tidak merusak sesuatu secara tidak sengaja di beberapa area kode untuk modul itu. Memiliki UT gagal secara sengaja untuk IMHO bug yang tahu akan menjadi kontra produktif dan hanya salah.


0

Saya kira jawabannya adalah, itu tergantung. Pragmatis tentang hal itu. Apa yang membuat Anda menulis sekarang? Mungkin itu segar di pikiran Anda?

Saat memperbaiki bug, masuk akal untuk membuktikannya ada dengan menulis unit test yang mengekspos bug. Anda kemudian memperbaiki bug, dan unit test harus lulus.

Apakah Anda punya waktu untuk menulis tes unit gagal sekarang? Apakah ada lebih banyak fitur mendesak atau bug yang perlu ditulis / diperbaiki.

Dengan asumsi Anda memiliki perangkat lunak pelacakan bug yang kompeten dengan bug yang masuk, sebenarnya tidak perlu menulis unit test yang gagal sekarang .

Mungkin Anda dapat menimbulkan beberapa kebingungan jika Anda memperkenalkan tes unit gagal sebelum rilis yang terjadi tanpa perbaikan bug.


0

Saya biasanya merasa tidak nyaman tentang kegagalan yang diketahui dalam ruang tes, karena terlalu mudah bagi daftar untuk tumbuh dari waktu ke waktu, atau untuk kegagalan yang tidak terkait dalam tes yang sama diberhentikan sebagai "diharapkan". Hal yang sama berlaku untuk kegagalan intermiten - mungkin ada sesuatu yang jahat mengintai kode. Saya akan memilih untuk menulis tes untuk kode seperti sekarang, dan sebagaimana seharusnya setelah itu diperbaiki tetapi berkomentar atau dinonaktifkan entah bagaimana.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.