Sebagai pengembang profesional, apakah boleh untuk tidak menulis unit test? [Tutup]

9

Hanya bertanya-tanya tentang pro dan kontra pada pengujian unit TDD / otomatis dan mencari pandangan masyarakat tentang apakah pengembang profesional dapat menulis aplikasi tanpa mendukung pengujian unit?

testing unit-testing

— David Osborne
sumber

7

Sudahkah Anda mencoba, atau Anda mencari alasan untuk tidak melakukannya?

3

Maka jawabannya adalah "itu tergantung pada apa yang mereka ingin Anda lakukan".

3

@Florents "harus" - yah, tidak, tidak harus. Untuk contoh balasan lihat bagaimana JWZ mengeluarkan browser Netscape pada tahun 1994. jwz.org/blog/2009/09/that-duct-tape-silliness . Mereka tidak punya waktu untuk itu, dan unit test umumnya tidak membuahkan hasil sampai Anda mencapai mode pemeliharaan.

4

Terlepas dari apakah itu dapat diterima atau tidak , pengalaman profesional saya adalah bahwa itu diterima .

— Carson63000

4

Saya harap saya profesional (20+ tahun pengalaman). Saya tidak menulis unit test untuk sebagian besar kode saya (selain pustaka runtime sepele). Saya menulis kontrak dan tes integrasi sebagai gantinya. Dan saya tidak menggunakan OOD / OOP dalam bentuk apa pun, tentu saja.

— SK-logic

21

Untuk menguji apa?

Jika Anda berbicara tentang cakupan kode 100%, itu sangat jarang, tidak berguna dan seringkali tidak mungkin. Dengan cara yang sama, menguji kode terkait CRUD adalah buang-buang waktu, dan akan sangat tidak profesional menghabiskan waktu berjam-jam menulis kode yang tidak Anda perlukan daripada melakukan sesuatu yang benar-benar berguna.

Sekarang, sebagai pengembang, Anda harus tahu cara menulis unit test, dan di mana Anda membutuhkannya.

— Arseni Mourzenko
sumber

5

Teori

Ada kesalahpahaman umum bahwa pengujian unit adalah untuk menguji "unit" .
Tes unit, juga semua tes lainnya, menguji fungsionalitas . Tidak ada yang bisa diuji.

Namun, fungsi dari sistem yang kompleks seringkali tidak dapat diuji secara efektif.
Katakanlah, pengguna menekan tombol "Hapus", dan tidak ada yang terjadi. Mengapa? Kesalahan mungkin ada dalam database, koneksi mungkin terputus, logika inti mungkin tidak berfungsi, atau bahkan operasi mungkin berhasil tetapi antarmuka tidak memperbarui dengan benar. Setiap layer dapat berisi banyak fungsi yang memanggil satu sama lain, dan tidak selalu jelas di mana kesalahannya.
Tes unit didasarkan pada paradigma pemisahan komponen dan mengujinya secara individual.

Sekali lagi, ini tidak menjamin keseluruhan sistem akan bekerja, tetapi menyederhanakan pengujian.

TDD bukan persyaratan dengan sendirinya. Ini menyederhanakan pengkodean dengan memaksa pengembang untuk menjawab terlebih dahulu, "apa yang sebenarnya akan saya kode?".

Biaya

Banyak yang berpikir bahwa dengan tidak menulis tes, mereka menghemat waktu mereka. Salah. Berpikir secara strategis, biaya kesalahan meningkat secara eksponensial dengan waktu sejak penampilan hingga deteksi.

Katakanlah Anda membuat kesalahan dalam kode Anda dan mendeteksi dan memperbaikinya pada hari yang sama. Biaya adalah $ X .
Anggap saja kesalahan tetap tidak terdeteksi dan masuk ke internal build mingguan. Untungnya, QA telah mendeteksinya, menaikkan bug di bug tracker, masalahnya adalah subjek diskusi 5 menit pada pertemuan 5 orang, dll. Akhirnya, Anda memperbaikinya. Biaya adalah jumlah tenaga kerja yang dihabiskan oleh semua orang, dan mungkin $ 3 * X dalam hal ini.
Bagaimana jika kesalahannya menuju pengujian beta dan melibatkan lebih banyak orang? Mari mengatakan, $ 10 * X .
Jika tetap tidak terdeteksi untuk waktu yang lama, pergi ke 1.000 pelanggan (mudah-mudahan, bukan ke satu juta!), 10 dari mereka mendeteksi itu, mereka mengangkat diskusi dengan staf pendukung Anda, beberapa mungkin memanggil bos Anda, rekan tim Anda berusaha mereproduksi itu , dll, dll. Akhirnya, bug kembali kepada Anda, dan Anda memperbaikinya. Berapa totalnya? Nah lebih dari $ 50 * X .

Seperti yang Anda lihat, sebuah bug cepat atau lambat akan kembali kepada Anda (atau kolega Anda). Satu-satunya perbedaan adalah ketika itu terjadi dan berapa biayanya.
Tes unit memperpendek siklus hidup bug dan karenanya mengurangi biaya.

Pro

Tes unit memungkinkan pengembang untuk kode lebih baik . Sesimpel itu.
Mereka membiarkan menghemat waktu Anda;
Mereka mengurangi biaya;
Tes unit hidup bersama dengan kode yang mereka uji. Atas permintaan perubahan apa pun (yang terjadi sepanjang waktu), tes akan beradaptasi.

Con

Saya bisa melihat satu alasan untuk tidak menulis tes. Jika Anda menulis prototipe, mis. Sesuatu yang tidak akan pernah jatuh ke orang lain. Atau mungkin Anda sedang menulis sesuatu untuk sekali penggunaan.

— bytebuster
sumber

1

TDD adalah untuk mendapatkan API yang benar.

Anda mengatakan yang berikut seolah-olah itu kontradiksi, tetapi tidak:

There's a common misconception that unit tests are for testing "units". Unit tests, likewise all other tests, test functionality.

Pengujian unit tentu saja dimaksudkan untuk menguji unit ; dari situlah nama itu berasal.

— Andres F.

1

@AndresF. IMHO, unit harus dianggap sebagai cara mengatur kode, tetapi bukan subjek pengujian. Demikian juga "minum secangkir kopi" berarti minum kopi yang diatur dalam cangkir, bukan minum secangkir. :)

— bytebuster

3

Tentu, dapat diterima untuk tidak menulis unit test untuk utilitas pembantu internal kecil, atau alat pengujian, atau skenario di mana bisnis benar- benar membutuhkan hal-hal selain kualitas dan Anda sebagai pengembang profesional menemukan bahwa Anda dapat menyelesaikan perangkat lunak dan bekerja dengan cepat tanpa.

— Telastyn
sumber

3

Dalam pengalaman saya, 95% kesalahan yang bisa ditangkap oleh unit test berasal dari panggilan ke lapisan data, terutama setelah perubahan desain database. Jika Anda menggunakan database, cukup uji setiap metode yang Anda gunakan untuk mengaksesnya. Tes bahkan tidak perlu rumit, hanya pemeriksaan kewarasan.

Sebagai jawaban atas pertanyaan Anda - jika Anda mengakses database, dan Anda adalah pengembang profesional, Anda harus menggunakan tes unit. Kalau tidak, itu tergantung.

— Paul
sumber

Jika Anda menguji akses ke lapisan data, itu bukan tes unit! Tes unit sering membuat Anda alasan tentang kesalahan logika , seperti penanganan kondisi batas yang tidak tepat. Bukan kesalahan data!

— Andres F.

2

Itu sangat tergantung pada bagaimana aplikasi akan digunakan. Apakah ini aplikasi kritis misi? Atau itu aplikasi verifikasi sederhana yang hanya digunakan secara internal oleh pengembang? Ketika mengerjakan aplikasi inti untuk perusahaan Anda harus ada sebanyak unit test yang diperlukan untuk memastikan keputusan bisnis tercakup. Bergantung pada perusahaan Anda, itu adalah aplikasi yang dilihat pelanggan dan bug dapat menghabiskan biaya. Ketika dilakukan dengan baik, unit test dapat sangat membantu untuk memastikan aplikasi Anda akan berfungsi saat digunakan. Tapi itu bukan obat semua dan pengujian manusia masih harus dilakukan. Aplikasi internal (atau tambahan) yang sederhana tidak perlu pengujian unit, tetapi harus tetap ditulis dengan baik.

TDD bukan hanya tentang tes menulis terlebih dahulu. Ini tentang memastikan kode Anda mudah diuji. Dan lebih sering daripada tidak mudahnya kode yang diuji juga lebih mudah dibaca / debug / perawatan. Lebih sering daripada tidak mudah kode diuji juga mengikuti pola dan prinsip OO seperti SOLID. Saya berpendapat sebagai pengembang profesional kode Anda harus selalu ditulis seperti itu.

— bwalk2895
sumber

1

Anda pasti tidak ingin "tidak ada pengujian". Jika Anda menulis tes unit, Anda setidaknya memiliki beberapa jaminan bahwa kode Anda cocok dengan tes Anda (meskipun Anda harus memastikan bahwa tes Anda sesuai dengan spesifikasi Anda).

Anda belum selesai jika semua yang Anda miliki adalah unit test. Anda mungkin masih perlu melakukan tes integrasi dan tes end-to-end (dan seiring waktu mengumpulkan kasus uji untuk menangkap regresi bug).

— Vatine
sumber

1

Pengujian unit bukan satu-satunya cara untuk memastikan kepatuhan terhadap spesifikasi. Bahkan bukan yang paling ketat.

— K.Steff

2

@ K.Steff Anda sepenuhnya benar. Saya harap sulit untuk membaca jawaban saya karena "semua yang Anda butuhkan adalah pengujian unit".

— Vatine

1

Saya akan mengambil risiko di sini dan mengatakan itu sebagian besar subjektif dan tergantung pada tujuan Anda. tl; dnr: Ini baik untuk dilakukan, tetapi bersikap dogmatis hanya akan menimbulkan lebih banyak masalah.

Tes TDD / Unit akan meningkatkan stabilitas kode Anda. Mereka membuatnya lebih mudah untuk membuat perubahan tanpa mengetahui basis kode dengan sangat baik, mereka membiarkan Anda refactor lebih cepat, mereka membiarkan Anda yakin bahwa Anda tidak melakukan sesuatu yang konyol. Tes unit juga bisa membuang-buang waktu. Waktu yang bisa dihabiskan menulis kode. Hal ini juga dapat membuat Anda membodohi diri Anda dengan berpikir bahwa kode Anda berfungsi jika tidak jika Anda mengikuti secara membabi buta.

Jika Anda bekerja untuk perusahaan yang mendukung praktik terbaik dan memberi Anda waktu untuk mengimplementasikannya dan Anda menginginkan aplikasi yang tahan lama, maka sangat baik bagi semua orang untuk menggunakan dan mempraktikkan tes unit dan ulasan kode. Memiliki tim QA dapat menjadi pengganti yang dapat diterima jika pengembang tidak menyalahgunakannya. Jika Anda menulis prototipe (bahkan yang produksi) mungkin lebih cepat hanya melakukan tes asap.

Jika Anda mengerjakan sesuatu di mana kekacauan tidak akan menjadi akhir dunia, cakupan yang lebih sedikit mungkin baik-baik saja. Transaksi keuangan? Banyak. Jika Anda memiliki tim pengembang yang kuat yang mengetahui basis kode, bekerja sama dengan baik dan tidak ada pergantian, maka Anda mungkin perlu cakupan yang lebih sedikit. Dll

Jadi itu mungkin beberapa fungsi

Ukuran / omset tim
Kehidupan rak yang diinginkan dari aplikasi
Aplikasi dan bagaimana kegagalan kritis
Waktu yang disediakan untuk menerapkan praktik terbaik relatif terhadap jadwal pengembangan
Kecerdasan tim (ini tidak berarti menjadi programmer yang baik berarti Anda tidak boleh menulis tes unit, tetapi tim tanpa pengembang junior mungkin bisa terbang dengan kursi celana dengan lebih sukses)

Ada banyak situasi di mana tidak menulis tes unit dapat diterima. TDD 'dalam' saat ini, tapi itu bukan peluru perak.

— spinning_plate
sumber

0

Profesional untuk Menulis Tes Unit yang Dapat Dipertahankan Yang Akan Menghemat Waktu Dan Air Mata Anda!

Ada a misconception that Unit test finds bugs. Yah, itu TIDAK benar untuk semua kasus. Pengujian unit bukan tentang menemukan bug atau mendeteksi regresi. Secara definisi examine each unit of your code separately,. Tetapi ketika aplikasi Anda berjalan nyata, semua unit tersebut harus bekerja bersama, dan keseluruhannya lebih kompleks dan halus daripada jumlah bagian yang diuji secara independen.

Dengan demikian, tujuan pengujian Unit (dalam proses TDD) adalah tentang merancang komponen perangkat lunak dengan kuat.

Sunting: Ada satu pengecualian di mana unit test benar - benar mendeteksi bug. Saat Anda melakukan refactoring, atau merestrukturisasi kode unit tetapi tanpa bermaksud mengubah perilakunya. Dalam hal ini, tes unit sering dapat memberi tahu Anda jika perilaku unit telah berubah.

— Yusubov
sumber

0

Sebagai pengembang profesional, apakah boleh untuk tidak menulis unit test?

Tidak.

Tanpa pertanyaan - Ini harus menjadi salah satu pelajaran pertama yang dipelajari lebih segar. Anda harus mengembangkan unit test untuk membuktikan bahwa kode Anda berfungsi sebelum Anda memberi tahu QA bahwa kode Anda siap untuk diuji. Kegagalan untuk melakukannya akan menambah biaya proyek dan menurunkan semangat tim.

Seberapa menyeluruh tes unit ini seharusnya?

Ini adalah tes lakmus: Jika QA menemukan bug dalam kode Anda, apakah Anda akan merasa nyaman menggunakan unit test Anda untuk membuktikan uji tuntas Anda kepada bos Anda?

Jika jawaban Anda adalah 'Tidak', maka Anda harus membuat tes unit (atau tes) yang lebih baik.
Jika jawaban Anda adalah 'Ya', maka kode Anda siap untuk verifikasi.

Sebagai pengembang profesional, apakah boleh untuk tidak menulis tes unit otomatis ?

Iya.

Terutama jika waktu dan usaha yang dihabiskan untuk menulis tes unit otomatis akan lebih besar daripada manfaat yang diperoleh oleh tes. Ini termasuk, tetapi tidak terbatas pada, kode UI yang dapat sulit untuk diejek.

Penekanan: Saya tidak mengatakan bahwa tidak mungkin untuk menulis tes unit otomatis untuk kode UI. Saya hanya mengatakan bahwa, dalam pengalaman saya, kadang-kadang sulit untuk menulis tes unit otomatis untuk beberapa kode UI.

— Jim G.
sumber