Apakah cakupan kode 100% mimpi pipa?


28

Apakah layak untuk mengharapkan cakupan kode 100% dalam aplikasi web jquery / backbonejs berat? Apakah masuk akal untuk gagal berlari karena cakupan 100% tidak terpenuhi ketika cakupan kode aktual berkisar sekitar 92% -95% di javascript / jquery?


7
“Fail a sprint” terdengar aneh tidak menyenangkan ...
Donal Fellows

5
Ini asimtot.
Robert Harvey

12
bahkan jika Anda memiliki cakupan penuh beberapa bug tidak akan ditemukan jadi jangan mengandalkan nomor itu untuk memperbaiki semuanya
ratchet freak

11
Apa pun mungkin. Pertanyaan sebenarnya adalah apakah nilai cakupan kode 100% sebanding dengan biaya dalam waktu dan sumber daya.
JohnFx

5
Mengapa Anda mengkhawatirkan hal ini, ketika asumsi yang mendasarinya - bahwa 100% (atau angka lainnya) cakupan pengujian otomatis secara ajaib akan membuat kode Anda lebih baik - adalah mimpi pipa itu sendiri?
Mason Wheeler

Jawaban:


30

Ini sama realistisnya dengan tidak realistis.

Realistis
Jika Anda memiliki pengujian otomatis yang telah terbukti mencakup seluruh basis kode, maka menuntut cakupan 100% masuk akal.
Itu juga tergantung pada seberapa kritis proyek itu. Semakin kritis, semakin masuk akal untuk mengharapkan / menuntut cakupan kode lengkap.
Lebih mudah melakukan ini untuk proyek berukuran kecil hingga menengah.

Tidak realistis
Anda mulai dari cakupan 0% ...
Proyek ini mengerikan dengan banyak, banyak jalur kesalahan yang sulit diciptakan atau dipicu.
Manajemen tidak mau berkomitmen / berinvestasi untuk memastikan cakupannya ada.

Saya telah mengerjakan keseluruhan proyek mulai dari tanpa cakupan hingga layak. Tidak pernah proyek dengan 100%, tetapi tentu saja saya berharap kami memiliki cakupan yang mendekati 100%.
Pada akhirnya pertanyaannya adalah apakah cakupan yang ada memenuhi cukup banyak kasus yang diperlukan agar tim merasa nyaman dalam pengiriman produk.

Kami tidak tahu dampak kegagalan pada proyek Anda, jadi kami tidak dapat mengatakan apakah 92% atau 95% sudah cukup, atau jika itu 100% benar-benar diperlukan. Atau dalam hal ini, 100% sepenuhnya menguji semua yang Anda harapkan.


30
... Dan hanya karena Anda memiliki cakupan kode 100% tidak berarti Anda memiliki cakupan cabang 100%, sehingga bahkan dengan cakupan kode 100% Anda bisa kehilangan banyak hal.
Bryan Oakley

3
+1 untuk ukuran proyek. Terurai menjadi komponen yang lebih kecil, dapat digunakan kembali, dan dapat diuji memungkinkan kami untuk mendapatkan cakupan ~ 95% sendiri. Cakupan 100% tidak perlu. Pengujian integrasi harus mencakup kesenjangan pengujian unit.
Apoorv Khurasia

5
@BryanOakley ... dan juga tes Anda bisa sia-sia, atau bahkan tidak menguji apa pun
David_001

5
@BryanOakley Dan bahkan dengan cakupan cabang 100%, mungkin saja kombinasi cabang tertentu dapat menyebabkan masalah. (dua pernyataan IF berurutan, misalnya, dapat bercabang ke dalam dan di sekitar dalam tes terpisah, tetapi melewatkan tes yang masuk keduanya . Cakupan cabang penuh, namun satu jalur eksekusi tidak terjawab)
Izkata

4
Bahkan cakupan cabang 100%, termasuk semua jalur eksekusi tidak cukup. Mungkin beberapa kesalahan hanya terjadi ketika Anda mengambil beberapa kombinasi cabang dan Anda memiliki beberapa input eksternal, misalnya tanggal yang salah. Tidak ada kemungkinan bahwa semua kasus akan pernah dibahas. Pada saat yang sama, seseorang dapat memiliki kepercayaan diri yang baik dengan cakupan kurang dari 100% tetapi sesuai kasus tepi yang dipilih sebagai input.
Andrea

32

Siapa yang menguji tes?

Ini sangat naif dalam hal terbaik dan tidak realistis bahkan dalam pengertian teoretis dan tidak praktis dalam pengertian bisnis.

  • Itu tidak realistis dengan kode yang memiliki kompleksitas siklomatik yang tinggi. Ada terlalu banyak variabel untuk mencakup setiap kombinasi.
  • Itu tidak realistis dengan kode yang sangat bersamaan. Kode tidak deterministik sehingga Anda tidak dapat mencakup setiap kondisi yang mungkin terjadi karena perilaku akan berubah pada setiap uji coba.
  • Ini tidak realistis dalam arti bisnis, hanya membayar dividen untuk menulis tes untuk kode yang merupakan kode jalur kritis, yaitu kode yang penting dan kode yang dapat sering berubah.

Menguji setiap baris kode bukanlah tujuan yang baik

Sangat mahal untuk menulis tes, itu adalah kode yang harus ditulis dan diuji sendiri, itu adalah kode yang harus didokumentasikan dalam apa yang sebenarnya mencoba untuk menguji, itu adalah kode yang harus dipertahankan dengan perubahan logika bisnis dan tes gagal karena mereka kedaluwarsa. Mempertahankan tes otomatis dan dokumentasi tentang mereka bisa lebih mahal daripada mempertahankan kode kadang-kadang.

Ini bukan untuk mengatakan bahwa tes unit dan tes integrasi tidak berguna, tetapi hanya jika mereka masuk akal, dan di luar industri yang dapat membunuh orang, tidak masuk akal untuk mencoba dan menguji setiap baris kode dalam basis kode. Di luar banyak orang yang dengan cepat membunuh basis kode ini, tidak mungkin untuk menghitung laba atas investasi yang akan tercakup dalam cakupan kode 100%.

Menghentikan masalah:

Dalam teori komputabilitas, masalah penghentian adalah masalah penentuan, dari uraian program komputer yang sewenang-wenang dan input, apakah program akan selesai berjalan atau terus berjalan selamanya.

Alan Turing membuktikan pada tahun 1936 bahwa algoritma umum untuk memecahkan masalah penghentian untuk semua pasangan input-program yang mungkin tidak ada. Bagian penting dari buktinya adalah definisi matematis dari komputer dan program, yang kemudian dikenal sebagai mesin Turing; masalah penghentian tidak dapat ditentukan pada mesin Turing. Ini adalah salah satu contoh pertama masalah keputusan.

Karena Anda bahkan tidak dapat membuktikan sesuatu bekerja 100% mengapa menjadikannya tujuan Anda?

Sederhana dan sederhana, dalam banyak kasus tidak masuk akal secara bisnis.


7
ini benar-benar harus menjadi jawaban yang diterima. Cakupan kode 100% hampir seburuk 0%.
Ryathal

1
"Ada terlalu banyak variabel untuk mencakup setiap kombinasi." Ini tidak ada hubungannya dengan mendapatkan cakupan kode 100%. Jika satu baris kode cukup penting untuk ditulis, dan cukup penting untuk dipertahankan, maka cukup penting untuk dicakup oleh suatu pengujian. Jika tidak dicakup oleh tes, satu-satunya asumsi yang aman adalah itu tidak berfungsi. Memang benar bahwa untuk beberapa kode tidak masuk akal dari perspektif bisnis untuk mengujinya. Itu adalah kode yang sama yang tidak masuk akal dari perspektif bisnis untuk ditulis.
still_dreaming_1

2
jadi Anda berpikir menulis kasus uji untuk mencakup getXXX()/setXXX()konstruktor tugas sederhana untuk objek nilai adalah penggunaan waktu dan sumber daya yang baik, maaf itu tidak terjadi pada kenyataannya dan pendapat yang sangat naif yang tidak memiliki pengalaman dunia nyata untuk mendukungnya. Ingat kode tes masih kode yang harus dipertahankan. Semakin sedikit kode yang Anda tulis untuk menyelesaikan masalah, semakin baik dalam setiap kasus .

Uhm "Itu tidak realistis dengan kode yang memiliki kompleksitas siklomatik yang tinggi. Ada terlalu banyak variabel untuk mencakup setiap kombinasi." - tentu saja, itu sebabnya Anda harus memecah kode tersebut menjadi potongan-potongan kecil yang memiliki kompleksitas siklomatik kecil dan karenanya lebih mudah untuk diuji. Refactoring dengan cara itu penting untuk pengujian - itu membuat pengujian lebih mudah.
Predrag Stojadinović

17

Dalam kebanyakan kasus, cakupan kode 100% berarti Anda telah "sedikit curang":

  • Bagian sistem yang kompleks dan sering berubah (seperti gui) telah dipindahkan ke templat deklaratif atau DSL lainnya.
  • Semua kode yang menyentuh sistem eksternal telah diisolasi atau ditangani oleh perpustakaan.
  • Hal yang sama berlaku untuk ketergantungan lainnya, terutama yang membutuhkan efek samping.

Pada dasarnya, bagian-bagian yang sulit untuk diuji telah dihambat ke daerah-daerah di mana mereka tidak selalu dihitung sebagai "kode". Ini tidak selalu realistis, tetapi perhatikan bahwa terlepas dari membantu Anda menguji, semua praktik ini membuat basis kode Anda lebih mudah untuk dikerjakan.


Bagaimana cara memindahkan barang ke kecurangan DSL?
back2dos

2
@ back2dos - Meskipun Anda dapat menguji unit, skrip python tersemat Anda, Anda mungkin tidak sedang menguji templat html Anda, atau CSS Anda, atau menghitung garis di dalamnya ke arah perkiraan cakupan.
Dan Monego

12

Untuk contoh dunia nyata yang mengesankan dari cakupan cabang 100% , lihat Bagaimana SQLite Diuji .

Saya menyadari pertanyaan Anda secara khusus bertanya tentang javascript yang merupakan jenis produk perangkat lunak yang sama sekali berbeda, tetapi saya ingin membawa kesadaran akan apa yang dapat dilakukan dengan motivasi yang memadai.


9

Cakupan kode 100% untuk pengujian unit untuk semua bagian dari aplikasi tertentu adalah mimpi pipa, bahkan dengan proyek-proyek baru. Saya berharap memang begitu, tetapi kadang-kadang Anda hanya tidak dapat menutupi sepotong kode, tidak peduli seberapa keras Anda mencoba untuk menghilangkan ketergantungan eksternal. Misalnya, katakanlah kode Anda harus memohon layanan web. Anda dapat menyembunyikan panggilan layanan web di belakang antarmuka sehingga Anda dapat mengejek bagian itu, dan menguji logika bisnis sebelum dan sesudah layanan web. Tetapi bagian aktual yang perlu meminta layanan web tidak dapat diuji unit (sangat baik pula). Contoh lain adalah jika Anda perlu terhubung ke server TCP. Anda dapat menyembunyikan kode yang menghubungkan ke server TCP di belakang antarmuka. Tetapi kode yang secara fisik terhubung ke server TCP tidak dapat diuji unit, karena jika turun karena alasan apa pun maka itu akan menyebabkan unit test gagal. Dan unit test harus selalu lulus, tidak peduli kapan mereka dipanggil.

Aturan praktis yang baik adalah semua logika bisnis Anda harus memiliki cakupan kode 100%. Tetapi potongan-potongan yang harus memanggil komponen eksternal, itu harus memiliki cakupan kode mendekati 100% mungkin. Jika Anda tidak dapat mencapai maka saya tidak akan terlalu banyak berkeringat.

Jauh lebih penting, apakah tesnya benar? Apakah mereka mencerminkan bisnis Anda secara akurat dan persyaratannya? Memiliki cakupan kode hanya untuk memiliki jangkauan kode tidak berarti apa-apa jika semua yang Anda lakukan adalah pengujian yang salah, atau pengujian kode yang salah. Yang sedang berkata, jika tes Anda baik, maka memiliki cakupan 92-95% luar biasa.


1
Menguji apa yang terjadi ketika Anda mendapatkan kombinasi aneh dari kasus kesalahan dan kegagalan untuk merespons bisa sangat rumit.
Donal Fellows

Tidak memahami apa yang akan dilakukan sistem Anda ketika dihadapkan dengan masalah rumit ini sebagai bagian dari daya tarik pengujian unit? Juga, ada sedikit kebingungan di sini antara tes unit dan tes integrasi.
Peter Smith

unit testingdengan konfigurasi ini integration testing, kode pengujian yang tidak Anda tulis adalah integrationpengujian. Tumpukan TCP dalam OS Anda tidak harus menguji itu, Anda harus menganggap itu sudah diuji oleh siapa yang pernah menulisnya.

4

Saya akan mengatakan kecuali kode tersebut dirancang dengan tujuan khusus yang memungkinkan cakupan pengujian 100%, 100% mungkin tidak dapat dicapai. Salah satu alasannya adalah bahwa jika Anda membuat kode secara defensif - yang seharusnya - Anda harus memiliki kode yang terkadang menangani situasi yang Anda yakini tidak boleh terjadi atau tidak dapat terjadi mengingat pengetahuan Anda tentang sistem. Untuk menutupi kode tersebut dengan tes akan sangat sulit menurut definisi. Tidak memiliki kode seperti itu mungkin berbahaya - bagaimana jika Anda salah dan situasi ini terjadi sekali saja dari 256? Bagaimana jika ada perubahan di tempat yang tidak terkait yang membuat hal yang mustahil menjadi mungkin? Dll. Jadi 100% mungkin agak sulit dijangkau dengan cara "alami" - misalnya, jika Anda memiliki kode yang mengalokasikan memori dan Anda memiliki kode yang memeriksa jika gagal, kecuali jika Anda mengejek manajer memori (yang mungkin tidak mudah) dan tulis tes yang mengembalikan "kehabisan memori", yang mencakup kode itu mungkin sulit. Untuk aplikasi JS, mungkin itu adalah kode defensif di sekitar kemungkinan kebiasaan DOM di browser yang berbeda, kemungkinan kegagalan layanan eksternal, dll.

Jadi saya akan mengatakan seseorang harus berusaha untuk mendekati 100% mungkin dan memiliki alasan yang baik untuk delta, tapi saya tidak akan melihat tidak mendapatkan 100% sebagai kegagalan. 95% bisa baik-baik saja pada proyek besar, tergantung pada apa 5% itu.


Hanya karena kode tidak seharusnya dijalankan dalam produksi dalam keadaan normal tidak berarti kode tidak dapat ditulis sedemikian rupa untuk dijalankan oleh pengujian. Seberapa kritiskah kode yang tidak biasa itu untuk berjalan dengan benar? Apakah cukup penting untuk menutupinya dengan tes? Saya berpendapat bahwa jika tidak cukup penting untuk dibahas dengan tes, tidak cukup penting untuk menangani kasus itu. Kode yang tidak perlu tes adalah kode yang tidak perlu ada, dan harus dihapus.
still_dreaming_1

2

Jika Anda memulai dengan proyek baru, dan Anda benar-benar menggunakan metodologi uji-pertama, maka sepenuhnya masuk akal untuk memiliki cakupan kode 100% dalam arti bahwa semua kode Anda akan dipanggil pada titik tertentu ketika tes Anda memiliki telah dieksekusi. Namun Anda mungkin tidak menguji secara eksplisit setiap metode atau algoritme individual secara langsung karena visibilitas metode, dan dalam beberapa kasus Anda mungkin tidak menguji beberapa metode bahkan secara tidak langsung.

Mendapatkan 100% dari kode Anda yang diuji berpotensi merupakan latihan yang mahal, terutama jika Anda belum merancang sistem Anda untuk memungkinkan Anda mencapai tujuan ini, dan jika Anda memfokuskan upaya desain Anda pada testability, Anda mungkin tidak memberikan perhatian yang cukup. untuk merancang aplikasi Anda untuk memenuhi persyaratan spesifik itu, terutama di mana proyek itu besar. Maaf, tetapi Anda tidak bisa mendapatkan keduanya tanpa ada kompromi.

Jika Anda memperkenalkan tes ke proyek yang ada di mana pengujian belum dipelihara atau dimasukkan sebelumnya, maka mustahil untuk mendapatkan cakupan kode 100% tanpa biaya latihan melebihi upaya. Yang terbaik yang dapat Anda harapkan adalah memberikan cakupan pengujian untuk bagian-bagian penting dari kode yang paling sering disebut.

Apakah masuk akal untuk gagal berlari karena cakupan 100% tidak terpenuhi ketika cakupan kode aktual berkisar sekitar 92% -95% di javascript / jquery?

Dalam kebanyakan kasus, saya akan mengatakan bahwa Anda hanya harus menganggap sprint Anda 'gagal' jika Anda belum memenuhi tujuan Anda. Sebenarnya, saya lebih suka untuk tidak menganggap sprint gagal dalam kasus-kasus seperti itu karena Anda harus dapat belajar dari sprint yang tidak memenuhi harapan untuk mendapatkan perencanaan Anda yang benar saat Anda menentukan sprint. Apapun, saya tidak berpikir itu masuk akal untuk mempertimbangkan cakupan kode menjadi faktor dalam keberhasilan relatif sprint. Tujuan Anda harus melakukan cukup hanya untuk membuat semuanya berfungsi seperti yang ditentukan, dan jika Anda meng-coding-test terlebih dahulu, maka Anda harus dapat merasa yakin bahwa tes Anda akan mendukung tujuan ini. Setiap pengujian tambahan yang Anda rasa perlu Anda tambahkan secara efektif adalah pelapis gula dan dengan demikian merupakan biaya tambahan yang dapat menahan Anda dalam menyelesaikan sprint Anda dengan memuaskan.


"Maaf, tapi kamu tidak bisa mendapatkan keduanya tanpa ada sesuatu yang dikompromikan." Itu tidak benar. Anda selalu dapat mengurangi fitur, atau lebih lambat. Jika ada sesuatu yang tidak layak untuk diuji, itu tidak layak ditulis. Jika satu baris kode cukup penting untuk disimpan, cukup penting untuk diuji. Jika tidak cukup penting untuk diuji, itu tidak cukup penting untuk dipertahankan. Satu-satunya asumsi aman dari satu baris kode yang tidak diuji adalah bahwa itu tidak berfungsi.
still_dreaming_1

@ still_dreaming_1, Anda tampaknya telah mendukung pernyataan saya dan bertentangan dengan diri Anda sendiri. Menambah fitur atau mengubah tenggat waktu Anda adalah kompromi, yang masing-masing dapat memengaruhi biaya proyek dan harapan pemangku kepentingan. Menguji kode lawas yang belum pernah diuji sepenuhnya sangat sulit, karena Anda harus memahami bukan hanya kode saat dijalankan, tetapi niat pembuat asli, dan menulis tes yang menangkap perilaku kode warisan yang ada tidak selalu menunjukkan bahwa kode berfungsi sepenuhnya sebagaimana mestinya.
S.Robins

Saya kira maksud saya adalah bahwa sesuatu yang dikompromikan, fitur atau perubahan yang belum dibuat karena pengembangan bergerak lebih cepat, bukan kompromi nyata karena jika Anda kehilangan cakupan untuk bergerak lebih cepat, fitur dan perubahan tersebut dapat hanya diasumsikan tidak berfungsi dengan baik. Jadi apa gunanya membuat perubahan itu atau menambahkan fitur-fitur itu jika tidak masalah apakah itu berfungsi dengan benar atau tidak? Jika tidak masalah apakah itu berfungsi atau tidak, perubahan itu tidak perlu dilakukan, dan sekarang harus ditarik keluar dari kode.
still_dreaming_1

Saya tidak sepenuhnya percaya itu lagi, atau setidaknya saya menyadari aspek kepraktisan dari kebenaran yang Anda bicarakan, terutama dalam basis kode warisan, jadi itu hanya penjelasan tentang poin yang saya coba sampaikan pada saat itu. Sebenarnya, saya sekarang benar-benar bertentangan tentang melakukan TDD sepanjang waktu pada basis kode baru, apalagi mendapatkan cakupan 100%. Di satu sisi, setiap bentuk logika dan nalar memberi tahu saya bahwa kedua hal itu harus baik, namun dalam praktiknya saya tidak bisa membuatnya praktis. Jadi ada yang sangat salah dengan dunia pemrograman, kita perlu paradigma baru.
still_dreaming_1

1

Tentu saja saya tidak melakukan ini, tetapi saya telah melakukannya pada dua proyek besar. Jika Anda punya kerangka kerja untuk pengaturan unit test, itu tidak sulit sebenarnya, tetapi itu menambah banyak tes.

Apakah ada beberapa kendala khusus yang Anda temui yang mencegah Anda mengenai beberapa kalimat terakhir? Jika tidak, jika mendapatkan cakupan dari 95% hingga 100% mudah, maka Anda sebaiknya melakukannya. Karena Anda di sini bertanya, saya akan berasumsi bahwa ada adalah sesuatu. Apa itu sesuatu?


Ini adalah salah satu jawaban terbaik di sini. Menanyakan apa yang mencegah agar baris kode tidak mudah terjangkau adalah pertanyaan yang bagus. Mendapatkan garis-garis tersebut akan memaksa Anda untuk meningkatkan kode untuk mewujudkannya, sehingga itu akan menjadi kemenangan, menang.
still_dreaming_1

0

92% baik-baik saja. Saya merasa bahwa pertanyaan sebenarnya adalah:

  • Apakah 92% norma 'baru' sekarang? Jika sprint berikutnya memiliki pengujian 88%, apakah itu akan baik-baik saja? Ini seringkali merupakan awal dari test suites yang ditinggalkan.

  • Seberapa penting perangkat lunak itu berfungsi dan tidak memiliki bug. Anda memiliki tes karena alasan ini, bukan "demi pengujian"

  • Apakah ada rencana untuk kembali dan mengisi tes yang hilang?

  • Mengapa Anda menguji? Sepertinya fokusnya adalah% garis yang dicakup bukan fungsionalitas


"Seberapa pentingkah perangkat lunak itu bekerja dan tidak memiliki bug"? Pertanyaan bagus. Apa definisi bug? Sesuatu yang tidak berfungsi sebagaimana dimaksud. Jika ok untuk beberapa kode tidak berfungsi dengan benar maka jangan menulisnya. Inti dari kode adalah agar bisa berfungsi.
still_dreaming_1

0

Martin Fowler menulis di blognya :I would be suspicious of anything like 100% - it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing.

Namun, bahkan ada standar yang mewajibkan cakupan 100% di tingkat unit. Sebagai contoh, ini adalah salah satu persyaratan dalam standar komunitas spaceflight Eropa (ECSS, Kerjasama Eropa untuk Standardisasi Ruang). Makalah yang ditautkan di sini , menceritakan kisah menarik tentang proyek yang memiliki tujuan mencapai cakupan pengujian 100% dalam perangkat lunak yang sudah selesai. Ini didasarkan pada nterview dengan insinyur yang terlibat yang mengembangkan tes unit.

Beberapa pelajaran adalah:

  • Cakupan 100% tidak biasa tetapi dapat dicapai
  • Cakupan 100% kadang-kadang diperlukan
  • Cakupan 100% membawa risiko baru
  • Jangan optimalkan untuk 100% -metrik
  • Kembangkan strategi yang tepat untuk memaksimalkan cakupan
  • Cakupan 100% bukan kondisi yang memadai untuk kualitas yang baik

0

Mungkin bertanya apakah layak dan masuk akal bukan pertanyaan yang paling membantu untuk diajukan. Mungkin jawaban yang paling praktis adalah jawaban yang diterima. Saya akan menganalisis ini pada tingkat yang lebih filosofis.

Cakupan 100% akan ideal, tetapi idealnya tidak diperlukan, atau akan jauh lebih mudah untuk dicapai. Saya lebih suka memikirkan apakah itu alami dan manusia daripada layak atau masuk akal.

Tindakan pemrograman dengan benar hampir tidak mungkin dilakukan dengan alat saat ini. Sangat sulit untuk menulis kode yang sepenuhnya benar, dan tidak memiliki bug. Itu tidak alami. Jadi, tanpa opsi lain yang jelas, kami beralih ke teknik seperti TDD, dan melacak cakupan kode. Tetapi selama hasil akhirnya masih merupakan proses yang tidak wajar, Anda akan kesulitan membuat orang melakukannya secara konsisten dan bahagia.

Mencapai cakupan kode 100% adalah tindakan yang tidak wajar. Bagi kebanyakan orang, memaksa mereka untuk mencapainya akan menjadi bentuk siksaan.

Kita membutuhkan proses, alat, bahasa, dan kode yang memetakan ke model mental alami kita. Jika kami gagal melakukan ini, tidak ada cara untuk menguji kualitas menjadi suatu produk.

Lihat saja semua perangkat lunak di luar sana hari ini. Sebagian besar mengacaukan cukup teratur. Kami tidak ingin percaya ini. Kami ingin percaya bahwa teknologi kami ajaib dan membuat kami bahagia. Jadi kami memilih untuk mengabaikan, memaafkan, dan melupakan sebagian besar waktu teknologi kami berantakan. Tetapi jika kita mengambil penilaian yang jujur ​​tentang hal-hal, sebagian besar perangkat lunak di luar sana hari ini cukup jelek.

Berikut adalah beberapa upaya untuk menjadikan pengkodean lebih alami:

https://github.com/jcoplien/trygve

https://github.com/still-dreaming-1/TujuanPhp

Kemudian sangat tidak lengkap dan eksperimental. Sebenarnya ini adalah proyek yang saya mulai, tetapi saya percaya itu akan menjadi langkah besar ke depan untuk keahlian pemrograman jika saya bisa mendapatkan waktu untuk menyelesaikannya. Pada dasarnya adalah gagasan bahwa jika kontrak mengungkapkan satu-satunya aspek perilaku kelas yang kita pedulikan, dan kita sudah menyatakan kontrak sebagai kode, mengapa tidak hanya memiliki definisi kelas dan metode bersama dengan kontrak. Dengan cara itu kontrak akan menjadi kode, dan kita tidak perlu menerapkan semua metode. Biarkan perpustakaan mengetahui cara menghormati kontrak untuk kita.


-2

Mencapai 100% pada kode baru harus sangat dapat dicapai dan jika Anda berlatih TDD Anda mungkin akan mencapai itu secara default karena Anda sangat sengaja menulis tes untuk setiap baris kode produksi.

Pada kode lawas yang ada yang ditulis tanpa tes unit bisa sulit karena sering kode warisan tidak ditulis dengan pengujian unit dalam pikiran dan dapat memerlukan banyak refactoring. Level refactoring itu seringkali tidak praktis mengingat kenyataan risiko dan jadwal sehingga Anda melakukan trade off.

Di tim saya, saya menentukan cakupan kode 100% dan jika kita melihat kurang dari itu dalam ulasan kode pemilik teknis komponen membahas mengapa 100% tidak tercapai dengan pengembang dan harus setuju dengan alasan pengembang. Seringkali jika ada masalah mengenai 100% pengembang akan berbicara dengan pemilik teknis sebelum peninjauan kode. Kami telah menemukan bahwa begitu Anda membiasakan diri dan mempelajari teknik-teknik untuk mengatasi beberapa masalah umum dengan menambahkan tes ke kode lawas yang memukul 100% secara teratur tidak sesulit yang Anda bayangkan.

Buku Michael Feather " Bekerja Efektif dengan Kode Legacy " telah sangat berharga bagi kami untuk membuat strategi untuk menambahkan tes ke kode legacy kami.


-3

Tidak, itu tidak mungkin dan itu tidak akan pernah terjadi. Jika memungkinkan, semua matematika akan jatuh ke dalam finitisme. Sebagai contoh, bagaimana Anda menguji suatu fungsi yang mengambil dua bilangan bulat 64 bit dan mengalikannya? Ini selalu menjadi masalah saya dengan pengujian versus membuktikan program yang benar. Untuk apa pun kecuali program yang paling sepele, pengujian pada dasarnya tidak berguna karena hanya mencakup sejumlah kecil kasus. Ini seperti memeriksa 1.000 angka dan mengatakan Anda telah membuktikan dugaan Goldbach.


Oh! Jadi seseorang kesal karena saya tidak menjawab masalah di pesawat konsepsinya; pengujian itu sia-sia ... saya tidak peduli apakah itu populer. Itu tidak akan pernah berhasil. Itu tidak bisa. Ilmuwan komputer terpintar telah mengetahui hal ini (Dijkstra, Knuth, Hoare et al.). Saya kira jika Anda seorang programmer JavaScript yang tidak mengerti pemrograman eXtreme maka Anda tidak peduli dengan engkol itu. Blah, apa pun, siapa yang peduli ... tulis kode jelek. Buang CO ^ 2 menjalankan tes Anda. - Maksudku, siapa yang punya waktu untuk duduk dan berpikir lagi? Kami telah mengekspornya ke komputer.
veryfoolish

3
Pertanyaannya ditandai "TDD". TDD lebih merupakan alat desain dan alat eksplorasi masalah daripada pengujian, dan masing-masing "tes" hanyalah contoh bagaimana kode akan berperilaku dalam beberapa konteks, sehingga orang dapat membaca dan memahami apa yang terjadi, kemudian mengubahnya dengan aman . TDD yang dilakukan dengan baik cenderung mengarah pada kode yang lebih bersih, lebih mudah digunakan, dan menjalankan tes hanya memeriksa bahwa dokumentasinya terkini. Sebagian besar suite TDD hampir tidak pernah menangkap bug; bukan untuk apa mereka di sana. Saya pikir Anda sedang downvoted karena jawaban Anda mengkhianati kurangnya pemahaman, dan saya harap komentar ini membantu.
Lunivore
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.