Pertanyaan Kekurangan Pengembangan Test Driven? [Tutup]


Apa yang saya kalah dengan mengadopsi desain yang digerakkan oleh pengujian?

Cantumkan hanya negatif; jangan daftar manfaat yang ditulis dalam bentuk negatif.


186


asal


Jawaban:


Beberapa kerugian (dan saya tidak mengklaim tidak ada manfaat - terutama ketika menulis fondasi proyek - itu akan menghemat banyak waktu di akhir):

  • Investasi waktu besar. Untuk kasus sederhana, Anda kehilangan sekitar 20% dari implementasi yang sebenarnya, tetapi untuk kasus yang rumit, Anda kehilangan jauh lebih banyak.
  • Kompleksitas tambahan. Untuk kasus yang rumit, kasus uji Anda lebih sulit untuk dihitung, saya akan menyarankan dalam kasus seperti itu untuk mencoba dan menggunakan kode referensi otomatis yang akan berjalan secara paralel dalam versi debug / uji coba, sebagai ganti uji unit kasus yang paling sederhana.
  • Dampak Desain. Kadang-kadang desain tidak jelas di awal dan berevolusi ketika Anda pergi - ini akan memaksa Anda untuk mengulang tes Anda yang akan menghasilkan kehilangan waktu besar. Saya akan menyarankan untuk menunda tes unit dalam kasus ini sampai Anda memahami desain dalam pikiran.
  • Tweaking Berkelanjutan. Untuk struktur data dan tes unit algoritma kotak hitam akan sempurna, tetapi untuk algoritme yang cenderung diubah, diubah atau diperbaiki, ini dapat menyebabkan investasi waktu besar yang dapat diklaim tidak dibenarkan. Jadi gunakan itu ketika Anda berpikir itu benar-benar sesuai dengan sistem dan jangan memaksakan desain agar sesuai dengan TDD.

122



Jika Anda ingin melakukan TDD "nyata" (baca: uji pertama dengan langkah-langkah red, green, refactor) maka Anda juga harus mulai menggunakan tiruan / rintisan, ketika Anda ingin menguji titik-titik integrasi.

Ketika Anda mulai menggunakan tiruan, setelah beberapa saat, Anda akan ingin mulai menggunakan Injeksi Ketergantungan (DI) dan wadah Inversi Kontrol (IOC). Untuk melakukan itu Anda perlu menggunakan antarmuka untuk semuanya (yang memiliki banyak perangkap sendiri).

Pada akhirnya, Anda harus menulis lebih banyak kode, daripada jika Anda hanya melakukannya dengan "cara lama yang polos". Alih-alih hanya kelas pelanggan, Anda juga perlu menulis antarmuka, kelas tiruan, konfigurasi IoC dan beberapa tes.

Dan ingat bahwa kode tes juga harus dipelihara dan dirawat. Tes harus dapat dibaca seperti yang lainnya dan dibutuhkan waktu untuk menulis kode yang baik.

Banyak pengembang tidak begitu mengerti bagaimana melakukan semua ini "dengan cara yang benar". Tetapi karena semua orang mengatakan kepada mereka bahwa TDD adalah satu-satunya cara yang benar untuk mengembangkan perangkat lunak, mereka hanya mencoba sebaik mungkin.

Jauh lebih sulit dari yang dipikirkan orang. Seringkali proyek yang dilakukan dengan TDD berakhir dengan banyak kode yang tidak ada yang benar-benar mengerti. Tes unit sering menguji hal yang salah, dengan cara yang salah. Dan tidak ada yang setuju bagaimana seharusnya tes yang baik terlihat, bahkan guru yang disebut.

Semua tes tersebut membuatnya jauh lebih sulit untuk "berubah" (berlawanan dengan refactoring) perilaku sistem Anda dan perubahan sederhana hanya menjadi terlalu sulit dan memakan waktu.

Jika Anda membaca literatur TDD, selalu ada beberapa contoh yang sangat bagus, tetapi sering dalam aplikasi kehidupan nyata, Anda harus memiliki antarmuka pengguna dan database. Di sinilah TDD menjadi sangat sulit, dan sebagian besar sumber tidak menawarkan jawaban yang baik. Dan jika mereka melakukannya, itu selalu melibatkan abstraksi lebih: objek tiruan, pemrograman ke antarmuka, pola MVC / MVP dll, yang lagi-lagi membutuhkan banyak pengetahuan, dan ... Anda harus menulis lebih banyak kode.

Jadi hati-hati ... jika Anda tidak memiliki tim yang antusias dan setidaknya satu pengembang berpengalaman yang tahu cara menulis tes yang baik dan juga tahu beberapa hal tentang arsitektur yang baik, Anda benar-benar harus berpikir dua kali sebelum turun jalan TDD .


178



Ketika Anda sampai pada titik di mana Anda memiliki sejumlah besar tes, mengubah sistem mungkin memerlukan penulisan ulang beberapa atau semua tes Anda, tergantung pada mana yang menjadi tidak valid oleh perubahan. Ini bisa mengubah modifikasi yang relatif cepat menjadi sangat memakan waktu.

Juga, Anda mungkin mulai membuat keputusan desain berdasarkan lebih pada TDD daripada pada desain yang benar-benar baik. Sedangkan Anda mungkin memiliki solusi yang sangat sederhana dan mudah yang tidak mungkin untuk menguji tuntutan TDD, Anda sekarang memiliki sistem yang jauh lebih rumit yang sebenarnya lebih rentan terhadap kesalahan.


66



Saya pikir masalah terbesar bagi saya adalah hilangnya waktu BESAR yang dibutuhkan untuk "masuk ke dalamnya". Saya masih sangat banyak pada awal perjalanan saya dengan TDD (Lihat saya blog untuk memperbarui petualangan pengujian saya jika Anda tertarik) dan saya benar-benar telah menghabiskan jam mulai.

Dibutuhkan waktu lama untuk memasukkan otak Anda ke "mode pengujian" dan menulis "kode yang dapat diuji" adalah keterampilan tersendiri.

TBH, saya dengan hormat tidak setuju dengan Komentar Jason Cohen untuk membuat metode pribadi menjadi publik, bukan itu tentang apa. Saya tidak lagi membuat metode publik dalam cara kerja saya yang baru daripada sebelumnya. Memang, bagaimanapun melibatkan perubahan arsitektur dan memungkinkan Anda untuk "hot plug" modul kode untuk membuat segalanya lebih mudah untuk menguji. Kamu harus tidak membuat internal kode Anda lebih mudah diakses untuk melakukan hal ini. Kalau tidak, kita kembali ke titik awal dengan segala sesuatu menjadi publik, di mana enkapsulasi dalam hal itu?

Jadi, (IMO) secara singkat:

  • Jumlah waktu yang diambil untuk berpikir (yaitu benar-benar grok'ing pengujian).
  • Pengetahuan baru yang dibutuhkan untuk mengetahui cara menulis kode yang dapat diuji.
  • Memahami perubahan arsitektur yang diperlukan untuk membuat kode dapat diuji.
  • Meningkatkan keahlian Anda "TDD-Coder" sambil mencoba meningkatkan semua keterampilan lain yang diperlukan untuk kerajinan pemrograman kami yang gemilang :)
  • Mengatur basis kode Anda untuk memasukkan kode pengujian tanpa mengacaukan kode produksi Anda.

NB: Jika Anda ingin tautan ke hal-hal positif, saya telah bertanya dan menjawab beberapa pertanyaan tentang itu, periksa saya Profil.


51



Dalam beberapa tahun saya telah berlatih Test Driven Development, saya harus mengatakan bahwa kelemahan terbesarnya adalah:

Menjualnya ke manajemen

TDD paling baik dilakukan secara berpasangan. Untuk satu, sulit untuk menahan dorongan untuk hanya menulis implementasi ketika Anda TAHU bagaimana cara menulis jika ya pernyataan. Tapi sepasang akan membuat Anda tetap pada tugas karena Anda membuatnya tetap pada tugas. Sayangnya, banyak perusahaan / manajer tidak berpikir bahwa ini adalah penggunaan sumber daya yang baik. Mengapa membayar dua orang untuk menulis satu fitur, ketika saya memiliki dua fitur yang perlu dilakukan pada saat yang bersamaan?

Menjualnya ke pengembang lain

Beberapa orang tidak memiliki kesabaran untuk menulis tes unit. Beberapa sangat bangga dengan pekerjaan mereka. Atau, beberapa seperti melihat metode / fungsi berbelit-belit memudar dari ujung layar. TDD bukan untuk semua orang, tapi saya benar-benar berharap itu terjadi. Itu akan membuat pemeliharaan barang jadi lebih mudah bagi orang-orang miskin yang mewarisi kode.

Mempertahankan kode pengujian bersama dengan kode produksi Anda

Idealnya, tes Anda hanya akan pecah ketika Anda membuat keputusan kode yang buruk. Artinya, Anda mengira sistem bekerja dengan satu cara, dan ternyata tidak. Dengan melanggar tes, atau serangkaian tes (kecil), ini sebenarnya adalah kabar baik. Kamu tahu persis bagaimana kode baru Anda akan memengaruhi sistem. Namun, jika tes Anda ditulis dengan buruk, digabungkan dengan erat atau, lebih buruk lagi, dihasilkan (batuk VS Test), maka mempertahankan tes Anda bisa menjadi paduan suara dengan cepat. Dan, setelah cukup banyak tes mulai menyebabkan lebih banyak pekerjaan yang dirasakan nilai yang mereka ciptakan, maka tes akan menjadi hal pertama yang harus dihapus ketika jadwal menjadi terkompresi (misalnya sampai ke waktu krisis)

Tes tulis sehingga Anda mencakup semuanya (100% cakupan kode)

Idealnya, sekali lagi, jika Anda mematuhi metodologi, kode Anda akan 100% diuji secara default. Biasanya, saya berpikir, saya mendapatkan cakupan kode hingga 90%. Ini biasanya terjadi ketika saya memiliki beberapa arsitektur gaya template, dan basis diuji, dan saya mencoba untuk memotong sudut dan tidak menguji kustomisasi template. Juga, saya telah menemukan bahwa ketika saya menemukan penghalang baru yang sebelumnya tidak saya temui, saya memiliki kurva belajar dalam mengujinya. Saya akan mengakui menulis beberapa baris kode dengan cara skool lama, tapi saya benar-benar ingin memiliki 100% itu. (Saya kira saya lebih berprestasi di sekolah, er skool).

Namun, dengan itu saya akan mengatakan bahwa manfaat TDD jauh lebih besar daripada yang negatif untuk ide sederhana bahwa jika Anda dapat mencapai serangkaian tes yang baik yang menutupi aplikasi Anda tetapi tidak begitu rapuh sehingga satu perubahan akan merusak semuanya, Anda akan dapat terus menambahkan fitur baru pada hari ke 300 dari proyek Anda seperti yang Anda lakukan pada hari ke-1. Ini tidak terjadi dengan semua orang yang mencoba TDD berpikir itu adalah peluru ajaib untuk semua kode bug-sarat mereka, dan mereka pikir itu bisa bekerja, titik.

Secara pribadi saya telah menemukan bahwa dengan TDD, saya menulis kode yang lebih sederhana, saya menghabiskan lebih sedikit waktu berdebat jika solusi kode tertentu akan berfungsi atau tidak, dan bahwa saya tidak takut untuk mengubah setiap baris kode yang tidak memenuhi kriteria yang ditetapkan oleh tim.

TDD adalah disiplin yang sulit untuk dikuasai, dan saya telah melakukannya selama beberapa tahun, dan saya masih belajar teknik pengujian baru setiap saat. Ini adalah investasi waktu besar di depan, tetapi, dalam jangka panjang, keberlanjutan Anda akan jauh lebih besar daripada jika Anda tidak memiliki tes unit otomatis. Sekarang, seandainya atasan saya tahu hal ini.


47



Pada proyek TDD pertama Anda, ada dua kerugian besar, waktu dan kebebasan pribadi

Anda kehilangan waktu karena:

  • Membuat suite unit dan tes penerimaan yang komprehensif, terfokus, dapat diperbaiki menambah waktu utama untuk iterasi pertama proyek. Ini mungkin menghemat waktu dalam jangka panjang tetapi sama-sama bisa jadi waktu yang tidak perlu Anda habiskan.
  • Anda harus memilih dan menjadi ahli dalam seperangkat alat inti. Alat pengujian unit perlu dilengkapi dengan semacam kerangka mengejek dan keduanya harus menjadi bagian dari sistem build otomatis Anda. Anda juga ingin memilih dan menghasilkan metrik yang sesuai.

Anda kehilangan kebebasan pribadi karena:

  • TDD adalah cara penulisan kode yang sangat disiplin yang cenderung menggosok mentah terhadap orang-orang di bagian atas dan bawah dari skala keterampilan. Selalu menulis kode produksi dengan cara tertentu dan menundukkan pekerjaan Anda pada tinjauan sejawat terus-menerus dapat membuat pengembang Anda menjadi yang terburuk dan terbaik dan bahkan menyebabkan hilangnya jumlah karyawan.
  • Kebanyakan metode Agile yang menanamkan TDD mengharuskan Anda berbicara dengan klien secara terus-menerus tentang apa yang ingin Anda capai (dalam cerita ini / hari / apa pun) dan apa trade off-nya. Sekali lagi ini tidak semua orang secangkir teh, baik di sisi pengembang pagar dan klien.

Semoga ini membantu


24



TDD mengharuskan Anda untuk merencanakan bagaimana kelas Anda akan beroperasi sebelum Anda menulis kode untuk lulus tes tersebut. Ini adalah nilai plus dan minus.

Saya merasa sulit untuk menulis tes dalam "kekosongan" - sebelum ada kode yang ditulis. Dalam pengalaman saya, saya cenderung tersandung tes saya setiap kali saya pasti memikirkan sesuatu saat menulis kelas saya bahwa saya lupa saat menulis tes awal saya. Maka saatnya untuk tidak hanya refactor kelas saya, tetapi JUGA tes saya. Ulangi ini tiga atau empat kali dan itu bisa membuat frustrasi.

Saya lebih suka menulis draf kelas saya terlebih dahulu kemudian menulis (dan memelihara) baterai tes unit. Setelah saya memiliki draft, TDD berfungsi dengan baik untuk saya. Sebagai contoh, jika bug dilaporkan, saya akan menulis tes untuk mengeksploitasi bug itu dan kemudian memperbaiki kode sehingga lulus tes.


15



Prototyping bisa sangat sulit dengan TDD - ketika Anda tidak yakin jalan apa yang akan Anda ambil untuk solusi, menulis tes di depan dapat menjadi sulit (selain yang sangat luas). Ini bisa menjadi sakit.

Jujur saja, saya tidak berpikir bahwa untuk "pengembangan inti" untuk sebagian besar proyek, ada kerugian yang nyata. itu berbicara lebih banyak daripada yang seharusnya, biasanya oleh orang-orang yang percaya kode mereka cukup baik bahwa mereka tidak perlu tes (tidak pernah ada) dan orang-orang yang sekadar tidak dapat diganggu untuk menulisnya.


11



Nah, dan peregangan ini, Anda perlu men-debug tes Anda. Juga, ada biaya tertentu dalam waktu untuk menulis tes, meskipun kebanyakan orang setuju bahwa itu adalah investasi di muka yang terbayar selama masa pakai aplikasi baik dalam menghemat waktu debugging dan stabilitas.

Masalah terbesar yang saya alami sendiri, adalah, bangun disiplin untuk benar-benar menulis tes. Dalam tim, terutama tim yang sudah mapan, akan sulit untuk meyakinkan mereka bahwa waktu yang dihabiskan sangat berharga.


9