it-swarm-id.com

Apakah Pengujian Unit sepadan dengan usaha?

Saya sedang berupaya mengintegrasikan pengujian unit ke dalam proses pengembangan di tim tempat saya bekerja dan ada beberapa skeptis. Apa beberapa cara yang baik untuk meyakinkan pengembang skeptis pada tim tentang nilai Unit Testing? Dalam kasus khusus saya, kami akan menambahkan Tes Unit saat kami menambahkan fungsionalitas atau bug yang diperbaiki. Sayangnya basis kode kami tidak cocok untuk pengujian mudah.

573
Ross Fuhrman

Setiap hari di kantor kami ada pertukaran yang berlangsung seperti ini:

"Ya ampun, aku suka tes unit, aku baru saja bisa membuat banyak perubahan pada cara sesuatu bekerja, dan kemudian bisa memastikan aku tidak merusak apa pun dengan menjalankan tes lagi ..."

Detailnya berubah setiap hari, tetapi sentimennya tidak. Tes unit dan pengembangan yang digerakkan oleh tes (TDD) memiliki begitu banyak manfaat tersembunyi dan pribadi serta yang jelas sehingga Anda tidak dapat benar-benar menjelaskan kepada seseorang sampai mereka melakukannya sendiri.

Tapi, mengabaikan itu, ini usahaku!

  1. Tes Unit memungkinkan Anda membuat perubahan besar pada kode dengan cepat. Anda tahu itu berfungsi sekarang karena Anda telah menjalankan tes, ketika Anda membuat perubahan yang perlu Anda buat, Anda perlu menjalankan tes lagi. Ini menghemat waktu.

  2. TDD membantu Anda menyadari kapan harus berhenti coding. Tes Anda memberi Anda keyakinan bahwa Anda telah melakukan cukup untuk saat ini dan dapat berhenti mengutak-atik dan beralih ke hal berikutnya.

  3. Tes dan kode bekerja bersama untuk mencapai kode yang lebih baik. Kode Anda bisa buruk/bermasalah. UJI Anda bisa buruk/bermasalah. Dalam TDD Anda mengandalkan kemungkinan keduanya menjadi buruk/bermasalah. Seringkali ini adalah tes yang perlu diperbaiki tetapi itu masih merupakan hasil yang baik.

  4. TDD membantu mengkodekan sembelit. Saat dihadapkan dengan pekerjaan besar dan menakutkan di depan menulis tes akan membuat Anda bergerak cepat.

  5. Tes Unit membantu Anda benar-benar memahami desain kode yang sedang Anda kerjakan. Alih-alih menulis kode untuk melakukan sesuatu, Anda mulai dengan menjabarkan semua kondisi yang Anda kenakan kode dan apa output yang Anda harapkan dari itu.

  6. Unit Test memberi Anda umpan balik visual instan, kita semua menyukai perasaan semua lampu hijau ketika kita sudah selesai. Sangat memuaskan. Ini juga jauh lebih mudah untuk mengambil di mana Anda tinggalkan setelah gangguan karena Anda dapat melihat di mana Anda harus - lampu merah berikutnya yang perlu diperbaiki.

  7. Bertentangan dengan pengujian unit kepercayaan populer tidak berarti menulis kode dua kali lebih banyak, atau coding lebih lambat. Ini lebih cepat dan lebih kuat daripada pengkodean tanpa tes setelah Anda bisa menguasainya. Kode tes itu sendiri biasanya relatif sepele dan tidak menambah biaya besar untuk apa yang Anda lakukan. Ini adalah salah satu yang Anda hanya akan percaya ketika Anda melakukannya :)

  8. Saya pikir itu Fowler yang mengatakan: "Tes tidak sempurna, sering berjalan, jauh lebih baik daripada tes sempurna yang tidak pernah ditulis sama sekali". Saya menafsirkan ini sebagai memberi saya izin untuk menulis tes di mana saya pikir mereka akan sangat berguna bahkan jika sisa cakupan kode saya sangat tidak lengkap.

  9. Tes unit yang baik dapat membantu mendokumentasikan dan menentukan apa yang seharusnya dilakukan

  10. Tes unit membantu penggunaan kembali kode. Migrasikan kedua kode Anda dan tes Anda ke proyek baru Anda. Tweak kode hingga tes berjalan lagi.

Banyak pekerjaan yang saya lakukan dengan Unit Test tidak baik (interaksi pengguna aplikasi web dll), tetapi meskipun demikian kita semua tes terinfeksi di toko ini, dan paling bahagia ketika kita memiliki tes kami terikat. Saya tidak bisa merekomendasikan pendekatan yang cukup tinggi.

722
reefnet_alex

Pengujian unit sangat mirip pergi ke gym. Anda tahu itu baik untuk Anda, semua argumen masuk akal, jadi Anda mulai berolahraga. Ada Rush awal, yang bagus, tetapi setelah beberapa hari Anda mulai bertanya-tanya apakah itu sepadan dengan masalahnya. Anda menghabiskan satu jam dari hari Anda untuk berganti pakaian dan berlari menggunakan roda hamster dan Anda tidak yakin benar-benar mendapatkan apa pun selain sakit kaki dan lengan.

Kemudian, setelah mungkin satu atau dua minggu, tepat ketika rasa sakit hilang, Batas Waktu Besar mulai mendekat. Anda perlu menghabiskan setiap jam bangun untuk menyelesaikan pekerjaan "berguna", jadi Anda hentikan hal-hal asing, seperti pergi ke gym. Anda keluar dari kebiasaan itu, dan pada saat Big Deadline berakhir, Anda kembali ke titik awal. Jika Anda berhasil kembali ke gym, Anda akan merasa sama sakitnya dengan pertama kali Anda pergi.

Anda membaca, untuk melihat apakah Anda melakukan sesuatu yang salah. Anda mulai merasa sedikit dendam yang tidak masuk akal terhadap semua yang cocok, orang-orang bahagia memuji kebajikan olahraga. Anda menyadari bahwa Anda tidak memiliki banyak kesamaan. Mereka tidak perlu berkendara 15 menit untuk pergi ke gym; ada satu di gedung mereka. Mereka tidak perlu berdebat dengan siapa pun tentang manfaat olahraga; itu hanya sesuatu yang dilakukan dan diterima semua orang sebagai hal yang penting. Ketika Tenggat Besar mendekat, mereka tidak diberi tahu bahwa olahraga tidak perlu seperti yang diminta bos Anda untuk berhenti makan.

Jadi, untuk menjawab pertanyaan Anda, Unit Testing biasanya sepadan dengan usaha, tetapi jumlah upaya yang diperlukan tidak akan sama untuk semua orang. Unit Testing mungkin memerlukan banyak usaha jika Anda berurusan dengan basis kode spaghetti di perusahaan yang tidak benar-benar kualitas kode nilai. (Banyak manajer akan menyanyikan pujian Unit Testing, tetapi itu tidak berarti mereka akan mendukungnya ketika itu penting.)

Jika Anda mencoba memperkenalkan Unit Testing ke dalam pekerjaan Anda dan tidak melihat semua sinar matahari dan pelangi seperti yang Anda duga, jangan salahkan diri Anda. Anda mungkin perlu mencari pekerjaan baru untuk benar-benar membuat Unit Testing bekerja untuk Anda.

421
benzado

Cara terbaik untuk meyakinkan ... menemukan bug, menulis tes unit untuk itu, memperbaiki bug.

Bug khusus itu sepertinya tidak akan pernah muncul lagi, dan Anda dapat membuktikannya dengan pengujian Anda.

Jika Anda cukup melakukan ini, orang lain akan cepat mengerti.

136
Ed Guiness

thetalkingwalnut bertanya:

Apa beberapa cara yang baik untuk meyakinkan pengembang skeptis pada tim tentang nilai Unit Testing?

Semua orang di sini akan menumpuk banyak alasan mengapa pengujian unit baik. Namun, saya menemukan bahwa sering kali cara terbaik untuk meyakinkan seseorang tentang sesuatu adalah dengan mendengarkan untuk argumen mereka dan mengatasinya poin demi poin. Jika Anda mendengarkan dan membantu mereka mengungkapkan kekhawatiran mereka, Anda dapat mengatasi masing-masing dan mungkin mengubahnya menjadi sudut pandang Anda (atau paling tidak, biarkan mereka tanpa kaki untuk berdiri di atas). Siapa yang tahu? Mungkin mereka akan meyakinkan Anda mengapa unit test tidak sesuai untuk situasi Anda. Tidak mungkin, tetapi mungkin. Mungkin jika Anda memposting argumen mereka terhadap unit test, kami dapat membantu mengidentifikasi kontra argumen.

Penting untuk mendengarkan dan memahami kedua sisi argumen. Jika Anda mencoba untuk mengadopsi tes unit terlalu bersemangat tanpa memperhatikan kekhawatiran orang, Anda akan berakhir dengan perang agama (dan mungkin tes unit benar-benar tidak berharga). Jika Anda mengadopsinya perlahan dan mulai dengan menerapkannya di tempat Anda akan melihat manfaat paling besar dengan biaya yang paling murah, Anda mungkin dapat menunjukkan nilai tes unit dan memiliki peluang yang lebih baik untuk meyakinkan orang. Saya menyadari ini tidak semudah kedengarannya - biasanya membutuhkan waktu dan metrik hati-hati untuk membuat argumen yang meyakinkan.

Tes unit adalah alat, seperti yang lainnya, dan harus diterapkan sedemikian rupa sehingga manfaat (menangkap bug) lebih besar daripada biaya (upaya menulisnya). Jangan menggunakannya jika/di mana mereka tidak masuk akal dan ingat bahwa mereka hanya bagian dari gudang alat Anda (mis. Inspeksi, pernyataan, penganalisa kode, metode formal, dll). Apa yang saya katakan kepada pengembang saya adalah ini:

  1. Mereka dapat bolos menulis tes untuk suatu metode jika mereka memiliki argumen yang bagus mengapa itu tidak perlu (misalnya terlalu sederhana untuk menjadi layak atau terlalu sulit untuk menjadi layak) dan bagaimana metode itu akan diverifikasi (misalnya inspeksi, pernyataan , metode formal, tes interaktif/integrasi). Mereka perlu mempertimbangkan bahwa beberapa verifikasi seperti inspeksi dan bukti formal dilakukan pada suatu titik waktu dan kemudian perlu diulang setiap kali kode produksi berubah, sedangkan unit test dan pernyataan dapat digunakan sebagai tes regresi (ditulis sekali dan dilaksanakan berulang kali sesudahnya). ). Kadang-kadang saya setuju dengan mereka, tetapi lebih sering saya akan berdebat tentang apakah suatu metode benar-benar terlalu sederhana atau terlalu sulit untuk unit test.

    • Jika seorang pengembang berpendapat bahwa suatu metode tampaknya terlalu mudah untuk gagal, bukankah perlu mengambil 60 detik yang diperlukan untuk menulis unit test 5-line sederhana untuk itu? Ini 5 baris kode akan berjalan setiap malam (Anda membangun malam, kan?) Untuk tahun berikutnya atau lebih dan akan bernilai usaha jika bahkan sekali saja terjadi untuk menangkap masalah yang mungkin memerlukan waktu 15 menit atau lebih lama untuk mengidentifikasi dan debug. Selain itu, menulis unit test yang mudah menaikkan hitungan unit test, yang membuat pengembang terlihat bagus.

    • Di sisi lain, jika pengembang berpendapat bahwa suatu metode tampaknya terlalu sulit untuk unit test (tidak sepadan dengan upaya signifikan yang diperlukan), mungkin itu adalah indikasi yang baik bahwa metode tersebut perlu dibagi atau di refactored untuk menguji bagian yang mudah. Biasanya, ini adalah metode yang mengandalkan sumber daya yang tidak biasa seperti lajang, waktu saat ini, atau sumber daya eksternal seperti kumpulan hasil basis data. Metode ini biasanya perlu di refactored menjadi metode yang mendapatkan sumber daya (mis. Panggilan getTime ()) dan metode yang menggunakan sumber daya sebagai argumen (mis. Menggunakan stempel waktu sebagai parameter). Saya membiarkan mereka melewatkan pengujian metode yang mengambil sumber daya dan mereka malah menulis tes unit untuk metode yang sekarang mengambil sumber daya sebagai argumen. Biasanya, ini membuat penulisan unit test lebih sederhana dan karena itu layak untuk ditulis.

  2. Pengembang perlu menggambar "garis di pasir" dalam seberapa komprehensif tes unit mereka seharusnya. Kemudian dalam pengembangan, setiap kali kami menemukan bug, mereka harus menentukan apakah unit test yang lebih komprehensif akan menangkap masalah. Jika demikian dan jika bug semacam itu muncul berulang kali, mereka perlu memindahkan "baris" ke arah penulisan unit test yang lebih komprehensif di masa mendatang (dimulai dengan menambah atau memperluas tes unit untuk bug saat ini). Mereka perlu menemukan keseimbangan yang tepat.

Yang penting untuk menyadari unit test bukan peluru perak dan ada adalah yang namanya terlalu banyak unit testing. Di tempat kerja saya, setiap kali kami melakukan pelajaran, saya pasti mendengar "kita perlu menulis lebih banyak unit test". Manajemen mengangguk setuju karena sudah terbentur di kepala mereka bahwa "unit test" == "bagus".

Namun, kita perlu memahami dampak "lebih banyak tes unit". Seorang pengembang hanya dapat menulis ~ N baris kode seminggu dan Anda perlu mencari tahu berapa persen dari kode itu harus menjadi kode uji unit vs kode produksi. Tempat kerja yang longgar mungkin memiliki 10% dari kode sebagai tes unit dan 90% dari kode sebagai kode produksi, menghasilkan produk dengan banyak fitur (walaupun sangat buggy) (pikirkan MS Word). Di sisi lain, toko ketat dengan unit test 90% dan kode produksi 10% akan memiliki produk yang solid dengan fitur yang sangat sedikit (pikirkan "vi"). Anda mungkin tidak pernah mendengar laporan tentang jatuhnya produk yang terakhir, tetapi kemungkinan besar itu berkaitan dengan produk yang tidak terjual dengan sangat baik seperti halnya dengan kualitas kode.

Lebih buruk lagi, mungkin satu-satunya kepastian dalam pengembangan perangkat lunak adalah bahwa "perubahan tidak bisa dihindari". Asumsikan toko yang ketat (90% unit test/10% kode produksi) menciptakan produk yang persis memiliki 2 fitur (dengan asumsi 5% dari kode produksi == 1 fitur). Jika pelanggan datang dan mengubah 1 fitur, maka perubahan itu menghancurkan 50% dari kode (45% dari tes unit dan 5% dari kode produksi). Toko longgar (tes unit 10%/kode produksi 90%) memiliki produk dengan 18 fitur, tidak ada yang bekerja dengan sangat baik. Pelanggan mereka benar-benar mengubah persyaratan untuk 4 fitur mereka. Meskipun perubahannya 4 kali lebih besar, hanya setengah dari basis kode yang dibuang (~ 25% = ~ 4.4% unit test + 20% dari kode produksi).

Maksud saya adalah Anda harus berkomunikasi bahwa Anda memahami keseimbangan antara terlalu sedikit dan terlalu banyak pengujian unit - pada dasarnya Anda telah memikirkan kedua sisi masalah. Jika Anda dapat meyakinkan rekan-rekan Anda dan/atau manajemen Anda tentang hal itu, Anda mendapatkan kredibilitas dan mungkin memiliki peluang yang lebih baik untuk memenangkannya.

69
Bert F

Saya telah mempermainkan unit pengujian beberapa kali, dan saya masih harus diyakinkan bahwa itu sepadan dengan usaha yang diberikan situasi saya.

Saya mengembangkan situs web, di mana banyak dari logika melibatkan membuat, mengambil atau memperbarui data dalam database. Ketika saya telah mencoba untuk "mengejek" database untuk keperluan pengujian unit, itu menjadi sangat berantakan dan tampak agak sia-sia.

Ketika saya telah menulis unit test di sekitar logika bisnis, itu tidak pernah benar-benar membantu saya dalam jangka panjang. Karena saya sebagian besar mengerjakan proyek sendiri, saya cenderung tahu secara intuitif area kode mana yang mungkin dipengaruhi oleh sesuatu yang saya kerjakan, dan saya menguji area ini secara manual. Saya ingin memberikan solusi kepada klien saya secepat mungkin, dan pengujian unit seringkali tampak membuang-buang waktu. Saya daftar tes manual dan berjalan melalui mereka sendiri, berdetak saat aku pergi.

Saya dapat melihat bahwa itu mungkin bermanfaat ketika tim pengembang sedang mengerjakan suatu proyek dan memperbarui kode masing-masing, tetapi bahkan kemudian saya berpikir bahwa jika pengembang memiliki kualitas tinggi, komunikasi yang baik dan kode yang ditulis dengan baik seringkali harus cukup. .

38
Ronnie

Satu hal hebat tentang unit test adalah mereka berfungsi sebagai dokumentasi untuk bagaimana kode Anda seharusnya berperilaku. Tes yang baik seperti implementasi referensi, dan rekan tim dapat melihatnya untuk melihat bagaimana mengintegrasikan kode mereka dengan kode Anda.

31
pkaeding

Unit-testing layak investasi awal. Sejak mulai menggunakan unit-testing beberapa tahun yang lalu, saya telah menemukan beberapa manfaat nyata:

  • pengujian regresi menghilangkan rasa takut membuat perubahan pada kode (tidak ada yang seperti cahaya hangat melihat kode bekerja atau meledak setiap kali perubahan dilakukan)
  • contoh kode yang dapat dieksekusi untuk anggota tim lainnya (dan diri Anda dalam waktu enam bulan ..)
  • tanpa ampun refactoring - ini sangat bermanfaat, cobalah!

Cuplikan kode dapat sangat membantu dalam mengurangi overhead pembuatan tes. Tidaklah sulit untuk membuat cuplikan yang memungkinkan pembuatan garis besar kelas dan perlengkapan uji unit terkait dalam hitungan detik.

26
Jonathan Webb

Anda harus menguji sesedikit mungkin!

artinya, Anda harus menulis tes unit yang cukup untuk mengungkapkan niat. Ini sering disingkirkan. Biaya pengujian unit Anda. Jika Anda melakukan perubahan dan Anda harus mengubah tes, Anda akan lebih gesit. Buat tes unit singkat dan manis. Maka mereka memiliki banyak nilai.

Terlalu sering saya melihat banyak tes yang tidak akan pernah pecah, besar dan canggung dan tidak menawarkan banyak nilai, mereka hanya akhirnya memperlambat Anda.

25
Keith Nicholas

Saya tidak melihat ini di jawaban lain, tetapi satu hal yang saya perhatikan adalah saya bisa men-debug jauh lebih cepat. Anda tidak perlu menelusuri aplikasi Anda hanya dengan urutan langkah yang tepat untuk mendapatkan kode perbaikan Anda, hanya untuk menemukan Anda telah membuat kesalahan boolean dan perlu melakukan semuanya lagi. Dengan uji unit, Anda bisa langsung masuk ke kode yang Anda debug.

23
John MacIntyre

[Saya punya alasan untuk membuat saya tidak bisa melihat di atas]

"Semua orang menguji unit, mereka tidak harus menyadarinya - FAKTA"

Pikirkan tentang hal ini, Anda menulis fungsi untuk mengurai string dan menghapus karakter baris baru. Sebagai pengembang pemula, Anda menjalankan beberapa kasus melalui itu dari baris perintah dengan mengimplementasikannya di Main () atau Anda memukul ujung depan visual dengan tombol, mengikat fungsi Anda ke beberapa kotak teks dan tombol dan melihat apa yang terjadi.

Itu adalah unit testing - dasar dan disatukan tetapi Anda menguji potongan kode untuk beberapa kasus.

Anda menulis sesuatu yang lebih kompleks. Itu melempar kesalahan ketika Anda melempar beberapa kasus melalui (pengujian unit) dan Anda debug ke dalam kode dan melacak. Anda melihat nilai saat Anda melewati dan memutuskan apakah itu benar atau salah. Ini adalah pengujian unit sampai tingkat tertentu.

Unit testing di sini benar-benar mengambil perilaku itu, memformalkannya menjadi pola terstruktur dan menyimpannya sehingga Anda dapat dengan mudah menjalankan kembali tes-tes tersebut. Jika Anda menulis case test unit "layak" daripada pengujian secara manual, dibutuhkan waktu yang sama, atau mungkin kurang dari yang Anda alami, dan Anda dapat mengulanginya berulang kali

21
Chris Gill

Selama bertahun-tahun, saya telah mencoba meyakinkan orang bahwa mereka perlu menulis unit test untuk kode mereka. Apakah mereka menulis tes pertama (seperti dalam TDD) atau setelah mereka membuat kode fungsi, saya selalu mencoba menjelaskan kepada mereka semua manfaat memiliki unit test untuk kode. Hampir tidak ada yang tidak setuju dengan saya. Anda tidak dapat tidak setuju dengan sesuatu yang jelas, dan setiap orang pintar akan melihat manfaat dari tes unit dan TDD.

Masalah dengan pengujian unit adalah bahwa hal itu membutuhkan perubahan perilaku, dan sangat sulit untuk mengubah perilaku orang. Dengan kata-kata, Anda akan membuat banyak orang setuju dengan Anda, tetapi Anda tidak akan melihat banyak perubahan dalam cara mereka melakukan sesuatu.

Anda harus meyakinkan orang dengan melakukan. Kesuksesan pribadi Anda akan menarik lebih banyak orang daripada semua argumen yang Anda miliki. Jika mereka melihat Anda tidak hanya berbicara tentang unit test atau TDD, tetapi Anda melakukan apa yang Anda khotbahkan, dan Anda berhasil, orang akan mencoba meniru Anda.

Anda juga harus mengambil peran utama karena tidak ada yang menulis unit test dengan benar pertama kali, jadi Anda mungkin perlu melatih mereka tentang cara melakukannya, menunjukkan kepada mereka jalannya, dan alat yang tersedia untuk mereka. Bantu mereka saat mereka menulis tes pertama mereka, tinjau tes yang mereka tulis sendiri, dan tunjukkan trik, idiom, dan pola yang telah Anda pelajari melalui pengalaman Anda sendiri. Setelah beberapa saat, mereka akan mulai melihat manfaatnya sendiri, dan mereka akan mengubah perilaku mereka untuk memasukkan tes unit atau TDD ke dalam kotak peralatan mereka.

Perubahan tidak akan terjadi dalam semalam, tetapi dengan sedikit kesabaran, Anda dapat mencapai tujuan Anda.

16
Curro

Bagian utama dari pengembangan yang digerakkan oleh tes yang sering diabaikan adalah penulisan kode yang dapat diuji. Sepertinya ada semacam kompromi pada awalnya, tetapi Anda akan menemukan bahwa kode yang dapat diuji juga pada akhirnya bersifat modular, dapat dipelihara dan dapat dibaca. Jika Anda masih membutuhkan bantuan meyakinkan orang ini adalah presentasi sederhana yang bagus tentang kelebihan pengujian unit.

12
Tom Martin

Jika basis kode Anda saat ini tidak cocok untuk pengujian unit, dan sudah dalam produksi, Anda mungkin menciptakan lebih banyak masalah daripada Anda menyelesaikannya dengan mencoba untuk memperbaiki semua kode Anda sehingga dapat diuji unit.

Anda mungkin lebih baik berupaya meningkatkan pengujian integrasi Anda. Ada banyak kode di luar sana yang lebih sederhana untuk ditulis tanpa uji unit, dan jika QA dapat memvalidasi fungsionalitas terhadap dokumen persyaratan, maka Anda selesai. Kirim itu.

Contoh klasik dari ini dalam pikiran saya adalah SqlDataReader yang tertanam di halaman ASPX yang ditautkan ke GridView. Semua kode ada dalam file ASPX. SQL berada dalam prosedur tersimpan. Apa yang Anda uji unit? Jika halaman melakukan apa yang seharusnya dilakukan, haruskah Anda benar-benar mendesain ulang menjadi beberapa lapisan sehingga Anda memiliki sesuatu untuk diotomatisasi?

11
Eric Z Beard

Salah satu hal terbaik tentang pengujian unit adalah bahwa kode Anda akan menjadi lebih mudah untuk diuji saat Anda melakukannya. Kode yang sudah ada sebelumnya dibuat tanpa tes selalu merupakan tantangan karena karena mereka tidak dimaksudkan untuk diuji unit, tidak jarang memiliki tingkat kopling antar kelas yang tinggi, objek yang sulit dikonfigurasikan di dalam kelas Anda - seperti email mengirim referensi layanan - dan sebagainya. Tapi jangan biarkan ini menjatuhkanmu! Anda akan melihat bahwa keseluruhan desain kode Anda akan menjadi lebih baik ketika Anda mulai menulis unit-test, dan semakin Anda menguji, Anda akan semakin percaya diri dalam membuat lebih banyak perubahan tanpa takut merusak aplikasi Anda atau memperkenalkan bug .

Ada beberapa alasan untuk menguji unit kode Anda, tetapi seiring berjalannya waktu, Anda akan mengetahui bahwa waktu yang Anda hemat dalam pengujian adalah salah satu alasan terbaik untuk melakukannya. Dalam sistem yang baru saja saya sampaikan, saya berkeras melakukan pengujian unit otomatis meskipun ada klaim bahwa saya akan menghabiskan lebih banyak waktu melakukan tes daripada melakukan pengujian sistem secara manual. Dengan semua unit test saya selesai, saya menjalankan lebih dari 400 test case dalam waktu kurang dari 10 menit, dan setiap kali saya harus melakukan perubahan kecil pada kode, semua saya perlu memastikan bahwa kode itu masih berfungsi tanpa bug adalah sepuluh menit. Bisakah Anda bayangkan waktu yang dihabiskan seseorang untuk menjalankan 400+ test case dengan tangan?

Ketika datang ke pengujian otomatis - baik itu pengujian unit atau pengujian penerimaan - semua orang berpikir itu adalah upaya yang sia-sia untuk kode apa yang dapat Anda lakukan secara manual, dan kadang-kadang itu benar - jika Anda berencana untuk menjalankan tes Anda hanya sekali. Bagian terbaik dari pengujian otomatis adalah Anda dapat menjalankannya beberapa kali tanpa usaha, dan setelah menjalankan kedua atau ketiga, waktu dan upaya yang Anda sia-sia sudah dibayar.

Satu saran terakhir adalah untuk tidak hanya menguji unit kode Anda, tetapi mulai melakukan tes terlebih dahulu (lihat TDD dan BDD untuk lebih lanjut)

10
Alexandre Brasil

Tes unit juga sangat berguna ketika datang ke refactoring atau menulis ulang sepotong kode. Jika Anda memiliki cakupan tes unit yang baik, Anda dapat melakukan refactor dengan percaya diri. Tanpa tes unit, seringkali sulit untuk memastikan Anda tidak merusak apa pun.

8
killdash10

Saya bekerja sebagai teknisi pemeliharaan dari basis kode yang buruk, buruk dan terdokumentasi dengan buruk. Saya berharap orang-orang yang menulis kode telah menulis unit test untuknya.
Setiap kali saya melakukan perubahan dan memperbarui kode produksi, saya khawatir saya akan memperkenalkan bug karena tidak mempertimbangkan suatu kondisi.
Jika mereka menulis tes, membuat perubahan pada basis kode akan lebih mudah dan lebih cepat (pada saat yang sama basis kode akan dalam keadaan yang lebih baik) ..

Saya pikir unit test terbukti sangat berguna ketika menulis api atau kerangka kerja yang harus bertahan selama bertahun-tahun dan untuk digunakan/dimodifikasi/dikembangkan oleh orang-orang selain coders asli.

7
mic.sca

Singkatnya - ya. Mereka bernilai setiap ons usaha ... sampai titik tertentu. Tes, pada akhirnya, masih berupa kode, dan mirip dengan pertumbuhan kode yang khas, tes Anda pada akhirnya akan perlu di refactored agar dapat dipertahankan dan berkelanjutan. Ada satu ton GOTCHAS! ketika datang ke unit testing, tetapi man oh man oh man, tidak ada, dan maksud saya TIDAK ADA memberdayakan pengembang untuk membuat perubahan lebih percaya diri daripada serangkaian unit test yang kaya.

Saya sedang mengerjakan sebuah proyek sekarang .... ini agak TDD, dan kami memiliki sebagian besar aturan bisnis kami yang dihapus sebagai tes ... kami memiliki sekitar 500 atau lebih unit test sekarang. Iterasi yang lalu ini saya harus mengubah sumber data kami dan bagaimana aplikasi desktop kami berinteraksi dengan sumber data itu. Butuh waktu beberapa hari, sepanjang waktu saya terus menjalankan unit test untuk melihat apa yang saya rusak dan memperbaikinya. Membuat perubahan; Bangun dan jalankan tes Anda; perbaiki apa yang kamu bangkrut. Cuci, Bilas, Ulangi seperlunya. Apa yang secara tradisional akan memakan waktu berhari-hari QA dan banyak kapal stres bukan pengalaman pendek dan menyenangkan.

Bersiaplah di depan, sedikit usaha ekstra, dan membayar 10 kali lipat nanti ketika Anda harus mulai bergaul dengan fitur inti/fungsionalitas.

Saya membeli buku ini - itu adalah Alkitab pengetahuan xUnit Testing - ini mungkin salah satu buku yang paling direferensikan di rak saya, dan saya mengkonsultasikannya setiap hari: tautan teks

7
cranley

Kadang-kadang baik saya atau salah satu rekan kerja saya akan menghabiskan beberapa jam untuk sampai ke dasar bug yang sedikit tidak jelas dan begitu penyebab bug ditemukan 90% dari waktu kode tidak diuji unit. Tes unit tidak ada karena dev memotong sudut untuk menghemat waktu, tetapi kemudian kehilangan ini dan lebih banyak debug.

Mengambil sedikit waktu untuk menulis unit test dapat menghemat berjam-jam debugging di masa depan.

7
Jon Cahill

Ketika Anda berkata, "basis kode kami tidak cocok untuk pengujian mudah" adalah tanda pertama dari bau kode. Tes Unit Penulisan berarti Anda biasanya menulis kode secara berbeda untuk membuat kode lebih dapat diuji. Ini adalah hal yang baik menurut saya karena apa yang saya lihat selama bertahun-tahun dalam menulis kode yang harus saya tulis, itu memaksa saya untuk membuat desain yang lebih baik.

6
Keith Elder

Saya tidak tahu. Banyak tempat tidak melakukan uji unit, tetapi kualitas kodenya bagus. Microsoft melakukan pengujian unit, tetapi Bill Gates memberi layar biru pada presentasinya.

6
BigTiger

Unit Testing jelas layak dilakukan. Sayangnya Anda telah memilih skenario yang sulit (tapi sayangnya umum) untuk diterapkan.

Manfaat terbaik dari pengujian unit yang akan Anda dapatkan adalah ketika menggunakannya dari bawah ke atas - pada beberapa, pilih, proyek kecil Saya cukup beruntung untuk menulis pengujian unit saya sebelum mengimplementasikan kelas saya (antarmuka sudah lengkap saat ini) titik). Dengan tes unit yang tepat, Anda akan menemukan dan memperbaiki bug di kelas Anda saat mereka masih dalam masa pertumbuhan dan tidak berada di dekat sistem kompleks yang pasti akan terintegrasi di masa depan.

Jika perangkat lunak Anda berorientasi objek padat, Anda harus dapat menambahkan pengujian unit di tingkat kelas tanpa terlalu banyak usaha. Jika Anda tidak seberuntung itu, Anda harus tetap mencoba menggabungkan pengujian unit di mana pun Anda bisa. Pastikan ketika Anda menambahkan fungsionalitas baru, potongan baru didefinisikan dengan baik dengan antarmuka yang jelas dan Anda akan menemukan pengujian unit membuat hidup Anda lebih mudah.

6
Matt

Saya menulis posting blog yang sangat besar tentang topik tersebut. Saya telah menemukan bahwa pengujian unit saja tidak sesuai dengan pekerjaan dan biasanya dipotong ketika tenggat waktu semakin dekat.

Alih-alih berbicara tentang pengujian unit dari sudut pandang verifikasi "pengujian", kita harus melihat nilai sebenarnya yang ditemukan ketika Anda mulai menulis spesifikasi/pengujian/ide sebelum implementasi.

Gagasan sederhana ini telah mengubah cara saya menulis perangkat lunak dan saya tidak akan kembali ke cara "lama".

Bagaimana ujian pengembangan pertama mengubah hidup saya

5
Toran Billups

Satu hal yang belum ada yang disebutkan adalah mendapatkan komitmen semua pengembang untuk benar-benar menjalankan dan memperbarui tes otomatis yang ada. Tes otomatis yang Anda dapatkan kembali dan rusak karena pengembangan baru kehilangan banyak nilai dan membuat pengujian otomatis sangat menyakitkan. Sebagian besar dari tes tersebut tidak akan menunjukkan bug karena pengembang telah menguji kode secara manual, sehingga waktu yang dihabiskan untuk memperbaruinya hanya sia-sia.

Meyakinkan orang yang skeptis untuk tidak menghancurkan pekerjaan yang dilakukan orang lain pada unit-test jauh lebih penting untuk mendapatkan nilai dari pengujian dan mungkin lebih mudah.

Menghabiskan berjam-jam memperbarui tes yang rusak karena fitur baru setiap kali Anda memperbarui dari repositori tidak produktif atau menyenangkan.

3
Samuel Åslund

Saya menemukan TDD beberapa tahun yang lalu, dan sejak itu menulis semua proyek hewan peliharaan saya menggunakannya. Saya memperkirakan bahwa dibutuhkan waktu yang hampir sama untuk proyek TDD seperti yang dibutuhkan untuk koboi bersama, tetapi saya memiliki kepercayaan diri yang meningkat pada produk akhir sehingga saya tidak dapat menahan perasaan pencapaian.

Saya juga merasa bahwa itu meningkatkan gaya desain saya (jauh lebih berorientasi antarmuka jika saya perlu mengejek hal-hal bersama-sama) dan, ketika tulisan hijau di atas menulis, itu membantu dengan "coding konstipation": ketika Anda tidak tahu apa untuk menulis selanjutnya, atau Anda memiliki tugas yang menakutkan di depan Anda, Anda dapat menulis kecil.

Akhirnya, saya menemukan bahwa sejauh ini aplikasi TDD yang paling berguna adalah dalam debugging, jika hanya karena Anda telah mengembangkan kerangka kerja interogasi yang dengannya Anda dapat mendorong proyek untuk menghasilkan bug dengan cara yang berulang.

3
Kaz Dragon

Ya - Unit Testing jelas sepadan dengan usaha tetapi Anda harus tahu itu bukan peluru perak. Unit Testing bekerja dan Anda harus bekerja untuk menjaga agar tes tetap diperbarui dan relevan ketika kode berubah tetapi nilai yang ditawarkan sepadan dengan usaha yang Anda harus lakukan. Kemampuan untuk refactor dengan impunitas adalah manfaat besar karena Anda selalu dapat memvalidasi fungsionalitas dengan menjalankan tes Anda setelah kode perubahan apa pun. Triknya adalah jangan terlalu terpaku pada unit kerja yang Anda uji atau bagaimana Anda menguji persyaratan tes dan ketika tes unit benar-benar tes fungsional, dll. Orang akan berdebat tentang hal ini selama berjam-jam. pada akhirnya dan kenyataannya adalah bahwa setiap pengujian yang Anda lakukan sebagai kode tulis Anda lebih baik daripada tidak melakukannya. Aksioma lainnya adalah tentang kualitas dan bukan kuantitas - Saya telah melihat basis kode dengan 1000-an tes yang pada dasarnya tidak berarti karena sisanya tidak benar-benar menguji sesuatu yang berguna atau apapun yang spesifik domain seperti aturan bisnis, dll dari domain tertentu. Saya juga telah melihat basis kode dengan cakupan kode 30% tetapi pengujiannya relevan, bermakna dan benar-benar mengagumkan ketika mereka menguji fungsionalitas inti dari kode yang ditulis untuk dan menyatakan bagaimana kode harus digunakan.

Salah satu trik favorit saya ketika menjelajahi kerangka kerja baru atau basis kode adalah menulis unit-test untuk 'itu' untuk menemukan cara kerja. Ini cara yang bagus untuk belajar lebih banyak tentang sesuatu yang baru daripada membaca dokumen kering :)

3
Vinny Carpenter

Saya baru-baru ini melalui pengalaman yang sama persis di tempat kerja saya dan menemukan sebagian besar dari mereka tahu manfaat teoretis tetapi harus dijual mengenai manfaatnya secara khusus, jadi inilah poin yang saya gunakan (berhasil):

  • Mereka menghemat waktu ketika melakukan pengujian negatif, di mana Anda menangani input yang tidak terduga (null pointer, nilai di luar batas, dll), karena Anda dapat melakukan semua ini dalam satu proses.
  • Mereka memberikan umpan balik langsung pada waktu kompilasi mengenai standar perubahan.
  • Mereka berguna untuk menguji representasi data internal yang mungkin tidak terpapar selama runtime normal.

dan yang besar ...

  • Anda mungkin tidak memerlukan pengujian unit, tetapi ketika orang lain masuk dan memodifikasi kode tanpa pemahaman penuh, hal itu dapat menangkap banyak kesalahan konyol yang mungkin mereka lakukan.
3
dlanod

Dari pengalaman saya, tes unit dan tes integrasi adalah "HARUS TELAH" dalam lingkungan perangkat lunak yang kompleks.

Untuk meyakinkan pengembang dalam tim Anda untuk menulis unit test, Anda mungkin ingin mempertimbangkan untuk mengintegrasikan analisis regresi unit test dalam lingkungan pengembangan Anda (misalnya, dalam proses pembuatan harian Anda).

Setelah pengembang tahu bahwa jika sebuah unit test gagal mereka tidak perlu menghabiskan begitu banyak waktu untuk debugging untuk menemukan masalah, mereka akan lebih didorong untuk menulisnya.

Inilah alat yang menyediakan fungsionalitas seperti itu:

alat analisis regresi unit test

2
Liorp

Jika Anda menggunakan NUnit, satu demo sederhana namun efektif adalah menjalankan test suite NUnit sendiri di depannya. Melihat test suite nyata memberikan basis kode latihan bernilai ribuan kata ...

2
Garth Gilmour

Satu hal yang perlu diingat tentang pengujian unit adalah kenyamanan bagi pengembang.

Sebaliknya, tes fungsional untuk pengguna: setiap kali Anda menambahkan tes fungsional, Anda menguji sesuatu yang akan dilihat pengguna. Ketika Anda menambahkan tes unit, Anda hanya membuat hidup Anda lebih mudah sebagai pengembang. Ini sedikit mewah dalam hal itu.

Ingatlah dikotomi ini ketika Anda harus membuat pilihan antara menulis unit atau tes fungsional.

2
Cedric Beust

Saya setuju dengan sudut pandang yang berlawanan dengan mayoritas di sini: Tidak apa-apa Untuk Tidak Menulis Tes Unit Khusus pemrograman prototipe-berat (AI misalnya) sulit untuk digabungkan dengan pengujian unit.

2
DSblizzard

Pengujian unit sangat membantu dalam proyek yang lebih besar daripada yang bisa dipegang oleh satu pengembang. Mereka memungkinkan Anda untuk menjalankan unit test suite sebelum checkin dan mengetahui apakah Anda memecahkan sesuatu. Ini mengurangi lot pada kasus harus duduk dan bermain-main dengan ibu jari Anda sambil menunggu orang lain untuk memperbaiki bug yang mereka laporkan, atau pergi ke kerumitan mengembalikan perubahan mereka sehingga Anda bisa mendapatkan pekerjaan selesai Ini juga sangat berharga dalam refactoring, sehingga Anda dapat yakin bahwa kode yang dire-refour melewati semua tes yang dilakukan oleh kode asli.

2
Max Rible Kaehn

Dengan unit test suite, seseorang dapat membuat perubahan pada kode sambil membiarkan fitur lainnya tetap utuh. Ini keuntungan besar. Apakah Anda menggunakan unit test sutie dan suite uji regresi ketika Anda selesai mengkode fitur baru.

2
Shinwari

Inti dari pengujian unit adalah untuk membuat pengujian mudah. Ini otomatis. "tes" dan Anda selesai. Jika salah satu masalah yang Anda hadapi adalah sulit untuk menguji kode, itulah alasan terbaik dari semuanya untuk menggunakan pengujian unit.

1
Deathbob

Baru hari ini, saya harus mengubah kelas di mana tes unit telah ditulis sebelumnya.
Tes itu sendiri ditulis dengan baik dan termasuk skenario pengujian yang bahkan tidak saya pikirkan.
Untungnya semua tes lulus, dan perubahan saya cepat diverifikasi dan dimasukkan ke dalam lingkungan tes dengan percaya diri.

1
crowne

Saat Anda menguji perangkat lunak secara manual, Anda biasanya memiliki serangkaian kecil tes/tindakan yang Anda gunakan. Akhirnya, Anda akan secara otomatis mengubah data input atau tindakan sehingga Anda menavigasi diri sendiri di sekitar masalah yang diketahui. Tes unit harus ada untuk mengingatkan Anda bahwa segala sesuatu tidak berfungsi dengan benar.

Saya merekomendasikan penulisan tes sebelum kode, menambahkan tes/data baru untuk mengembangkan fungsionalitas kode utama!

1
Ray Hayes

Sebagai seorang mahasiswa fisika saya sangat terdorong untuk benar-benar membuktikan bahwa kode saya berfungsi sebagaimana mestinya. Anda bisa membuktikan ini secara logis, yang meningkatkan kesulitan secara drastis karena implementasi menjadi lebih kompleks, atau Anda dapat membuat (sedekat mungkin) bukti fungsi empiris melalui pengujian yang baik.

Jika Anda tidak memberikan bukti fungsi yang logis, Anda harus menguji. Satu-satunya alternatif adalah mengatakan "Saya pikir kodenya berfungsi ...."

1
Fredrik

@ George Stocker "Sayangnya basis kode kami tidak cocok untuk pengujian mudah." Semua orang setuju bahwa ada manfaat untuk pengujian unit tetapi sepertinya untuk basis kode ini biayanya tinggi. Jika biayanya lebih besar dari manfaatnya, mengapa mereka harus antusias? Dengarkan rekan kerja Anda; mungkin bagi mereka rasa sakit yang dirasakan dari unit test lebih besar dari nilai yang dirasakan dari unit test.

Secara khusus, cobalah untuk mendapatkan nilai sesegera mungkin, dan bukan nilai "xUnit is green", tetapi kode bersih yang dihargai pengguna dan pengelola. Mungkin Anda harus mengamanatkan tes unit untuk satu iterasi dan kemudian mendiskusikan apakah itu sepadan dengan usaha atau tidak.

1
Trystan Spangler

Buat hal pertama yang Anda uji tidak terkait dengan unit testing Saya bekerja sebagian besar di Perl, jadi ini adalah contoh spesifik Perl, tetapi Anda dapat beradaptasi.

  • Apakah setiap modul dimuat dan dikompilasi dengan benar? Di Perl, ini adalah masalah membuat Foo.t untuk setiap Foo.pm dalam basis kode yang:

    use_ok( 'Foo' );
    
  • Apakah semua POD (Plain Ol 'Documentation) diformat dengan benar? Gunakan Test :: Pod untuk memvalidasi validitas pemformatan semua POD di semua file.

Anda mungkin tidak berpikir ini adalah hal-hal besar, dan mereka tidak, tetapi saya dapat menjamin Anda akan mendapatkan sesuatu yang buruk. Ketika tes ini berjalan satu jam sekali, dan itu menangkap komitmen dini seseorang, Anda akan meminta orang mengatakan "Hei, itu keren sekali."

1
Andy Lester

Salah satu manfaat dari pengujian unit adalah prediktabilitas.

Sebelum pengujian unit, saya bisa memperkirakan keakuratan tingkat tinggi berapa lama waktu yang dibutuhkan untuk kode sesuatu, tetapi tidak berapa banyak waktu yang saya perlukan untuk men-debug itu.

Hari-hari ini, karena saya dapat merencanakan tes apa yang akan saya tulis, saya tahu berapa lama pengkodean akan dilakukan, dan pada akhir pengkodean, sistem sudah didebug! Ini membawa kemungkinan untuk proses pengembangan, yang menghilangkan banyak tekanan tetapi masih mempertahankan semua kegembiraan !!.

1
Raz

Unit Testing adalah salah satu metodologi yang paling banyak diadopsi untuk kode berkualitas tinggi. Kontribusinya terhadap kode yang lebih stabil, independen dan terdokumentasi terbukti dengan baik. Kode uji unit dipertimbangkan dan ditangani sebagai bagian integral dari repositori Anda, dan karenanya memerlukan pengembangan dan pemeliharaan. Namun, pengembang sering menghadapi situasi di mana sumber daya diinvestasikan dalam unit test di mana tidak sebanyak yang diharapkan. Dalam dunia yang ideal setiap metode yang kami kodekan akan memiliki serangkaian tes yang mencakup kodenya dan memvalidasi kebenarannya. Namun, biasanya karena keterbatasan waktu, kami melewatkan beberapa tes atau menulis yang berkualitas buruk. Dalam kenyataan seperti itu, sambil mengingat jumlah sumber daya yang diinvestasikan dalam pengembangan dan pemeliharaan unit pengujian, kita harus bertanya pada dirinya sendiri, mengingat waktu yang tersedia, kode mana yang paling layak untuk diuji? Dan dari tes yang ada, tes mana yang benar-benar layak disimpan dan dipertahankan? Lihat di sini

0
RoiG

Pengujian unit membantu Anda merilis perangkat lunak dengan bug lebih sedikit sambil mengurangi biaya pengembangan keseluruhan. Anda dapat mengeklik tautan untuk membaca lebih lanjut tentang manfaat pengujian unit

0
Steve_0

Siapa yang Anda coba meyakinkan? Insinyur atau manajer? Jika Anda mencoba meyakinkan rekan kerja insinyur Anda, saya pikir taruhan terbaik Anda adalah dengan mengajukan banding kepada keinginan mereka untuk membuat perangkat lunak berkualitas tinggi. Ada banyak penelitian yang menunjukkan menemukan bug, dan jika mereka peduli melakukan pekerjaan yang baik, itu sudah cukup bagi mereka.

Jika Anda mencoba meyakinkan manajemen, kemungkinan besar Anda harus melakukan semacam pertimbangan biaya/manfaat dengan mengatakan bahwa biaya cacat yang tidak terdeteksi lebih besar daripada biaya penulisan tes. Pastikan untuk memasukkan juga biaya yang tidak dapat ditebak, seperti hilangnya kepercayaan pelanggan, dll.

0
Craig H

Ini sangat. Net-sentris, tetapi apakah ada yang mencoba Pex?

Saya sangat skeptis sampai saya mencobanya - dan wow, kinerja yang luar biasa. Sebelum saya berpikir "Saya tidak akan diyakinkan oleh konsep ini sampai saya mengerti apa yang sebenarnya lakukan bermanfaat bagi saya". Butuh satu langkah bagi saya untuk berubah pikiran dan berkata "Saya tidak peduli bagaimana Anda tahu ada risiko pengecualian fatal di sana, tetapi there is dan sekarang saya tahu saya harus menghadapinya "

Mungkin satu-satunya downside ke perilaku ini adalah bahwa ia akan menandai semuanya dan memberi Anda backlog enam bulan. Tetapi, jika Anda memiliki hutang kode, Anda selalu memiliki hutang kode, Anda hanya tidak mengetahuinya. Memberitahu PM ada potensi dua ratus ribu poin kegagalan ketika sebelum Anda menyadari beberapa lusin adalah prospek yang buruk, yang berarti sangat penting bahwa konsepnya adalah dijelaskan terlebih dahulu.

0
Tom W