Apakah Anda menggunakan tes unit di tempat kerja? Apa manfaat yang Anda dapatkan dari mereka? [Tutup]

18

Saya telah merencanakan untuk belajar dan menerapkan pengujian unit pada kode saya, tetapi setelah berbicara dengan kolega saya, beberapa dari mereka menyarankan kepada saya bahwa itu tidak perlu dan memiliki manfaat yang sangat kecil. Mereka juga mengklaim bahwa hanya beberapa perusahaan yang benar-benar melakukan pengujian unit dengan perangkat lunak produksi.

Saya ingin tahu bagaimana orang-orang telah menerapkan pengujian unit di tempat kerja dan manfaat apa yang mereka dapatkan dari menggunakannya, misalnya, kualitas kode yang lebih baik, mengurangi waktu pengembangan dalam jangka panjang, dll.

unit-testing

— Anonim
sumber

13

"Mereka juga mengklaim bahwa hanya sedikit perusahaan yang melakukan uji unit dengan perangkat lunak produksi." Itu berarti hanya sedikit perusahaan yang menghasilkan perangkat lunak berkualitas tinggi. Kelompok mana yang ingin Anda selaraskan? Bagaimana "hanya beberapa perusahaan" bisa menjadi pernyataan negatif? Hanya beberapa perusahaan yang sangat menguntungkan; apakah itu membuatnya buruk? Hanya beberapa perusahaan yang benar-benar tempat yang menyenangkan untuk bekerja; apakah itu membuatnya buruk? Hanya beberapa perusahaan yang memperkecil jumlah limbah mereka; apakah itu membuatnya buruk? Komentar "hanya beberapa perusahaan" mereka tidak masuk akal.

— S.Lott

2

mungkin juga salah, secara anekdot, saya belum pernah bekerja untuk atau dengan perusahaan yang setidaknya tidak melakukan beberapa tingkat pengujian unit

— jk.

1

Saya berpendapat bahwa seorang programmer yang berpikir pengujian unit "memiliki sedikit manfaat" tidak berpengalaman, atau tidak tahu bagaimana menulis tes unit yang efektif.

— Toby

Berapa banyak pengujian unit yang digunakan pengembang situs ini?

— JeffO

1

@ S.Lott: tidak masuk akal ya, namun, masih digunakan sebagai argumen untuk tidak melakukan tes unit oleh mereka yang tidak ingin melakukannya. Saya tidak membela sudut pandang mereka di sini, justru sebaliknya. Namun pernyataan itu masih dibuat dan mereka yang membuatnya yakin akan nilainya dan karena itu kita harus meyakinkan manfaat sebenarnya dari pengujian menyikatnya karena tidak masuk akal tidak akan banyak membantu penyebab yang lebih besar.

— Newtopian

20

beberapa dari mereka menyarankan saya bahwa itu tidak perlu

Yah, dalam arti sempit mereka benar: pengujian, ulasan kode, kontrol sumber dll tidak sepenuhnya diperlukan . Hanya sedikit pengembang yang masuk akal yang bekerja tanpa ini dalam jangka panjang. Sebagian besar dari kita telah belajar (seringkali dengan cara yang sulit, dari kesalahan kita sendiri) mengapa ini adalah praktik terbaik.

dan itu memiliki sedikit manfaat.

Ini tidak benar dalam banyak kasus. Artinya, jika kita berbicara tentang perangkat lunak produksi yang seharusnya digunakan - dengan demikian dalam pemeliharaan - untuk tahun-tahun mendatang.

Mereka juga mengklaim bahwa hanya sedikit perusahaan yang melakukan uji unit dengan perangkat lunak produksi.

Ini mungkin benar (meskipun dalam pengalaman saya semakin sedikit), tetapi tidak ada yang mengatakan tentang nilai pengujian unit. Berlawanan dengan ini, lawakan lama "Sial itu bagus - 50 miliar lalat tidak mungkin salah!" ;-)

apakah Anda menerapkan tes-unit di tempat kerja Anda dan apa yang Anda dapatkan dari itu? (mis. kualitas kode yang lebih baik, kurangi waktu dalam jangka panjang, dll.)

Saya telah menerapkan tes unit dalam pekerjaan saya, kapan pun memungkinkan, selama lebih dari 10 tahun sekarang. Perasaan percaya diri pada kode saya, mengetahui bahwa itu berfungsi - dan saya bisa membuktikannya kapan saja, di mana saja, dalam beberapa detik, lagi dan lagi, yang bertentangan dengan hanya mempercayainya - sangat berharga. Ini memberi saya keberanian untuk memperbaiki kode saya, untuk meningkatkan desainnya, atau untuk memperbaiki bug, tanpa takut merusak fungsi yang ada. Saya tidak akan pernah kembali ke masa lalu "kode dan berdoa".

— Péter Török
sumber

14

Saya melakukan unittests, tetapi tidak (atau sedikit) di tempat kerja

Manfaat utama dari pengujian yang saya dapatkan adalah, bahwa refactoring jauh lebih mudah dan regresi itu (yaitu, reintroduksi kesalahan sudah diperbaiki) diperhatikan.

Menguji hidup dengan 'the build': Anda memeriksa perangkat lunak dengan menjalankan tes, dan Anda tidak memeriksa sampai semua tes berjalan dengan modifikasi Anda.

Jadi, dalam pengalaman saya, tes menulis hampir tidak berguna ketika dilakukan dengan cara yang sendirian. Ketika Anda selalu harus memperbaiki tes Anda untuk mengakomodasi perubahan yang dilakukan orang lain, ketika tes dapat dihapus oleh rekan kerja Anda (bersenang-senang di pekerjaan saya sebelumnya) karena 'mereka tidak akan membiarkan saya menyebarkan', dll. Mereka hanya bekerja ekstra dengan manfaatnya langsung dibakar oleh anggota tim lainnya.

Ketika seluruh tim setuju (dan, dalam tim 1 yang mudah), menurut pengalaman saya, tes adalah manfaat besar untuk kualitas, gaya dan kekokohan Proyek.

Tetapi dalam sebuah tim yang dengan jujur percaya bahwa 'hanya beberapa perusahaan yang menguji kode mereka secara otomatis' dan yakin bahwa mereka hanya membuang-buang waktu, tampaknya ada sedikit harapan untuk mendapatkan manfaat, tetapi kemungkinan besar Anda akan dibuat bertanggung jawab atas 'kehilangan waktu' saat menunjukkan kesalahan.

Kesempatan terbaik untuk memperkenalkan tes akan menjadi proyek kecil dalam tanggung jawab Anda sendiri. Di sana Anda akan memiliki kesempatan untuk bersinar dan menunjukkan nilai tes.

— keppla
sumber

1

Maaf kedengarannya negatif, tetapi saya masih dibakar oleh 'bagaimana menyelesaikan sesuatu sebagai gerutuan';)

— keppla

Saran yang sangat bagus Masalahnya adalah bahwa ketika dilakukan dengan benar, Anda tidak benar-benar melihat manfaat dari pengujian unit. Anda hanya berpotensi melihat bahayanya jika tidak melakukan pengujian unit. Jadi, jika Anda perlu meyakinkan orang lain dengan statistik, daripada teori, Anda cukup kacau.

— Peter Kruithof

12

@keppla, saya telah menulis unit test di proyek-proyek di mana rekan tim saya bahkan belum pernah mendengar pengujian unit sebelumnya. Setelah pengujian saya berhasil menangkap beberapa bug yang seharusnya lolos tanpa disadari, yang lain mulai memperhatikan dan segera mereka ingin belajar pengujian unit sendiri. Bukti nyata adalah raja.

— Péter Török

1

@keppla, cukup adil, jika rekan satu tim bias pada tingkat kehilangan akal sehat mereka, tidak ada cara untuk meyakinkan mereka dengan bukti logis :-( Dalam kasus seperti itu, dengan dukungan manajemen yang kuat Anda mungkin masih berhasil mendorong ide melalui , tapi tanpa itu, tidak ada harapan

— Péter Török

3

Anda 'mematahkan' tes sering dengan mengubah antarmuka, menghapus Kelas, dll. Ketika Anda melakukan 'tes pertama', Anda tidak mengalami ini sebagai 'melanggar', tetapi sebagai langkah pertama 'Merah'. Tetapi ketika Anda berada dalam pola pikir 'Cukup tambahkan beberapa garis sampai berhasil'-tes ini hanya berupa lebih banyak garis. Dan ketika 'diperbaiki' oleh seseorang seperti ini, tes cenderung menurun kegunaannya, sampai mereka benar-benar tidak ada gunanya. Memenuhi nubuat 4tw!

— keppla

7

Saya cenderung memihak kolega Anda, tetapi hanya sampai titik tertentu.

Masalah dengan tes unit adalah bahwa mereka sering dan tanpa berpikir ditulis pada kasus-kasus sepele di mana penyelidikan sepintas kode mengungkapkan bahwa itu akan berhasil tidak peduli apa. Contohnya:

def add(x, y)
  x + y
end

Bersama dengan selusin tes untuk memastikan bahwa penambahan itu memang akan bekerja untuk kasus penggunaan yang dipilih secara sewenang-wenang. Duh ...

Premis umum di balik pengujian unit adalah: jika kode Anda tidak mengandung bug, itu karena Anda belum cukup menguji. Sekarang, kapan harus menulis tes unit yang tepat. Jawaban:

Saat Anda menguji
Saat Anda debugging
Ketika Anda sedang mengembangkan hal-hal yang sangat rumit

Mari kita telusuri masing-masing, seandainya Anda sedang mengembangkan semacam aplikasi web.

Anda menulis beberapa kode ke fungsionalitas baru, dan seharusnya sudah bekerja dengan cukup baik sekarang. Anda kemudian menjangkau browser Anda dan memverifikasi bahwa itu bekerja dengan menguji lebih intensif, bukan? Bzzzt! ... Jawaban salah. Anda menulis tes unit. Jika Anda tidak melakukannya sekarang, Anda mungkin tidak akan pernah melakukannya. Dan ini adalah salah satu tempat di mana tes unit bekerja dengan sangat baik: untuk menguji fungsionalitas tingkat tinggi.

Anda kemudian menemukan bug (yang tidak pernah ketinggalan?). Ini membawa kita ke poin dua. Anda menyelam kembali ke dalam kode dan mulai mengikuti langkah-langkahnya. Ketika Anda melakukannya, tulis unit test pada titik-titik penting dimana memiliki data yang konsisten dan benar sangat penting.

Poin terakhir adalah sebaliknya. Anda sedang merancang beberapa fungsi berbulu yang melibatkan banyak pemrograman meta. Dengan cepat memunculkan pohon keputusan dengan ribuan skenario potensial, dan Anda perlu memastikan bahwa masing-masing dari mereka yang terakhir berfungsi. Saat menulis hal-hal seperti itu, perubahan yang tampak sederhana di sini atau di sana dapat memiliki konsekuensi yang tak terbayangkan lebih lanjut dalam rantai makanan. Katakanlah, Anda sedang merancang implementasi MPTT menggunakan pemicu SQL - sehingga bisa bekerja dengan pernyataan multi-baris.

Dalam lingkungan berduri seperti ini, Anda biasanya ingin mengotomatisasi tes Anda. Jadi, Anda menulis skrip untuk mengotomatiskan pembuatan data uji, dan menjalankan sejumlah besar unit uji pada data uji ini. Satu hal penting untuk tidak kehilangan jejak saat Anda melakukan ini, adalah bahwa Anda juga perlu menulis unit test untuk generator unit test Anda.

Intinya: tes unit, pasti ya. Tapi luangkan diri Anda dengan fungsionalitas dasar - sampai Anda benar-benar membutuhkannya untuk debugging, atau memastikan beberapa fungsionalitas berbulu berfungsi dengan baik (termasuk, dalam kasus terakhir, tes itu sendiri).

— Denis de Bernardy
sumber

Seperti Kent Beck katakan: "uji segala sesuatu yang mungkin bisa pecah."

— Péter Török

1

Setuju dengan sepenuh hati dengannya. Harapan utama saya adalah OP akan mencatat: jangan lupa untuk menguji tes mana yang berlaku. :-)

— Denis de Bernardy

7

Semua kode harus diuji. Tidak ada pilihan tentang itu.

Kode yang belum diuji tidak berguna: tidak dapat dipercaya untuk melakukan apa pun.

Anda dapat menulis tes unit atau Anda dapat menulis tes integrasi tingkat tinggi atau tes penerimaan.

Tes unit lebih mudah untuk ditulis, lebih mudah untuk di-debug, dan lebih mudah untuk dikelola.

Tes integrasi didasarkan pada asumsi bahwa unit tersebut benar-benar berfungsi. Tanpa tes unit, bagaimana Anda tahu unit bekerja? Bagaimana Anda bisa men-debug uji integrasi jika Anda tidak tahu bahwa masing-masing unit yang terintegrasi benar-benar berfungsi?

Tes penerimaan, sama, tergantung pada semua bagian dan bagian yang berfungsi. Bagaimana Anda bisa tahu bagian dan komponen bekerja tanpa harus memiliki serangkaian unit test?

Pengujian wajib dilakukan. Semua tes tingkat yang lebih tinggi tergantung pada unit yang benar-benar berfungsi.

Itu membuat pengujian unit kebutuhan logis. Tidak ada pilihan lain.

— S.Lott
sumber

1

Tidak ada pilihan lain ... jika Anda peduli kualitas. Sebagian besar organisasi perangkat lunak tidak benar-benar peduli dengan kualitas (sejauh ini mereka menolak untuk mengirimkan perangkat lunak yang dikenal rusak).

— Joeri Sebrechts

@ Joeri Sebrechts: Ini bukan masalah kualitas. Ini masalah "sudah selesai". Bahkan perangkat lunak yang buruk perlu diuji untuk membuktikan bahwa ia melakukan sesuatu - apa saja. Logika sederhana menyatakan bahwa harus ada tes untuk membuktikannya berhasil. Bahkan ujian yang buruk adalah ujian. Logika sederhana menyatakan bahwa pengujian keseluruhan harus mencakup pengujian bagian-bagian. Unit testing hanya diperlukan oleh logika, tidak ada yang lain. Bukan pertimbangan kualitas, tetapi dengan definisi "selesai".

— S.Lott

1

Menggunakan perangkat lunak adalah ujian tersendiri. Banyak organisasi senang membuat pengguna melakukan pengujian. Saya tidak mengatakan itu hal yang baik, tetapi memang begitu adanya. Anda memang dapat memilih untuk tidak menguji sebelum pengiriman, membongkar pengujian ke pengguna akhir. Anda bisa, tetapi Anda seharusnya tidak.

— Joeri Sebrechts

1

@ Joeri Sebrechts: Sebenarnya, Anda tidak bisa. Anda tidak dapat mengubah perangkat lunak - secara acak - ke pengguna untuk pengujian penerimaan. Anda harus menjalankan perangkat lunak setidaknya sekali untuk memastikan itu berfungsi. Itu ujian - ujian buruk - tapi ujian. Logikanya, tes buruk itu menggabungkan tes unit buruk. Mereka ada, meskipun mereka sangat buruk.

— S.Lott

definisi Anda tentang unit test tidak berguna untuk diskusi ini. Tes unit adalah tes yang dikodifikasikan dan sama sekali tidak diperlukan untuk mengirim perangkat lunak. (tapi bagus untuk dilakukan dalam banyak situasi)

— Martin Ba

6

Saya menggunakan tes unit untuk semua yang saya tulis, dan saya tidak membiarkan kode yang belum diuji melewati ulasan tanpa test case. (Tapi saya tidak memiliki alat cakupan, jadi saya harus alasan tentang cakupan tes. Satu hal pada suatu waktu ...)

Ini cukup sederhana: jika Anda tidak dapat menunjukkan bahwa kode Anda berfungsi (dan cara apa yang lebih baik daripada spesifikasi yang dapat dieksekusi dalam bentuk tes?) Maka tidak berfungsi .

Ini memberi saya:

Ketenangan pikiran: server CI saya memberi tahu saya seluruh basis kode saya berfungsi.
Kemampuan untuk meningkatkan kode saya: Saya dapat menyusun kembali kode saya - refactor it - mengetahui bahwa setelah restrukturisasi saya tidak merusak apa pun.

— Frank Shearar
sumber

2

Saya akan menambahkan satu peringatan yang sangat penting untuk itu - pengujian unit saja tidak akan menjamin bahwa "seluruh basis kode Anda berfungsi". Ini akan memastikan bahwa semua unit kode bekerja secara terpisah, tetapi masih ada kemungkinan besar untuk kesalahan integrasi, kesalahan dalam penyajian data secara visual, dll.

— Ryan Brunner

Kecuali jika lingkungan Anda melewati "jika Anda tidak dapat menunjukkan bahwa kode Anda tidak berfungsi maka itu berfungsi." : p

— Davy8

@Ryan: Tentu saja tes integrasi Anda harus menggerakkan seluruh proyek. Pertanyaannya adalah tentang tes unit jadi saya berbicara tentang tes unit, tetapi tentu saja Anda harus menunjukkan perlunya sepotong kode dengan memiliki tes integrasi yang gagal. Dan tentu saja Anda harus memiliki server CI secara otomatis menyebarkan basis kode Anda dan menjalankan semua tesl

— Frank Shearar

@ Davy8: Dalam hal ini Anda memiliki masalah lebih serius yang "melakukan pengujian unit?".

— Frank Shearar

4

Pengujian unit adalah suatu disiplin. Karena kode tidak perlu berfungsi, sering kali kode tersebut dibuang.

Namun, ini adalah metode yang terbukti yang mengarah pada kode yang kuat dan kurang buggy. Saya rasa saya tidak perlu menjelaskan manfaatnya kepada Anda, karena Anda sudah menyebutkan beberapa. Jika Anda melihat beberapa proyek open source terkemuka, apakah itu perpustakaan javascript, kerangka kerja susun penuh, atau aplikasi tujuan tunggal, semuanya menggunakan pengujian unit.

Saya curiga kolega Anda yang merekomendasikan untuk tidak menggunakannya bukan programmer. Jika ya, anggap saja tidak banyak orang yang saya nilai lebih tinggi daripada orang-orang seperti Martin Fowler atau Kent Beck ;).

Seperti kebanyakan praktik terbaik, manfaatnya bersifat jangka panjang, Anda perlu menginvestasikan waktu di dalamnya. Anda dapat menulis skrip panjang kode prosedural, tetapi kita semua tahu bahwa Anda berharap Anda telah menulisnya dengan gaya berorientasi objek ketika Anda perlu memperbaikinya setelah 2 tahun.

Hal yang sama berlaku untuk pengujian unit. Jika Anda menulis tes unit untuk bagian-bagian penting dalam aplikasi Anda, Anda dapat memastikan itu berfungsi sebagaimana dimaksud, setiap saat, bahkan setelah kode refactoring. Mungkin kode Anda sangat baik sehingga Anda tidak pernah memiliki bug regresi. Tetapi jika Anda tidak, atau seorang programmer baru bergabung dengan tim Anda, Anda ingin memastikan bahwa bug di masa lalu tidak terjadi lagi. Saya pikir bos Anda akan senang dengan itu juga, karena tidak harus mengajukan laporan bug yang dia pikir sudah diselesaikan setengah tahun yang lalu.

— Peter Kruithof
sumber

3

Unit-tes membutuhkan bahasa ramah unit-test, desain ramah-unit-test dan masalah ramah-unit-test.

C ++, desain multithreaded dan GUI akan menjadi mimpi buruk, dan cakupan masalah akan mengerikan.

NET, perakitan dll ulir tunggal yang dapat digunakan kembali, logika komputasi murni akan mudah.

Apakah itu sepadan, saya tidak bisa mengatakannya.

Apakah Anda banyak refactor? Apakah Anda melihat "bug bodoh" seperti "mati satu per satu" di kode Anda?

Apa pun yang Anda lakukan, jangan menjadi pria yang mengkritik orang lain dengan "Anda tidak memiliki tes unit, karena itu Anda payah". Jika tes membantu Anda, lakukan saja, jika tidak, itu bukan seperti peluru perak.

— Coder
sumber

1

Mengapa desain multithreaded menjadi mimpi buruk? Desain untuk titik sinkronisasi, dan uji di sana.

— Frank Shearar

1

Karena waktu tergantung pada fase bulan, jam CPU, trashing dan cukup banyak apa pun. Pada satu kali check-in, tes mungkin gagal, jika Anda beruntung, pada 1000 lainnya tidak akan berhasil.

— Coder

1

Saya telah menulis hal-hal multithreaded yang digerakkan oleh tes. Ini pasti bisa dilakukan.

— Frank Shearar

4

sampah, Anda dapat menguji unit dalam bahasa apa pun.

— jk.

1

Sulit menulis unit test untuk interaksi GUI, tapi itu sebabnya kami mengisolasi apa pun (kode engine kami) tidak ada hubungannya dengan GUI. Ini membantu kami membuat keputusan yang baik untuk memisahkan mesin dari GUI, plus, Unit Test bertindak sebagai antarmuka kami sebagai pengganti GUI, menanyakan dan memberikan informasi yang biasanya kami butuhkan.

— Peluang

3

Saya mau , tetapi saya pernah mengalami nasib sial karena hampir seluruhnya bekerja di perusahaan yang tidak peduli dengan kualitas, dan lebih fokus dengan membuang sampah yang agak mungkin bekerja-jika-Anda-menyipit. Saya telah menyebutkan unit test dan saya mendapat "Hah?" jenis tampilan (tampilan yang sama saya dapatkan ketika saya menyebutkan prinsip SOLID , atau ORM, atau pola desain di luar "kelas dengan semua metode statis", atau mengikuti konvensi penamaan .NET). Saya hanya pernah berada di satu perusahaan yang memahami hal-hal itu, dan sayangnya itu adalah kontrak jangka pendek dan departemen dipangkas untuk memotong biaya sehingga tidak ada cukup waktu untuk benar-benar belajar.

Saya telah mencoba-coba unit test dalam proyek-proyek dummy yang dapat dibuang, tetapi saya belum benar-benar memahami TDD / BDD, dan tidak memiliki seorang mentor yang dapat membantu dengan itu membuatnya menjadi jauh lebih sulit untuk dilakukan dengan benar.

— Wayne Molina
sumber

2

Kami menggunakannya. Satu manfaat besar yang kami dapatkan adalah kerangka uji unit kami memeriksa kebocoran memori dan kegagalan alokasi . Terkadang masalahnya ada di kode tes unit itu sendiri, tetapi sering kali itu dalam kode produksi.

Ini cara yang bagus untuk menemukan hal-hal yang terlewatkan dalam tinjauan kode.

Tes unit (harus) juga berjalan sangat cepat dan dapat berjalan sebagai bagian dari integrasi berkelanjutan Anda setelah setiap komitmen, dan juga oleh pengembang sebelum melakukan. Kami memiliki lebih dari 1.000 yang membutuhkan waktu kurang dari 20 detik untuk beroperasi.

Bandingkan dengan dengan 40+ menit untuk tes otomatisasi tingkat sistem, dan jam / hari untuk pengujian manual. Tentu saja, pengujian unit bukan satu-satunya pengujian yang harus Anda lakukan, tetapi pada level kode berbutir halus, mereka dapat membantu menemukan bug dan menguji kasus tepi yang tidak dapat disentuh pengujian sistem / integrasi. Kode kami harus diuji dengan cakupan keputusan lebih dari 75% dan dengan cakupan fungsi 100%, yang akan sangat sulit dicapai tanpa tes unit.

— Hugo
sumber

2

Saya akan mengatakan tes unit menambah nilai, tapi saya bukan murid TDD besar. Saya menemukan manfaat paling besar dengan tes unit ketika saya melakukan mesin kalk, atau jenis mesin apa pun dan kemudian kelas utilitas, tes unit sangat membantu saat itu.

Saya lebih suka tes integrasi otomatis untuk blok data yang lebih tergantung, tetapi semuanya tergantung, saya di bisnis data, begitu banyak kesalahan lebih banyak data yang terkait di lingkungan kita daripada yang lain, dan untuk itu tes integrasi otomatis berfungsi dengan baik. Memeriksa data sebelum dan sesudah dan menghasilkan laporan pengecualian dari tes-tes tersebut.

Jadi unit test benar-benar menambah nilai, terutama jika unit yang Anda uji dapat diberikan dengan semua input yang dibutuhkan dan bekerja sendiri dengan input yang diberikan. Sekali lagi dalam kasus saya mesin calc dan kelas utilitas adalah contoh sempurna dari ini.

— Marthinus
sumber

2

Biaya: Lebih lambat ke kode, Kurva Belajar, Inersia Pengembang

Manfaat: Umumnya saya menemukan diri saya menulis kode yang lebih baik ketika saya diuji pertama - bijaksana ...

Tetapi IMHO, manfaat terbesar yang saya pikir, adalah keandalan dalam sistem yang lebih besar yang sering berubah. Pengujian unit yang baik akan menghemat pantat Anda (jadi milik saya) ketika Anda merilis beberapa versi dan dapat menghilangkan banyak biaya yang terkait dengan proses QA manual. Tentu saja tidak akan menjamin kode bebas bug tetapi akan menangkap beberapa kode yang sulit diprediksi. Dalam sistem besar yang kompleks, ini bisa menjadi keuntungan yang sangat besar.

— Bob_Mac
sumber

0

Saya melakukan beberapa tes unit di tempat kerja ketika saya mendapat kesempatan, dan saya mencoba meyakinkan rekan-rekan saya untuk melakukan hal yang sama.

Saya tidak religius tentang hal itu, tetapi pengalaman menunjukkan bahwa metode utilitas dan bisnis yang telah diuji unit sangat kuat dan cenderung memiliki sedikit atau tidak ada bug yang muncul selama fase pengujian, yang pada akhirnya mengurangi biaya pada proyek.

— Philippe
sumber

0

Di mana saya melihat keuntungan sebenarnya dari pengkodean Tes Unit dan membuat pelaksanaan uji unit bagian dari proses pembuatan harian ada pada proyek dengan 30+ pengembang yang bekerja di 3 benua yang berbeda. Di mana tes unit benar-benar bersinar adalah ketika seseorang secara halus mengubah kelas yang mereka pertahankan tanpa memahami bagaimana orang menggunakan kelas itu. Alih-alih menunggu kode untuk mengenai kelompok pengujian, ada umpan balik langsung ketika tes unit orang lain mulai gagal sebagai akibat dari perubahan. [Itu sebabnya semua unit test perlu dijalankan secara rutin, bukan hanya yang Anda tulis untuk kode Anda.]

Pedoman saya untuk pengujian unit adalah:

Uji setiap kondisi yang dapat Anda pikirkan untuk kode Anda, termasuk input yang buruk, batasan, dll.
Semua Tes Unit untuk Semua Modul harus dijalankan secara teratur (yaitu sebagai bagian dari bangunan malam)
Periksa hasil Tes Unit!
Jika seseorang menemukan bug dalam kode Anda yang melewati tes Anda, tulis tes baru untuk itu!

— jerny
sumber

0

Saya baru-baru ini mempelajari TDD dan menemukan bahwa itu sangat berguna. Ini memberi keyakinan lebih besar bahwa kode saya berperilaku seperti yang saya harapkan. Seiring dengan membuat re-factoring yang ingin saya lakukan lebih mudah. Setiap kali bug ditemukan Anda dapat memastikan bahwa melalui pengujian itu tidak akan muncul lagi.

Bagian tersulit adalah menulis yang baik tes unit.

Ini adalah patokan yang baik untuk kode Anda.

— Schleis
sumber