berapa banyak waktu yang Anda habiskan untuk pengujian Unit?


27

Di perusahaan tempat saya bekerja, para eksekutif bersikeras bahwa cakupan kode dengan uji unit harus 99% atau lebih. Ini menghasilkan lebih banyak tes daripada kode. Kami benar-benar membutuhkan 3 hari untuk menulis tes untuk satu kelas yang membutuhkan satu hari untuk diimplementasikan.

Namun, sebagai hasilnya, saya belajar banyak tentang TDD, alat pengujian, praktik, dll.

Di perusahaan tempat saya bekerja setelah itu, pengujian unit adalah hal yang tidak diketahui. Itu adalah sesuatu yang mungkin pernah didengar seseorang. Saya berjuang untuk memperkenalkan mereka pada konsep pengujian unit, tetapi tanpa efek.

Sekarang, sebagai wiraswasta, saya bertanya-tanya - berapa banyak waktu yang benar - benar diperlukan untuk dihabiskan untuk pengujian unit? Menjadi sebagian besar pengembang iPhone / Android, bagian mana dari kode yang harus dicakup dalam pengujian?


Di perusahaan saya sebelumnya, itu Java EE, stripes and struts framework. Seperti yang saya katakan, sekarang sebagian besar pengembangan iPhone dan Android.
Maggie

TDD berarti Anda menulis tes sebelum kode. Sepertinya ini adalah pengujian "setelah fakta", yang merupakan hal lain.

manajer tidak peduli dengan teknik ini, pemimpin tim saya bersikeras pada TDD. itu berakhir sebagai kombinasi keduanya :)
Maggie

Maggie, Anda mungkin menemukan artikel ini menarik: fastcompany.com/magazine/06/writestuff.html

Apakah ada beberapa metrcis untuk memperkirakan waktu? Alat untuk kode JS / .NET?
Hellboy

Jawaban:


16

Jumlah pengujian unit yang diperlukan tergantung pada beberapa faktor:

  • Ukuran Produk (Semakin besar proyek, semakin besar kebutuhan untuk menyertakan setidaknya beberapa pengujian unit)
  • Level Kualitas yang Diperlukan (Jika Anda dengan cepat menyatukan perangkat lunak yang perlu keluar secepat mungkin dan beberapa bug kecil dapat diterima, maka Anda mungkin terpaksa melewati beberapa pengujian seperti pengujian unit)
  • Jenis Produk (UI dapat diuji unit, tetapi kadang-kadang lebih mudah untuk melewatkan pengujian unit pada bagian GUI yang berat dari sebuah proyek dan bukannya menguji secara manual)
  • Kemampuan / Riwayat Pengkodean Anda (Jenis bug apa yang biasanya Anda buat? Apakah itu hal-hal yang biasanya ditangkap oleh Unit Testing atau hal-hal yang biasanya ditemukan oleh tipe pengujian lain. Mengetahui hal ini mungkin mendorong Anda untuk melakukan lebih atau kurang pengujian unit)

10

Dalam kelompok produk kami, kami menargetkan cakupan kode 50-70% dari pengujian unit dan 90% + cakupan dari pengujian unit dan otomatisasi pengujian digabungkan. Waktu umum yang dianggarkan untuk tes unit penulisan adalah sekitar 1 hari untuk setiap fitur yang membutuhkan 3-4 hari pengkodean head down. Tapi itu bisa bervariasi dengan banyak faktor.

Cakupan kode 99% bagus. Tes unit sangat bagus. Tetapi 99% cakupan kode dari pengujian unit saja? Saya merasa sulit untuk percaya bahwa Anda bisa mendapatkan cakupan sebanyak itu dari pengujian unit saja.

Untuk kasus di mana Anda menghabiskan 3 hari menulis tes untuk kelas yang dinyatakan membutuhkan 1 hari untuk diterapkan. Anda tidak menjelaskan mengapa perlu waktu lama atau membagikan kode apa pun. Dari spekulasi, saya kira Anda tidak benar-benar menulis unit test yang benar untuk kelas Anda, tetapi sebenarnya menulis otomatisasi tes . Dan sebenarnya tidak ada yang salah dengan itu - selama Anda mengenali perbedaan antara dua jenis tes yang berbeda.

Tetapi Anda mengatakan tiga hari penulisan tes hanya untuk satu kelas. Mungkin kelas itu sendiri tidak dirancang untuk pengujian unit. Apakah kelas menerapkan UI? Jaringan? File I / O? Jika demikian, Anda mungkin akhirnya menulis lebih banyak kode untuk menguji runtime Java daripada logika bisnis Anda yang berinteraksi dengan runtime.

TDD membuat Anda berpikir dalam hal antarmuka dan antarmuka untuk dependensi. Kelas tunggal yang mengimplementasikan UI, jaringan, dan file / io untuk fitur tunggal mungkin lebih baik disajikan dibagi menjadi beberapa kelas - satu untuk jaringan, satu untuk file / io, dan UI dipecah menjadi desain model-viewer-controller. Kemudian Anda dapat menerapkan tes yang sesuai untuk masing-masing dengan objek tiruan sederhana untuk dependensi. Tentu saja, semua ini membutuhkan lebih banyak waktu. Jadi, daripada 1 hari untuk kode dan 3 hari untuk menulis tes, jenis desain ini mungkin memerlukan 3 hari pengkodean dan 1 hari tes menulis. Tetapi kode akan jauh lebih baik dipelihara dan digunakan kembali.


1
Jawaban yang bagus Sebagian besar terlalu rumit untuk pengujian, Anda benar tentang itu. Dan untuk membagi kelas menjadi beberapa unit yang lebih kecil hanya agar sesuai dengan tes unit yang lebih baik tampaknya sedikit - berlebihan. Saya ingin melampirkan kode untuk kelas dan tes pendamping, dan saya ingin mendengar pendapat Anda, tetapi saya tidak yakin apakah saya diizinkan. Kode ini bukan sepenuhnya milik saya, dan saya tidak bekerja lagi untuk perusahaan itu, jadi saya ingin menghindari masalah.
Maggie

2
Itu sebabnya Anda harus menulis tes terlebih dahulu. Kemudian Anda dapat menemukan tempat-tempat alami di mana logika direkatkan.

10

Tes unit terbayar pada waktu pemeliharaan. Jika Anda berencana untuk memiliki aplikasi lama, Anda akan menghabiskan lebih banyak waktu pemeliharaan daripada yang Anda pikirkan sekarang (jika Anda belum mencoba ini, Anda akan terkejut berapa lama proyek yang sukses dapat hidup)

Apa yang Anda inginkan, adalah bahwa jika Anda secara tidak sengaja mengubah fungsionalitas tes Anda pecah sehingga Anda menemukan hal-hal ini secepat mungkin. Pelanggan sangat tidak suka ketika fungsi berubah secara tak terduga.


3
Dan Anda terlihat buruk ketika Anda memperbaiki bug A hanya untuk memperkenalkan bug B & C.
JeffO

tergantung apakah B dan C ditangkap oleh tes atau tidak

"Anda akan menghabiskan lebih banyak waktu untuk mempertahankan daripada yang Anda pikirkan sekarang" - tentu saja, terutama dengan mempertimbangkan bahwa produk-produk SW biasanya hidup lebih lama dari yang direncanakan, seringkali jauh.
Péter Török

Anda tidak dapat "merencanakan" untuk memiliki aplikasi yang tahan lama karena Anda tidak dapat memastikan sebelumnya apakah proyek tersebut akan berhasil atau tidak. Anda harus selalu mempertimbangkan itu ketika menganggarkan waktu untuk pengujian
Eran Galperin

1
@ Eran, jadi Anda harus merencanakan kegagalan sehingga Anda tidak perlu membuat anggaran untuk tes?

4

Jika Anda melakukan TDD, Anda akan menulis tes pada saat yang sama dengan kode, beralih di antara mereka setiap beberapa menit (atau kurang.) Tidak akan ada waktu yang berbeda dihabiskan untuk tes. Menggunakan TDD membuatnya lebih mudah untuk mengetahui bahwa Anda memiliki cakupan tes yang solid.

Jika Anda adalah Unit testing setelah fakta, Anda perlu menulis tes yang akan memberi tahu Anda jika kode rusak karena perubahan. Saya tidak akan mengandalkan metrik cakupan di sini, tetapi akan didasarkan pada kasus penggunaan dan parameter untuk antarmuka publik. Ini pada akhirnya akan didasarkan pada selera dan pengalaman Anda yang baik.


Yap, bagi saya ini benar (sebenarnya saya biasanya siklus antara mengerjakan tes dan mengerjakan kode produk setiap beberapa detik , bukan menit.) Jadi saya bisa dibilang mengerjakan tes 100% setiap saat.
Jonathan Hartley

2

Jika Anda tidak akan menghabiskan waktu untuk tes, Anda akan menghabiskan lebih banyak waktu untuk debug dalam kode langsung.
Jadi habiskan waktu sebanyak yang dibutuhkan untuk tes, untuk mencakup semua (atau 99% kode).


4
Mengapa orang memiliki paranoia debugging seperti itu? Jika Anda tahu alatnya, Anda jarang mengalami masalah yang membutuhkan lebih dari 5 menit untuk melakukan debug. Masalah yang sulit di-debug sebagian besar terkait dengan threading, tetapi tes unit tidak berguna di sana.
Coder

3
@Coder, karena orang-orang memiliki pengalaman dan tahu bahwa tes jauh lebih bermanfaat daripada debugging buta.
OZ_

2
Tergantung. Unit-test seringkali kontra-produktif dan menambah rasa aman yang salah. Dan dalam kode terstruktur dengan baik Anda tidak akan masuk ke masalah "debugging buta". Anda mendapatkan masalah, Anda tahu ke mana harus mencari. Jika tidak, lakukan tinjauan kode / desain lengkap. Lihat juga: programmers.stackexchange.com/questions/86636/…
Coder

4
Itulah masalah dengan banyak pendukung TDD, mereka memiliki sikap bermusuhan terhadap debugging dan desain, sambil mengandalkan tes untuk menemukan semua bug. Kemudian, dalam kode produksi, aplikasi bocor memori, pegangan, dan crash pada multi-core, dan mereka seperti? WTH ?. TDD hanyalah alat, dan tergantung pada tugas yang dihadapi bisa sangat produktif, atau sangat kontraproduktif. Cobalah untuk menulis unit-test untuk semua hard case di pos yang ditautkan, dan Anda tidak akan pernah mengirimkan produk.
Coder

1
"Jika Anda tahu alatnya, Anda jarang mengalami masalah yang membutuhkan lebih dari 5 menit untuk debug." - @Coder Saya ingin tahu jenis aplikasi apa yang Anda lihat.
Kirk Broadhurst

2

Seperti yang telah dicatat oleh orang lain, sebagian besar tergantung pada jenis perangkat lunak. Rasio waktu pengujian / pengembangan 3: 1 yang Anda sebutkan mungkin agak terlalu banyak untuk proyek rata-rata, tetapi mungkin sangat oke untuk aplikasi misi kritis dan mungkin bahkan terlalu sedikit untuk sistem yang kritis.

Cakupan unit tes 99+% sama mungkin terlalu banyak untuk diharapkan dalam kasus aplikasi rata-rata, tetapi terlalu sedikit untuk proyek yang kritis.

Dalam pengalaman saya, mengingat bahwa bagian penting dari kode produksi adalah kode penanganan kesalahan, cakupan 80-90% akan cukup untuk sebagian besar aplikasi, dan ini bisa memerlukan kira-kira jumlah waktu yang sama yang dihabiskan untuk menulis tes unit sebagai kode produksi. (Kemudian lagi, jika seseorang bekerja dengan sungguh-sungguh dalam mode TDD, keduanya sepenuhnya terjalin untuk secara praktis menjadi satu tugas tunggal, sehingga orang hanya dapat memperkirakan nilai rasio aktual.)


apakah Anda memiliki pengalaman dalam aplikasi seluler? rasio uji / pengembangan apa yang dapat diterima untuk aplikasi seluler sederhana?
Maggie

@ Maggie, sayangnya tidak. (Jadi jika saya perlu menulis satu, saya mungkin akan menghabiskan lebih dari waktu saya biasanya pada pengujian unit :-)
Péter Török
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.