Jika pengujian unit sangat bagus, mengapa tidak lebih banyak perusahaan yang melakukannya? [Tutup]

Perusahaan perangkat lunak nyata pertama tempat saya bekerja adalah tentang pengujian unit (NUnit). Saya tidak tahu bahwa kami benar-benar kaku untuk itu - Saya tidak tahu seperti apa cakupan kode kami dan saya menulis sebagian besar tes unit. Sejak itu saya telah bertemu dengan beberapa perusahaan yang melakukan banyak pengujian, tetapi ini adalah pengujian kursi: bergantung pada seseorang yang ada di sana, memiliki repeatibilitas yang rendah, dan kemungkinan rendah untuk menangkap bug. Sikap lainnya adalah: itu adalah sesuatu yang mereka ingin lakukan "di masa depan"; pada dasarnya ketika uang jatuh dari langit.

Saya rindu pengujian unit - itu hanya membuat hidup lebih mudah. Tapi saya menemukan bahwa ketika saya mencari pekerjaan baru, pengujian unit adalah sesuatu yang perusahaan ingin "lakukan" di masa depan atau sesuatu yang tidak mereka lakukan sama sekali (uhh, sudah ada untuk sementara waktu sekarang!). Saya akan mengatakan bahwa 60-75% dari persyaratan pekerjaan yang saya lihat selama 2 tahun terakhir belum mencantumkan pengujian unit sama sekali. Saya hanya dapat memikirkan satu atau dua yang memiliki pengalaman pengujian unit sebagai persyaratan (untuk posisi pengembang tingkat menengah).

Jadi pertanyaannya adalah, apa yang kurang ? Saya pikir itu membuat orang lebih produktif, tetapi itu hanya setelah menghabiskan banyak waktu untuk benar-benar melakukannya. Apakah tidak ada studi yang bagus tentang penghematan biaya pengujian unit? Apakah ini jenis perusahaan yang saya lihat?

Sunting: meskipun judulnya agak pendukung setan, saya menganggap diri saya pendukung pengujian unit.

Menurut pengalaman saya, ada beberapa faktor yang terlibat di dalamnya:

1. Manajemen tidak benar-benar memahami apa sebenarnya pengujian unit itu, atau mengapa pengujian tersebut memiliki nilai intrinsik yang nyata bagi mereka.
2. Manajemen cenderung lebih peduli dengan pengiriman produk yang cepat, dan (secara tidak benar) melihat pengujian unit sebagai kontraproduktif dengan tujuan tersebut.
3. Ada kesalahpahaman bahwa pengujian hanya dimiliki oleh pervue dari QA. Pengembang adalah pembuat kode, dan tidak dapat menulis pengujian.
4. Ada kesalahpahaman umum bahwa manajemen harus mengeluarkan uang untuk melakukan pengujian unit dengan benar, meskipun alat tersedia secara gratis. (Tentu saja, pengembang meningkatkan waktu untuk mempertimbangkan, tetapi itu tidak terlalu menghalangi.)
5. Jawaban Will akan melengkapi jawaban ini: Sangat sulit untuk menentukan nilai kode tes (edit jcollum)

Secara alami, ada faktor-faktor lain, tetapi itu hanya yang saya hadapi sejauh ini.

1) Sulit
2) Butuh waktu
3) Sangat sulit untuk menentukan nilai kode uji

Poin 3 adalah yang lengket. Tes unit yang baik mengurangi bug. Tetapi begitu juga kode produksi yang baik. Bagaimana Anda menentukan berapa banyak bug yang tidak ada karena pengujian unit Anda? Anda tidak dapat mengukur apa yang tidak ada. Anda dapat menunjuk ke studi, tetapi tidak cocok dengan spreadsheet manajer bisnis Anda.

Sangat mudah untuk menyalahkan "manajemen". Tetapi apakah manajemen benar - benar memberi tahu Anda untuk secara khusus tidak melakukan pengujian unit?

Manajemen secara umum tidak (dan mungkin seharusnya tidak) memberi tahu Anda cara melakukan pekerjaan Anda, apakah itu modularisasi, tipe data abstrak, pola desain, atau pengujian unit. Ini adalah alat perdagangan yang diterapkan oleh insinyur perangkat lunak yang berhasil dan kompeten, tetapi insinyur yang buruk tidak.

Saya pikir jawaban sebenarnya untuk pertanyaan Anda adalah: pengujian unit sangat sulit, dan siswa ilmu komputer tidak terlatih untuk itu.

Sangat mudah saat Anda menulis kelas string Anda sendiri. Saat Anda menguji produk kehidupan nyata, Anda mengalami tantangan yang tidak ada yang memberi tahu Anda tentang slide powerpoint:

• Interaksi pengguna. Separuh dari aplikasi Anda adalah logika antarmuka pengguna. Bagaimana Anda mengujinya secara otomatis, yang tidak rusak jika Anda memindahkan tombol?
• Interaksi dengan API dan kerangka kerja eksternal. Jika Anda menulis driver kernel Windows, bagaimana Anda mengujinya? Apakah Anda menulis rintisan untuk setiap IRP dan fungsi kernel yang Anda gunakan, secara efektif membuat simulasi kernel OS?
• Komunikasi jaringan adalah hal di abad ke-21. Bagaimana Anda mengoordinasikan pengujian unit yang terdiri dari beberapa komponen terdistribusi?
• Bagaimana Anda memilih kasus uji yang baik? Saya biasanya melihat orang mencoba pendekatan "lakukan hal-hal acak dalam satu putaran 1000 iterasi dan lihat apakah itu rusak". Ketika Anda melakukan ini, upaya lebih tinggi daripada hasil, bug penting terlewat, dan pengujian unit ditinggalkan.
• Bagaimana Anda menguji apakah persyaratan kinerja terpenuhi?
• Pengetahuan tentang pola dalam pengujian sangat langka: rintisan, tanggapan kalengan, pengujian regresi adalah konsep yang tidak diketahui kebanyakan orang. Berapa banyak orang di tempat kerja Anda yang benar-benar membaca buku tentang pengujian unit?

Satu hal yang dapat kita salahkan manajemen adalah bahwa spesifikasi persyaratan jarang memuat persyaratan apa pun tentang tingkat kualitas pengiriman.

Lain kali atasan Anda meminta Anda untuk melakukan perkiraan waktu, sertakan waktu untuk menulis tes unit dan lihat apa yang terjadi.

Kebanyakan tes tidak menguji apapun.
Anda menulis fungsi fileopen () dan unittest yang gagal jika file tidak ada dan berhasil jika file memang ada. Bagus! Sekarang apakah Anda memeriksa apakah itu berfungsi dengan nama file dalam bahasa Cina BIG5? pada saham NFS? di vista dengan file pada kunci USB dan UAC AKTIF?

Masalahnya adalah pengujian unit ditulis oleh programmer yang sama yang menulis fungsinya, dengan kumpulan asumsi yang sama dan dengan tingkat keahlian yang sama. Agar benar-benar berfungsi, pengujian harus ditulis oleh orang lain, hanya untuk spesifikasi yang dipublikasikan tanpa mereka melihat kodenya. - Di kebanyakan perusahaan, hanya mendapatkan spesifikasi tertulis akan menjadi terobosan!

Tes unit memeriksa kesalahan dalam kode fungsi individu. Mereka dapat bekerja untuk lapisan akses data, pustaka matematika, dll. Di mana input / output terkenal dan struktur internalnya kompleks tetapi untuk banyak kasus, mereka hanya membuang-buang waktu.
Mereka gagal ketika kesalahan terjadi karena interaksi antara bagian kode yang berbeda atau dengan OS dan pengguna. Masalah seperti pengaturan DPI tinggi / rendah yang mengacaukan kotak dialog atau pengaturan bahasa asing yang menukar '.' dan ',' biasanya tidak ditemukan.

Ada penelitian yang dilakukan pada ROI pengujian unit - lihat pertanyaan ini .

Saya telah menemukan banyak pengembang yang tidak tertarik dengan pengujian unit. Itu selalu tampak seperti banyak pekerjaan dengan sedikit hasil ketika Anda mulai. Tidak ada yang mau mendaftar untuk pekerjaan tambahan sehingga mereka menolak. Begitu orang mulai, mereka biasanya dengan antusias mematuhinya, tetapi memulainya bisa jadi sulit.

Selain masalah adopsi pengujian unit, pengujian unit tidak selalu bermanfaat, meskipun secara umum saya pikir begitu, jika diterapkan dengan benar. Tidak ada yang istimewa tentang pengujian unit yang menyelamatkan mereka dari kerentanan terhadap konstruksi yang buruk.

Pengujian unit memiliki biaya (pembuatan, pemeliharaan, dan pengoperasian) dan hanya bermanfaat jika memberikan manfaat yang lebih besar daripada biaya tersebut. Pembuatan tes adalah keterampilan seperti yang lain, ini membutuhkan pengalaman dan pengetahuan khusus untuk sukses. Tanpa pengalaman yang memadai, sangat mudah bahkan bagi pengembang berpengalaman untuk membuat pengujian unit berkualitas rendah, bernilai rendah, dan / atau berbiaya tinggi yang tidak berguna. Terutama mengingat betapa sulitnya menilai nilai tes unit.

Selain itu, pengujian unit hanyalah salah satu cara untuk meningkatkan kualitas kode, tetapi ini bukan satu-satunya cara. Dalam beberapa keadaan dan dengan beberapa tim, ini mungkin bukan cara yang paling efektif untuk meningkatkan kualitas perangkat lunak.

Perlu diingat bahwa melakukan banyak upaya dalam pengujian unit bukanlah jaminan perangkat lunak berkualitas. Dan, juga, dimungkinkan untuk menghasilkan perangkat lunak dengan kualitas tertinggi tanpa pengujian unit apa pun.

Nah, perusahaan saya belum menggunakan TDD atau Unit Testing. Sejujurnya, kami tidak yakin bagaimana melakukannya. Kami jelas dapat melakukannya untuk fungsi bodoh seperti CapitalizeString (), dll, tetapi kami tidak tahu bagaimana melakukannya untuk sistem yang sangat kompleks dengan objek yang rumit. Selain itu, sebagian besar orang yang diwawancarai tidak memiliki pengalaman, atau pengalaman terbatas. Tampaknya Pengujian Unit besar dari kerumunan SO, tetapi tidak terlalu besar di ruang kerja yang tersedia.

TDD adalah topik terpisah. Kami secara moral menentang TDD. Kami bukan pembuat kode koboi, tetapi kami percaya bahwa hal itu menghambat kreativitas dan fleksibilitas dalam sebuah proyek. Selain itu, memiliki pembuat kode yang menulis fungsi pengujian unit tidak masuk akal. Ketika saya melakukan sesuatu, saya membuat kode ke semua kasus tepi yang dapat saya pikirkan. Yang saya butuhkan adalah otak lain untuk mencari hal-hal yang mungkin saya lewatkan. Kami tidak punya itu. Timnya kecil dan mandiri.

Singkatnya, kami tidak percaya pada TDD, tapi kami ingin Uji Unit. Kami hanya tidak memiliki pengalaman untuk melakukannya, dan kami tidak dapat menemukannya dengan mudah.

Ada banyak perusahaan di luar sana yang benar-benar tidak melakukan apa pun sesuai dengan praktik terbaik. Tidak ada ulasan kode, tidak ada pengujian unit, tidak ada rencana pengujian, tidak ada apa-apa, hanya dengan tempat duduk celana mereka.

Ambil ini sebagai kesempatan untuk membuat mereka menggunakan platform Integrasi Berkelanjutan dan mengembangkan pengujian unit! Cara mudah untuk mengesankan kekuatan yang ada dan meningkatkan kualitas dan stabilitas kode Anda pada saat yang bersamaan

Sunting: Untuk alasannya, saya pikir mereka sekadar tidak mengetahui alat saat ini di luar sana yang membuat pengujian CI dan unit luar biasa mudah.

Dari apa yang saya lihat, banyak perusahaan memiliki basis kode yang sangat besar dan sangat digabungkan yang secara praktis tidak dapat diuji unit. Mereka juga tidak memiliki persyaratan pengujian yang layak, jadi pengujian unit akan menguji persyaratan de facto "as built".

Saya tidak berpikir kemalasan adalah akar penyebab pengujian unit yang buruk. Untuk perusahaan saya, batasan waktu dan sikap "selesaikan saja" adalah penghalang terbesar untuk melakukan pengujian unit. Selain itu, tempat-tempat di mana sistem kami gagal cenderung lebih pada tingkat integrasi (layanan, akses database, kueri kompleks yang membutuhkan data khusus untuk pengujian), bukan "tingkat unit". Hal-hal ini hanya lebih sulit untuk diuji, dan jika Anda hampir tidak memiliki cukup waktu untuk menyelesaikan fitur tersebut, Anda mungkin tidak akan punya waktu untuk menyelesaikan tes yang berguna pada saat yang bersamaan.

Pengujian unit seharusnya menjadi bagian alami dari alur kerja pengembangan kode, seperti halnya compilernya.

Namun, hal ini memerlukan pendidikan manajemen tentang manfaat pengujian unit. Pengembang junior memiliki peluang yang relatif rendah untuk memiliki pengaruh seperti itu. Jadi, apakah perusahaan adalah pendukung pengujian unit tergantung pada apakah mereka memiliki pengembang senior atau arsitek yang mendukung pengujian unit.

Saya yakin ini adalah jawaban atas pertanyaan Anda "apa yang hilang dan mengapa tidak lebih banyak perusahaan yang melakukan pengujian unit" . :-)

Ini mungkin kombinasi dari beberapa hal yang sudah Anda sebutkan. Sulit untuk mengukur penghematan biaya TDD. Jika Anda ingin melakukan outsourcing TI, Anda dapat menunjukkan berapa banyak yang Anda bayarkan per tahun untuk staf yang Anda miliki vs. biaya untuk mengontrakkannya; itu sangat konkret. Bagaimana Anda mengatakan, "Oh, pengujian ini menemukan bug yang membutuhkan waktu 4 jam untuk men-debug dan memperbaikinya ..."?

Alasan beberapa tempat tidak menggunakannya adalah karena dibutuhkan banyak pekerjaan untuk memulai dan melanjutkan. Fakta bahwa menulis unit test membutuhkan waktu sebanyak menulis fungsionalitas yang sebenarnya tampaknya bagi beberapa manajer seperti Anda memotong setengah produktivitas pengembang Anda.

Selain itu, Anda membangun tim (atau seseorang) perlu menempatkan infrastruktur dan memeliharanya.

Dan seperti yang dikatakan Alan , banyak tempat tidak menggunakan praktik terbaik - mereka hanya ingin melihat sesuatu yang nyata.

Saya pikir programmer harus mulai melakukannya. Beberapa pengujian sederhana untuk memulai mudah dibenarkan sebagai bagian dari pengembangan.

Sesuatu seperti pengujian unit hampir selalu diperlukan untuk mendapatkan proses debugging yang cepat. Cukup jelaskan seberapa cepat meluncurkan pengujian daripada mengatur input yang benar, menyetel breakpoint debugger, meluncurkan aplikasi, dll.

Dokumentasikan pengujian dalam kode Anda. Beri komentar yang menjelaskan di mana tes itu dan bagaimana menjalankannya. Pemrogram masa depan akan melihatnya dan mudah-mudahan pengujian akan menyebar!

Pengujian unit adalah salah satu istilah kotak hitam yang telah didengar kebanyakan orang, tetapi tidak tahu apa sebenarnya yang dimaksud dengan pengujian unit, di mana untuk memulai, bagaimana menulisnya, bagaimana cara menjalankan pengujian, apa sebenarnya yang harus mereka uji, dll. dll.

Dalam banyak kasus, lebih mudah bagi pengembang yang tidak yakin untuk mengabaikannya sebagai hal yang tidak perlu atau hanya diperlukan oleh "pengembang tingkat perusahaan".

Saya adalah penggemar berat pengujian unit dan saya juga merupakan mitra di sebuah perusahaan yang melakukan proyek pengembangan kontrak untuk berbagai jenis klien. Dalam sebulan kami akan menyentuh 3-4 proyek berbeda dengan ukuran berbeda.

Jika sebuah proyek tampaknya akan menjadi proyek yang gagal, saya tidak akan banyak berinvestasi dalam pengujian unit karena pengujian unit tersebut tidak membuahkan hasil untuk bisnis saya. Pada jenis proyek tersebut, saya akan menguji unit hal-hal yang saya tidak yakin / tidak terbiasa atau yang dapat sering berubah (seperti parser untuk sumber data yang tidak saya kendalikan.)

Sedangkan jika saya membangun sesuatu yang saya tahu akan berumur panjang, merupakan pekerjaan yang lebih besar, yang akan saya kerjakan melalui beberapa iterasi, atau akan berdampak besar pada klien saya jika terjadi kesalahan , Saya akan berinvestasi dalam lebih banyak pengujian unit. Sekali lagi, prioritas pengujian berkisar pada kode yang tidak pasti / asing / berubah.

Saya pikir pengujian unit harus berkisar pada kompleksitas tugas, serta apakah mereka akan membuahkan hasil. Tidak ada gunanya menulis kode tambahan yang tidak akan digunakan.

Menurut pengalaman saya, ini sangat tergantung pada perangkat lunak yang Anda tulis. Saya merasa sangat sulit untuk menulis pengujian unit untuk UI. Saya hanya menggunakan unit test untuk bagian-bagian dari sistem yang memiliki in / out tertentu.

Saya rindu pengujian unit - itu hanya membuat hidup lebih mudah.

Itu tidak alasan yang cukup bagi perusahaan untuk mengadopsi pengujian unit.

Alasan yang memadai mungkin "lebih murah" (dan / atau, "lebih baik"): yang tidak mudah dibuktikan tentang pengujian unit.

Satu-satunya alasan bagus mungkin "menulis unit test adalah penggunaan terbaik waktu pengembang", yang sangat sulit untuk membuktikan IMO: dan mungkin benar di beberapa tempat, untuk beberapa perangkat lunak, dengan beberapa pengembang, dan tidak benar di tempat lain.

Ada banyak pengembang yang tidak memikirkan dunia pengujian unit: termasuk beberapa yang berpikir bahwa bentuk pengujian lain (misalnya integrasi otomatis / pengujian fungsional) mungkin lebih murah dan lebih berharga, misalnya Apakah saya satu-satunya pengembang yang tidak? tidak suka tes unit?

Tentu saja, dalam dunia yang ideal, Anda tidak dapat membantah adanya unit test.

Namun, apakah Anda menulis pengujian unit bergantung pada beberapa hal:

• Bagaimana perangkat lunak akan digunakan. Jika Anda menulis perangkat lunak hanya untuk diri Anda sendiri, apakah Anda akan menulis pengujian unit? Mungkin tidak. Jika Anda menulis perangkat lunak yang dikemas sebelumnya untuk dijual secara komersial, mungkin ya.

• Berapa banyak orang yang memelihara kode .... jika itu hanya Anda, maka Anda mungkin mengetahuinya dengan cukup baik untuk cukup percaya diri setelah membuat perubahan bahwa menjalankan kode dengan cepat sudah cukup untuk memastikan tidak ada yang rusak. Jika orang lain yang awalnya tidak menulis kode sekarang harus memeliharanya, maka unit test akan membantu memberi mereka keyakinan bahwa ketika mereka memperbarui kode untuk memperbaiki yang besar (yang jelas tidak tertangkap dalam pengujian unit!) Mereka tidak merusak apa pun .

• kompleksitas kode: hanya kode uji yang perlu diuji. Metode penetapan variabel satu baris tidak memerlukan pengujian. Sebuah metode 50 baris dengan beberapa jalur eksekusi mungkin bisa melakukannya.

• Pertimbangan komersial komersial praktis: Faktanya adalah menulis tes unit membutuhkan waktu lebih lama daripada tidak melakukannya. Jika Anda menulis perangkat lunak prototipe, yang memiliki masa depan komersial yang tidak pasti, maka ada hasil yang harus diperoleh antara memiliki kode dengan cepat, sekarang, yang berfungsi cukup baik versus memiliki kode unit yang diuji dalam 2 minggu yang berfungsi lebih baik. Kadang-kadang membayar untuk mengetahui dengan cepat (selera konsumen) jika perangkat lunak akan memiliki rak pendek seperti dan pindah ke proyek berikutnya.

dan seperti yang ditunjukkan orang lain, ujian hanya akan sebaik orang yang menulisnya.

Alasan utamanya adalah banyak pengembang dan manajer pengembangan tidak memiliki petunjuk bahwa pengujian unit ada, atau bagaimana menggunakannya.

Alasan kedua adalah pengujian unit hanya dapat digunakan (dengan cara yang masuk akal) dengan kode yang telah memenuhi beberapa standar kualitas. Kemungkinannya, beberapa basis kode yang ada tidak termasuk dalam kategori itu.

Alasan ketiga adalah kemalasan dan / atau kemurahan hati.

Karena pengujian unit hanya berguna jika Anda menulis kode yang dapat diuji. Dan menulis kode yang dapat diuji itu sulit. Dan orang-orang malas dan / atau pelit.

EDIT: bernuansa "malas" sebagai "malas dan / atau murah"; Kadang-kadang, orang benar-benar memiliki keterampilan dan kapasitas dan kemauan untuk menulis tes, tetapi mereka memiliki hal lain untuk dilakukan yang secara lebih langsung memengaruhi hasil akhir.

Menurut saya, sebagian dari masalahnya adalah pengembang mengharapkan para pebisnis memiliki kumpulan nilai yang sama dan benar-benar peduli dengan jawaban "haruskah kita menguji unit atau tidak?". Kami tidak mendapatkan persetujuan sebelumnya dari bisnis untuk menggunakan bahasa tingkat tinggi daripada bahasa assembly - ini biasanya cara yang masuk akal untuk menyelesaikan pekerjaan.

Intinya adalah, kita adalah satu-satunya yang memenuhi syarat untuk melakukan panggilan (bukan berarti kita semua memiliki pengetahuan yang sama tentang topik tersebut). Lebih jauh lagi, bahkan jika tim Anda tidak, sebagai masalah kebijakan, melakukan pengujian unit (atau sebutkan-metode-Anda-of-the-day) umumnya tidak berarti Anda tidak dapat melakukannya.

Sebenarnya, kami tidak dapat benar-benar membuktikan ROI pada sebagian besar hal yang kami lakukan dengan perincian yang terlalu bagus. Mengapa pengujian unit diadakan untuk standar pembuktian yang tidak masuk akal / tidak khas ini di luar kemampuan saya ...

Orang malas dan hanya mengadopsi perubahan ketika dipaksa.

2 sen saya:

• Dibutuhkan pendidikan dan disiplin, tetapi lulusan baru sudah memiliki pengetahuan yang tepat.
• Overhead tes dapat dikurangi dengan alat yang lebih baik dan ini juga terjadi (refactoring dll.)

Jadi, ini hanya soal waktu.

Ada debat Martin-Coplien di mana Bob Martin menegaskan bahwa:

"saat ini, tidak bertanggung jawab bagi pengembang untuk mengirimkan baris kode yang belum dieksekusi dalam pengujian unit."

[ http://www.infoq.com/interviews/coplien-martin-tdd]

Jika Anda ingin menjual semua orang dalam pengujian, lakukan hal berikut:

1. Tulis banyak tes.
2. Beri tahu pengembang lain yang mengubah kode dan gagal dalam ujian Anda.
3. Mereka akan memperbaiki kode mereka.
4. Sekarang Anda dapat merilis tanpa bug khusus tersebut.

Bahkan seorang manajer pun dapat memahami ini.

Perusahaan tidak melakukan pengujian unit, karena alasan yang sama bahwa banyak situs web ditulis dengan buruk - ketidaktahuan, dan orang-orang berpegang teguh pada kebiasaan lama. Di perusahaan saya, sejak kami memulai pengujian unit (dengan Nunit, dan Typemock ), kami mencapai cakupan kode yang lebih tinggi dan merilis perangkat lunak dalam waktu yang lebih singkat ke pasar.

Seperti kebanyakan ide bagus, adopsi lebih berkaitan dengan ketergantungan jalur organisasi daripada dengan kualitas ide.

Di sebagian besar perusahaan yang telah mengirimkan produk, divisi QA yang substansial telah dibuat dengan kepala QA tingkat senior. Pengujian adalah wilayah kekuasaan tim QA.

Tim QA tidak mungkin menulis kode pengujian unit karena perusahaan biasanya tidak mempekerjakan tim QA dengan pembuat kode tugas beratnya.

Tim pemrograman enggan untuk menulis kode pengujian karena dapat menimbulkan konflik dengan tim QA.

Saya telah melihat lebih banyak minat dan adopsi Pengujian Unit dalam kelompok di mana QA belum dipisahkan menjadi fungsi pekerjaan yang terpisah

Sederhana saja, memerlukan biaya untuk menulis dan memperbarui pengujian unit. Sebagian besar perusahaan perangkat lunak sebelumnya tidak memiliki pengujian unit dan membutuhkan biaya terlalu banyak untuk menulis. Jadi mereka tidak melakukannya dan itu menambah waktu untuk proses pengembangan sehingga mereka juga tidak menambahkannya ke fitur baru.

Kebanyakan perusahaan tidak berguna. Bukan salah satu tempat Anda (atau saya) bekerja, jelas.