Mengapa pengembangan yang digerakkan oleh tes hilang dari Joel's Test?


23

Saya membaca blog ini oleh Joel Spolsky tentang 12 langkah menuju kode yang lebih baik . Tidak adanya Pengembangan Berbasis Tes sangat mengejutkan saya. Jadi saya ingin mengajukan pertanyaan kepada para Guru. Apakah TDD tidak sepadan dengan usaha?


13
Artikel itu ditulis Rabu, 9 Agustus 2000 (sekitar 12 tahun yang lalu). Bukan berarti TDD tidak ada pada saat itu tetapi saya tidak percaya itu menikmati hampir buzz yang dilakukannya hari ini.
Mike

12
Tes Joel hanyalah seperangkat pedoman umum. Tidak semua yang "sepadan dengan usaha" bisa cocok di sana.
yannis

2
Saya telah membuat tes ceroboh saya sendiri yang sangat tidak bertanggung jawab untuk menilai kualitas tim perangkat lunak. Bagian terbaik dari itu adalah bahwa dibutuhkan sekitar 3 menit ... Yang rapi tentang The Joel Test adalah mudah untuk mendapatkan jawaban ya atau tidak untuk setiap pertanyaan. Anda tidak perlu mencari tahu baris-kode-kode-per-hari atau rata-rata-bug-per-infleksi-titik ... ' - memutuskan apakah proyek Anda akan mendapatkan keuntungan dari TDD akan memakan waktu lebih dari 3 menit dan, yah , mungkin memerlukan perhitungan rata-rata-bug-per-infleksi-titik - itu sebabnya itu tidak ada dalam daftar
nyamuk

Pindah ke Joel Stack plz. Ini q yang menarik.
Erik Reppen

Anda harus mempertimbangkan untuk menerima jawaban yang menghubungkan dan mengutip langsung dari Joel, karena jawaban itu tidak lebih otoritatif daripada itu. Lihat programmers.stackexchange.com/a/189493/6586
Bryan Oakley

Jawaban:


30

Perkembangan yang didorong oleh tes hampir tidak dikenal sebelum buku Kent Beck keluar pada tahun 2002, dua tahun setelah Joel menulis posting itu. Pertanyaannya kemudian menjadi mengapa Joel belum memperbarui tesnya, atau jika TDD lebih dikenal pada tahun 2000 akankah ia memasukkannya ke dalam kriteria?

Saya percaya dia tidak akan memiliki, karena alasan sederhana bahwa yang penting adalah Anda memiliki proses yang terdefinisi dengan baik, bukan detail spesifik dari proses itu. Itu alasan yang sama ia merekomendasikan kontrol versi tanpa menentukan sistem kontrol versi tertentu, atau merekomendasikan memiliki database bug tanpa merekomendasikan merek tertentu. Tim yang baik terus meningkatkan dan beradaptasi, dan menggunakan alat dan proses yang cocok untuk situasi khusus mereka pada waktu tertentu. Untuk beberapa tim, itu pasti berarti TDD. Untuk tim lain, tidak banyak. Jika Anda mengadopsi TDD, pastikan itu bukan dari mentalitas kultus kargo .


1
Juga ... oh Anda agak memukul TDD adalah titik Kool Aid bukan?
Erik Reppen


27

Joel sebenarnya telah membahas hal ini secara khusus di beberapa tempat.

Dia menjelaskan bahwa tes hal-hal tidak mampu menangkap banyak masalah penting, terutama yang subjektif seperti "apakah antarmuka pengguna perangkat lunak ini payah?" Menurutnya, ketergantungan yang berlebihan pada tes otomatis di Microsoft adalah bagaimana kami berakhir dengan Windows Vista.

Dia menulis bagaimana, dalam pengalamannya, jenis bug yang ditemukan pengguna cenderung terbagi dalam dua kategori: 1) bug yang muncul dalam penggunaan umum, yang akan ditemukan oleh para programmer jika mereka menjalankan kode mereka sendiri sebelum menggunakannya. , atau 2) tepi case sangat tidak jelas sehingga tidak ada yang akan berpikir untuk menulis tes untuk menutupi mereka di tempat pertama. Dia menyatakan bahwa hanya sebagian kecil dari bug yang dia dan timnya perbaiki di FogBugz adalah hal-hal yang akan ditangkap oleh unit test. (Saya tidak dapat menemukan artikel itu sekarang, tetapi jika ada yang tahu yang saya maksud, jangan ragu untuk mengedit tautan di sini.)

Dan dia menulis bagaimana ini bisa lebih merepotkan daripada nilainya, terutama ketika proyek Anda tumbuh menjadi proyek yang sangat besar dengan banyak tes unit, dan kemudian Anda mengubah sesuatu (secara sengaja) dan berakhir dengan sejumlah besar tes unit yang rusak. Dia secara khusus menggunakan masalah-masalah yang dapat ditimbulkan oleh pengujian unit sebagai alasan mengapa dia tidak menambahkannya sebagai poin ke-13 pada Tes Joel, bahkan ketika orang-orang menyarankan bahwa dia harus melakukannya.


2
Sebenarnya kamu benar. MO Joel yang biasa adalah pria jerami. Seperti TDD tidak akan menangkap bug untuk saya, jadi itu tidak baik. Yang agak merindukan titik bahwa TDD bukan tentang pengujian, ini tentang desain. Tes yang ditinggalkan adalah bonus. Atau berargumentasi bahwa perubahan kecil akan merusak banyak unit test, yang menunjukkan bahwa dia melakukan kesalahan. Atau untuk sepenuhnya menulis ulang prinsip SOLID sebelum menyerang itu. Hal semacam itu. Sebenarnya pendukungnya yang menggunakan logika sirkular, bukan dia.
pdr

7
Saya sepenuhnya setuju dengan komentar Joel ini. Saya pikir masalah yang lebih besar adalah bahasanya - dengan banyak bahasa dinamis saya tidak bisa membayangkan melakukan apa pun tanpa tes unit - bagaimana lagi Anda bisa tahu jika kesalahan ketik sederhana akan menyebabkan beberapa masalah yang tidak akan Anda lihat sampai kritis saat? Dalam bahasa yang diketik secara statis, dikompilasi yang dirancang untuk mengurangi kesalahan, Anda dituntun menjauh dari semua kesalahan yang paling sederhana dan kebanyakan dibiarkan dengan kesalahan logika. Ini mengurangi kebutuhan untuk jenis cakupan penuh yang disediakan oleh TDD.
Bill K

2
@MasonWheeler: Anda serius berargumen bahwa keamanan compiler- / type-menghilangkan kebutuhan pengujian unit? Anda juga dengan sengaja mengabaikan manfaat desain dari TDD tetapi, yang lebih penting, Anda pasti memiliki waktu yang sulit untuk melakukan refactoring apa pun. Sebaliknya, yang sebaliknya telah dianggap benar: mis. Pengembang NET yang mengikuti metodologi TDD tiba-tiba merasa frustrasi dengan jumlah kode yang mereka perlu tulis untuk menyenangkan seorang kompiler yang semakin tidak membantu sebagai imbalannya.
pdr

2
@ pdr: Saya serius berpendapat bahwa "kebutuhan untuk tes unit" di tempat pertama adalah kurangnya keamanan jenis. Dan, bukan menjadi pengembang .NET, saya tidak bisa mengatakan banyak tentang pengalaman mereka, tetapi dalam pengalaman saya sendiri, saya telah menemukan bahwa kesulitan dalam refactoring sepenuhnya didasarkan pada dua faktor: apakah saya menulis kode di pertama atau tidak tempat, dan apakah penulis menulis kode dengan baik atau tidak. (Catatan: poin 1 dan 2 tidak harus saling berkorelasi kuat!)
Mason Wheeler

3
@Pdr Unit test tidak membuktikan kode Anda, sebagian besar merupakan pemeriksa sintaks, tetapi dapat sangat berguna selama pengembangan. Tes Integrasi dan Sistem jauh lebih masuk akal. Juga sebagian besar refactoring dalam bahasa yang diketik secara statis dapat dibuktikan aman, pada kenyataannya itulah yang dimaksud dengan refactoring - serangkaian operasi "Aman" yang dikenal yang mengubah kode Anda tanpa memperkenalkan perubahan. Dalam bahasa statis, IDE sering dapat membuat perubahan ini untuk Anda dan memastikan bahwa mereka aman, sesuatu yang sering tidak mungkin dalam bahasa dinamis yang karenanya memerlukan unit test untuk membantu (tidak membuktikan) keamanan yang sama
Bill K

25

Joel Spolsky sendiri menjawab pertanyaan ini pada tahun 2009 :

Joel: Ada perdebatan tentang Pengembangan Didorong Test ... jika Anda memiliki unit test untuk semuanya, hal-hal semacam itu ... banyak orang menulis kepada saya, setelah membaca The Joel Test, untuk mengatakan, "Anda harus memiliki yang ke-13 satu hal di sini: Unit Testing, 100% unit test semua kode Anda. "

Dan itu menurut saya sedikit terlalu doktriner tentang sesuatu yang mungkin tidak Anda butuhkan. Seperti, seluruh ide pemrograman cerdas bukan untuk melakukan hal-hal sebelum Anda membutuhkannya, tetapi untuk kesalahan halaman sesuai kebutuhan. Saya merasa seperti pengujian otomatis atas segalanya, sering kali, tidak akan membantu Anda. Dengan kata lain, Anda akan menulis banyak sekali unit test untuk memastikan kode itu, benar-benar, akan berfungsi, dan Anda pasti akan mencari tahu apakah itu tidak berhasil [jika Anda tidak menulis tes] tidak, sebenarnya masih bekerja, ... Saya tidak tahu, saya akan mendapatkan mail api seperti ini karena saya tidak mengekspresikannya dengan baik. Tapi, saya merasa jika sebuah tim benar-benar memiliki cakupan kode 100% dari tes unit mereka, akan ada beberapa masalah. Satu, mereka akan menghabiskan banyak waktu untuk menulis tes unit, dan mereka tidak perlu membayar untuk waktu itu dalam kualitas yang lebih baik. Maksud saya, mereka akan memiliki beberapa peningkatan kualitas, dan mereka akan memiliki kemampuan untuk mengubah hal-hal dalam kode mereka dengan keyakinan bahwa mereka tidak merusak apa pun, tetapi hanya itu.

Tetapi masalah sebenarnya dengan tes unit seperti yang saya temukan adalah bahwa jenis perubahan yang cenderung Anda buat ketika kode berevolusi cenderung memecah persentase konstan dari tes unit Anda. Kadang-kadang Anda akan membuat perubahan pada kode Anda yang, entah bagaimana, merusak 10% dari tes unit Anda. Sengaja. Karena Anda telah mengubah desain sesuatu ... Anda telah memindahkan menu, dan sekarang semua yang bergantung pada menu itu ada di sana ... menunya ada di tempat lain. Jadi semua tes itu sekarang rusak. Dan Anda harus bisa masuk dan membuat ulang tes-tes itu untuk mencerminkan realitas baru kode.

Jadi, hasil akhirnya adalah, ketika proyek Anda semakin besar dan lebih besar, jika Anda benar-benar memiliki banyak unit test, jumlah investasi yang harus Anda lakukan dalam mempertahankan unit test tersebut, menjaga mereka tetap up-to-date dan menjaga mereka lewat, mulai menjadi tidak proporsional dengan jumlah manfaat yang Anda dapatkan dari mereka.


2
Sangat? Downvotes pada posting jawaban Joel sendiri untuk pertanyaan OP?
Ross Patterson

1
Sulit membayangkan. Beberapa orang menggunakan suara yang berarti "Saya menyetujui" daripada "ini berguna". Ini jelas harus menjadi jawaban yang diterima karena pasti.
Bryan Oakley

Saya belum pernah mengerjakan proyek yang memiliki cakupan pengujian 100%. Tetapi jika Anda memiliki cakupan tes 0% ... ... itu cukup bagus.
Kzqai

Terima kasih! Saya pikir ini harus ditandai sebagai jawaban yang diterima.
Jalal

5

Tidak seorang pun kecuali Joel yang bisa menjawabnya dengan pasti. Tetapi kita dapat mencoba beberapa alasan / pengamatan.

Pertama-tama, pengujian tidak absen dari Tes Joel

  • Tes disebutkan dua kali dalam 12 langkah secara langsung (10 dan 12)
  • Keberadaan bangunan adalah salah satu poin pertama. Gagasan memiliki build adalah untuk mendapatkan kapasitas untuk melihat apakah mereka rusak, jadi kami (juga) berbicara tentang pengujian di sini.

Kedua, seluruh gagasan Tes Joel (seperti yang saya mengerti) adalah untuk memiliki pertanyaan cepat, ya-tidak. "Apakah kamu melakukan TDD?" tidak akan persis cocok (jawabannya bisa: "sebagian dari kita", "untuk bagian kode" atau "kami melakukan pengujian unit".

Ketiga, saya pikir tidak ada yang mengatakan bahwa (bahkan Joel) bahwa titik-titik di mana "satu-satunya yang bernilai waktu" (omong-omong, "apakah Anda memprogram" tidak ada di sana), hanya saja itu adalah pertanyaan cepat yang bagus untuk ditanyakan ketika datang berhubungan dengan tim perangkat lunak, baik sebagai anggota tim di masa depan atau bahkan sebagai pelanggan - ini adalah daftar yang saya berikan kepada beberapa orang non teknis di sekitar saya yang mencari petunjuk tentang seberapa baik / buruk departemen TI mereka sendiri. Ini bukan segalanya, tetapi sangat buruk untuk mengalahkan dalam tiga menit.


3
"Apakah kamu melakukan TDD?" tentu cocok sebagai pertanyaan ya-tidak. Dan maksud saya itu adalah pertanyaan yang semua orang jawab dengan tegas "ya", yang sebenarnya berarti "tidak".
yannis

2
@YannisRizos: Sama seperti "Apakah Anda menggunakan alat terbaik yang bisa dibeli dengan uang?" (Ya ... wellllll ... masuk akal.) Dan "Apakah programmer memiliki kondisi kerja yang tenang?" (Ohhhh ya ... Wellllll ... tergantung pada titik referensi Anda untuk tenang, kurasa.)
pdr

@ pdr Tergantung pada apakah Anda menganggap suara sirene yang masuk melalui jendela yang terbuka sepi.
Robert Harvey

Juga, "Ya, saya melakukan desain top-down ." ;)
Izkata
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.