Seberapa besar proyek saya perlu bagi saya untuk mengujinya? [Tutup]


86

Saya berasumsi bahwa proyek saya cukup dipisahkan untuk memungkinkan pengujian unit. Tetapi seberapa besar, tepatnya, dalam hal klas dan fungsi yang dibutuhkan proyek saya untuk menjadikan pengujian unit bermanfaat?

Kita semua membuat kesalahan dan tidak ada yang sempurna, tapi saya menganggap diri saya seorang programmer yang layak untuk menangani kesalahan proyek kecil dengan melangkah. Atau apakah pengujian unit merupakan kebutuhan yang sulit, tidak peduli berapa ukuran proyek Anda?


26
Asumsi besar yang salah yang Anda buat adalah bahwa proyek ini hanya untuk Anda dan hanya untuk saat ini . Bagaimana jika Anda meninggalkannya selama beberapa bulan, melakukan sesuatu yang lain, lalu kembali ke sana? Apakah Anda memiliki keyakinan yang sama tentang menjadi "programmer yang layak" (yang tidak ada hubungannya dengan apakah akan diuji atau tidak)? Bagaimana jika orang lain mengambil alih proyek Anda ...? Seorang blogger yang hebat (sayangnya tidak lagi aktif) menulis bahwa Anda harus selalu "melayani pembaca kode, bukan penulis kode".
Amos M. Carpenter

6
Bagaimana dengan ini (dimaksudkan untuk C # .NET): int x = 3 * (1/3); apa nilai yang disimpan dalam x setelah operasi selesai? Maksud saya bahkan satu kode baris mungkin memerlukan pengujian karena dapat menyebabkan bug, baik karena Anda tidak tahu atau karena Anda tahu tetapi melakukan kode yang salah.
NoChance

2
@ Ahamo, saya pikir Anda kehilangan poin saya. Fakta bahwa saya ditanyai pertanyaan ini saja menunjukkan bahwa saya mempertimbangkan untuk melayani pembaca kode juga.
Lamin Sanneh

13
Setelah melakukannya dengan dua cara, saya dapat memberi tahu Anda jauh lebih mudah untuk menulis tes saat Anda melanjutkan (yaitu ketika proyek ini kecil) daripada kembali dan menulis unit test nanti ketika Anda merasa proyek telah bertemu dengan beberapa arbitrer " kita harus menulis tes sekarang "kondisi.
Wonko the Sane

1
Anda mengajukan pertanyaan yang salah. Tidak masalah seberapa besar proyeknya. Pertanyaannya adalah, seberapa peduli Anda apakah itu benar? Jika kebenaran itu penting, maka unit test adalah cara yang efektif untuk meningkatkan kebenaran.
Mark E. Haase

Jawaban:


206

Proyek Anda sudah cukup besar.

Dalam pengalaman saya, satu kelas dan satu fungsi sudah cukup untuk mempertimbangkan kebutuhan pengujian unit.

    class Simple {
        boolean reallySimple() {
            return true; // how do we make sure it doesn't change to false?
        }
    }


    class SimpleTest {
        void assertReallySimple() {
            // ensure reallySimple return value isn't changed unexpectedly
            UnitTestFramework.assertTrue(new Simple().reallySimple());
        }
    }

24
Tentunya Anda harus memulai lebih awal, pada titik fungsi 0 class / 0 ... jika Anda mengikuti TDD :)
Kaz Dragon

115
+1. Jika program Anda cukup besar untuk memiliki bug, cukup besar untuk memiliki unit test.
Jason Orendorff

9
@JasonOrendorff: Saya mengejeknya ke poster dan meletakkannya di kantor saya. Cemerlang.
Justin ᚅᚔᚈᚄᚒᚔ

Selain itu memungkinkan untuk refactoring "aman".
Timo

7
Meskipun saya tidak selalu tidak setuju dengan sentimen, jika kode Anda benar-benar sesederhana itu, Anda mungkin bisa lolos hanya dengan pernyataan bukannya pengujian unit penuh.
Chuu

109

Saya tidak pernah setuju dengan ide "Anda harus menguji segalanya", meskipun ada orang-orang di luar sana yang memiliki (lihat jawaban nyamuk !).

Sejauh yang saya ketahui, manfaat utama dari pengujian unit adalah:

  1. Membantu memastikan perubahan tidak merusak.
  2. Membantu Anda mendesain antarmuka yang masuk akal ke kelas Anda (karena itu memaksa Anda untuk menjadi klien untuk kode Anda sendiri).
  3. Membantu mendokumentasikan bagaimana kode Anda diharapkan untuk digunakan.

Pada dasarnya Anda perlu mempertimbangkan waktu yang diperlukan untuk menulis & mempertahankan tes terhadap faktor-faktor ini.

Nomor 1 biasanya cukup untuk membuatnya layak untuk tes tulis. Dalam pengalaman saya,> 95% kode akan dimodifikasi cepat atau lambat.


8
Setuju dengan ini - ketika bekerja di satu toko pengembang Anda perlu menemukan keseimbangan antara kualitas perangkat lunak dan menguji segalanya (yang bisa menghabiskan banyak waktu Anda). Jangan lupa bahwa setiap kali Anda melakukan perubahan, Anda mungkin perlu memodifikasi tes unit Anda agar sesuai
Matt Wilko

1
Anda seharusnya tidak menguji semuanya, tetapi Anda harus menguji perilaku apa pun yang terpapar ke dunia luar. Ada / memang biaya perawatan untuk pengujian, dan seperti yang dikatakan Kent Beck dalam beberapa jawaban SO (saya pikir itu SO) - cukup uji untuk membuat Anda yakin bahwa kode Anda benar.
Wayne Werner

10
Saya akan menambahkan bahwa jika Anda hanya melakukan pengujian otomatis minimal, pengujian unit adalah level yang salah untuk ditargetkan. Alih-alih pergi untuk tes integrasi / asap tingkat tinggi yang mendorong beberapa set data melalui ujung ke ujung aplikasi Anda tanpa mengejek apa pun. Anda ingin tes ini menggunakan basis kode sebanyak mungkin dan mencakup semua kasus penggunaan normal dan jalur eksekusi. Peluang 75% untuk mengetahui perubahan Anda merusak sesuatu, di suatu tempat, dalam aplikasi lebih menguntungkan daripada peluang 5% untuk mengetahui Anda melanggar SomeClass.OneOfTheHandfulOfTestedFunctions ().
Dan Neely

3
Eh, saya pikir Anda melewatkan satu: "Memastikan kode berfungsi sebagaimana mestinya!"
BlueRaja - Danny Pflughoeft

3
@ BlueRaja-DannyPflughoeft: Sebenarnya, akan lebih akurat untuk mengatakan: "Memastikan kode melewati tes unit yang telah Anda tulis!"
vaughandroid

34

Ini sederhana: Anda tidak perlu pengujian unit jika Anda akan membuang program setelah menjalankannya sekali.

Jika ini tampak berlebihan bagi Anda, pertimbangkan apa artinya alternatif itu. Jika ada beberapa ukuran di bawah yang tidak dibayar pengujian unit, Anda harus terus menilai dalam pikiran Anda: "Sudahkah saya mencapai ukuran ajaib? Haruskah saya mulai menulis tes?" Sekarang, programmer terkenal buruk dalam memprediksi masa depan, dan mereka terkenal buruk dalam menilai keterampilan mereka sendiri. Kode yang terlihat sangat jelas bagi Anda sekarang akan menjadi tidak bisa dipahami, bahkan untuk Anda, bahkan dengan menunggu sebulan. Sebuah proyek yang Anda yakini benar-benar yakin tidak akan pernah digunakan lagi, dan bahwa Anda tetap bertahan hanya jika Anda ingin mencari tahu bagaimana Anda memecahkan sesuatu sebelumnya, akan diminta lagi, dan akan menerima permintaan perubahan.

Karena itu sangat mungkin Anda akan salah menilai apakah pengujian itu membantu atau tidak, dan ketika Anda mulai perlu tes, Anda sudah tidak 100% yakin apa sebenarnya yang harus diuji oleh semantik sebenarnya. Karena saya percaya bahwa semua program kecuali sepele yang didapat dari tes unit, saya menganggap biaya upaya yang dikeluarkan untuk tes yang tidak pernah berjalan lagi dapat diabaikan terhadap risiko memperpanjang kode yang belum diuji dan dipahami dengan buruk.


22
Programmer terkenal buruk menilai kemampuan mereka sendiri dalam memprediksi masa depan
superM

3
@superM Saya setuju dengan Anda. Program "lari sekali dan buang" yang sudah saya tulis selama karier singkat saya semua tetap, dijalankan setiap beberapa hari, dan menjadi kritis bisnis. Saya menyebutnya "temporarmanent" alias efek sementara-permanen .... sigh
Jalayn

@ Jayn Bukankah jawaban hanya bahwa seseorang harus kembali dan menambahkan tes unit segera setelah realisasi ini menyerang?
Cornel Masson

@CornelMasson Anda memang benar, berharap bahwa seringkali sulit untuk meyakinkan manajer bahwa "belum selesai" karena tes belum ada :-)
Jalayn

@Jalayn: Terlalu benar!
Cornel Masson

22

Beberapa waktu lalu saya menemukan posting yang bagus: Mengapa pengujian unit mempercepat pengembangan . Ini dapat membantu Anda menjawab pertanyaan itu.

... Bagaimana jika basis kode ... diberikan seperangkat unit test yang substansial. Satu set yang akan mengatakan: "jika semua tes berhasil, saya jamin kode itu tetap melakukan apa yang harus dilakukan" dan jika tes gagal itu persis menunjukkan kepada Anda di mana beberapa perilaku rusak. Ini hebat, saya bisa mengubah kode untuk menambahkan hal yang saya inginkan tanpa berkeliaran jika kode masih melakukan apa yang seharusnya dilakukan, saya hanya menjalankan ... tes dan saya memiliki keyakinan. Ini adalah dunia yang luar biasa sebagai insinyur perangkat lunak. Saya perhatikan bahwa saya bisa maju lebih cepat ...

Saya memiliki "iman".

Ini mungkin alasan paling penting mengapa unit test mempercepat pengembangan dalam konteks perusahaan.

Saya bisa percaya bahwa semuanya masih berfungsi jika semua tes lulus. Jika tes gagal mereka akan menunjukkan dengan tepat di mana masalahnya ...

... Anda harus memiliki cakupan tes unit yang tinggi dan tes unit yang baik . Ketika kondisi ini dihormati Anda akan menemukan diri Anda dalam situasi bahwa upaya untuk menambahkan fungsionalitas baru hampir tidak tergantung pada ukuran aplikasi dan dalam jangka panjang itu akan mempercepat pengembangan .

Michael Feathers memperkenalkan dalam salah satu bukunya dua cara untuk bekerja dengan perubahan kode:

  • edit dan berdoa,
  • tutup dan modifikasi.

Tidak masalah seberapa besar basis kode.


18

Menurut Kent Beck dalam jawabannya untuk pertanyaan Stack Overflow Seberapa dalam tes unit Anda? , Anda harus menguji kode yang cenderung salah.

Jika saya biasanya tidak membuat kesalahan (seperti mengatur variabel yang salah dalam konstruktor), saya tidak mengujinya.


4
Poin bagus, dan ini menyiratkan bahwa pertanyaan OP salah; apakah untuk menguji tidak ada hubungannya dengan ukuran proyek. Basis kode 5-baris mungkin memerlukan tes, dan metode 1-baris dalam basis kode besar mungkin tidak (meskipun hal-hal lain dalam basis kode itu dilakukan).
Nathan Long

Ini mungkin bekerja untuk proyek-proyek kecil yang Anda kerjakan sendiri, tetapi untuk proyek yang dilakukan untuk pekerjaan (di mana Anda tidak mengontrol siapa yang akan mengerjakannya di masa depan) atau apa pun yang mungkin open source, Anda perlu untuk menguji semuanya. Dan Anda harus segera mulai karena nanti akan "terlalu sulit untuk mengisi ulang semua kode yang sudah ditulis"
xaxx

@xaxxon: Kent benar-benar berbicara tentang hal itu dalam jawaban yang sama dengan yang dikaitkan dengan Mansuro, dengan mengatakan: "Ketika menulis kode pada sebuah tim, saya memodifikasi strategi saya untuk dengan hati-hati menguji kode yang kita, secara kolektif, cenderung salah."
henko

Tidak, itu masih sangat singkat. Anda tidak dapat mengetahui siapa yang akan mengerjakan kode di masa mendatang. Ini adalah jenis pola pikir yang mempengaruhi pengembang junior.
xaxxon

5

Tes unit diterapkan untuk menghemat waktu dan meningkatkan:

  • pelacakan bug
  • refactoring dan / atau menulis ulang kode
  • tes integrasi
  • pengujian regresi, dll.

Merupakan keharusan untuk menulis unit test untuk bagian-bagian program yang relatif kompleks.

Jika Anda yakin bahwa tes unit penulisan sekarang tidak akan menghemat waktu Anda di masa mendatang, Anda dapat melewatkannya. Namun, Anda tidak pernah tahu, dan secara pribadi saya tidak bisa memikirkan kasus ketika lebih murah (dalam hal waktu, uang dan saraf) untuk tidak menulis unit test tetapi melakukan semua pengujian secara manual.


Umumnya jawaban yang bagus, jadi +1. Namun, saya pikir poin terakhir Anda melewatkan fakta bahwa Anda masih ingin / perlu menguji tes unit Anda secara manual!
vaughandroid

@ Baqueta, mungkin saya tidak terdengar jelas, tapi saya tidak bermaksud mengatakan bahwa unit test sepenuhnya menggantikan pengujian manual
superM

4

"Haruskah saya menguji unit ini" biasanya dapat dijawab dengan menjawab pertanyaan berikut: "Apakah penting bahwa fungsi ini berfungsi dengan baik, dan apakah penting bagi saya untuk mengetahui kapan itu berhenti bekerja?"

Tentu saja, ini jauh lebih rumit dari itu, tapi itu cara yang baik untuk memulai. Pada akhirnya, Anda juga akan mempertimbangkan apakah kode tersebut sudah diuji berdasarkan penggunaan pada fungsi lain, atau apakah waktu Anda akan lebih baik dihabiskan di fungsi lain, dll.


4

Kecuali Anda akan menulis kode tanpa mengujinya, Anda akan selalu dikenai biaya pengujian.

Perbedaan antara memiliki unit test dan tidak memilikinya adalah perbedaan antara biaya penulisan tes dan biaya menjalankannya dibandingkan dengan biaya pengujian dengan tangan.

Jika biaya penulisan tes unit adalah 2 menit dan biaya menjalankan tes unit praktis 0, tetapi biaya pengujian kode secara manual adalah 1 menit, maka Anda impas ketika Anda telah menjalankan tes dua kali.


Selama bertahun-tahun saya berada di bawah kesalahpahaman bahwa saya tidak punya cukup waktu untuk menulis unit test untuk kode saya. Ketika saya menulis tes, itu adalah hal yang menggembung, hal-hal berat yang hanya mendorong saya untuk berpikir bahwa saya seharusnya hanya menulis unit test ketika saya tahu mereka diperlukan.

Baru-baru ini saya didorong untuk menggunakan Test Driven Development dan saya menemukan itu sebagai wahyu yang lengkap. Saya sekarang sangat yakin bahwa saya tidak punya waktu untuk tidak menulis tes unit .

Dalam pengalaman saya, dengan mengembangkan dengan pengujian dalam pikiran Anda berakhir dengan antarmuka yang lebih bersih, kelas & modul yang lebih fokus dan umumnya lebih SOLID , kode diuji.

Setiap kali saya bekerja dengan kode lama yang tidak memiliki tes unit dan saya harus menguji sesuatu secara manual, saya terus berpikir "ini akan jauh lebih cepat jika kode ini sudah memiliki unit test". Setiap kali saya harus mencoba dan menambahkan fungsionalitas unit test ke kode dengan kopling tinggi, saya terus berpikir "ini akan jauh lebih mudah jika telah ditulis dengan cara de-coupled".


TL; versi DR :

Tulis tes ketika biaya menulis tes, ditambah biaya menjalankannya sebanyak yang Anda butuhkan cenderung lebih kecil dari biaya pengujian secara manual sebanyak yang Anda butuhkan.

Ingat juga bahwa jika Anda menggunakan TDD, biaya tes menulis cenderung turun saat Anda menjadi lebih baik, dan kecuali jika kode itu benar-benar sepele, Anda mungkin akan berakhir menjalankan tes Anda lebih sering daripada yang Anda harapkan.


3

Tes segera setelah Anda mengamati regresi terjadi atau takut menyebabkan beberapa dengan suntingan Anda dan tidak menyadarinya.

Menyalakan ketakutan itu, biarkan tumbuh ke ukuran yang memadai: semakin cepat Anda menguji, semakin baik.

Harap dicatat: tergantung pada peran Anda dalam proyek ini, tes unit mungkin bukan satu-satunya jenis tes yang ingin Anda tulis.

Semua orang seharusnya terobsesi dengan uji unit , karena praktik pengujian arus utama yang buruk di masa lalu; tetapi jika Anda tidak pernah menguji sebelumnya, Anda benar-benar harus fokus pada pengujian secara umum , pengujian unit saja tidak akan menyelesaikan masalah dunia.


1
Saya melihat Anda menunjuk tetapi bukankah unit menguji titik awal dasar untuk programmer pemula. Dan juga bisa Anda menguraikan lebih lanjut tentang apa yang Anda maksud dengan "pengujian secara umum". Terima kasih.
Lamin Sanneh

1
Setidaknya ada dua jenis pengujian lainnya - tes integrasi, dan tes penerimaan. Tes unit mencakup unit tertentu (misalnya fungsi kelas ini seharusnya Frab the Fizz). Anda mengejek / mematikan semua tempat lain di mana kelas itu berinteraksi, memberikannya data palsu. Saat Anda melakukan tes integrasi, Anda menggabungkan dua (atau lebih) kelas untuk memastikan bahwa kelas Anda berjalan bersama seperti yang Anda pikir seharusnya. Akhirnya Anda membangun cukup banyak tes yang Anda lakukan pengujian ujung ke ujung seluruh sistem Anda, kadang-kadang dikenal sebagai "tes asap".
Wayne Werner

Ada juga uji regresi yang disebut- sebut. Tes regresi biasanya lebih besar dari uji unit, mungkin membutuhkan waktu sehari untuk dibangun, dapat menyiratkan akses ke data uji dan lingkungan uji khusus. Sebenarnya unit test lebih kecil, lebih ramping, dan versi yang lebih mudah dipertahankan dari tes regresi (gaya lama).
ZJR

1

Saya percaya bahwa itu bukan ukuran proyek tetapi jenis proyek yang memutuskan apakah harus menggunakan pengujian atau tidak.

Jika Anda bekerja pada bukti konsep, atau pada proyek lain di mana tujuannya adalah belajar dari pengkodean, maka pengujian tidak diperlukan. Jika proyek itu dimaksudkan untuk digunakan, bahkan mungkin dikirim ke produksi, maka itu harus diuji.

Kutipan dari "Kode Bersih" Robert C. Martin : "Jika ini sepele untuk ditulis, itu sepele untuk diuji", jadi tidak ada alasan untuk melewatkan pengujian untuk program singkat dan sepele.


0

Ini sebenarnya bukan masalah ukuran - ini adalah apa yang Anda lakukan dengannya (dan berapa umurnya). Jika saya mencari-cari tentang cara kerja teknologi dan berencana membuang benda itu (kami menyebutnya lonjakan Scrum), saya hanya akan membuat kode tanpa melakukan banyak pengujian. Jika Anda berencana mengembangkannya lebih lanjut (bahkan jika Anda hanya mencari-cari), Anda harus menulis tes di sekitar kode. TDD adalah teknik desain bahkan sebelum itu adalah teknik pengujian. Anda ingin memiliki gambaran yang jelas tentang apa yang ingin Anda lakukan kode sebelum Anda terikat dalam rincian eksekusi. Saya juga TIDAKmerekomendasikan untuk mencoba menulis unit test yang luas di sekitar sejumlah besar kode warisan. Cobalah untuk mengidentifikasi bagian-bagian yang kompleks (memiliki rasa siklomatik / kode spageti yang tinggi bagi mereka) dan bagian-bagian yang sering gagal (mereka akan sering sama). Seperti yang disarankan orang lain, saya akan membaca buku Kent Beck di TDD dan pasti membaca buku Michael Feather. Yang tidak terlalu banyak dibahas adalah aspek politis dari penulisan unit test di sekitar kode. Banyak pengembang benci harus mengubah kode mereka agar dapat diuji, dan banyak pengembang tidak merasa perlu untuk menguji kode sama sekali. Itu adalah sesuatu yang harus kita kerjakan sebagai sebuah profesi. Setiap disiplin teknik lainnya diharuskan untuk membuktikan (seringkali secara matematis) bahwa pekerjaan mereka memenuhi spesifikasi. Kita harus melakukan hal yang sama.


-1

Mengikat Proyek dalam batasan kelas atau fungsionalitas dan kemudian menilai apakah ini cocok untuk pengujian unit mungkin salah. Ada banyak manfaat pengujian unit suatu aplikasi tetapi kecantikan yang sebenarnya dimulai ketika Anda harus memelihara aplikasi atau harus bekerja di lingkungan terdistribusi. Jadi pilihannya ada di sini. Bahkan perubahan kecil dalam kode Anda dapat menyebabkan bencana.
Saya tidak hanya akan menyarankan 'Pengujian Unit' tetapi juga akan merekomendasikan untuk memeriksa cakupan kode Anda, memastikan maksimum kode Anda dicakup dengan Uji Unit. Ambang batas untuk cakupan kode tidak boleh kurang dari 95% dan target harus sekitar 100% . Anda dapat mencari alat untuk melacak cakupan kode Anda dan menghasilkan laporan.
Visual Studio Menyediakan Data Cakupan -http://msdn.microsoft.com/en-us/library/ms182496(v=vs.80).aspx
Anda juga dapat menggunakan NCover atau dotCover.

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.