Apakah ada area di mana TDD memberikan ROI tinggi dan area lain di mana ROI sangat rendah sehingga tidak layak untuk diikuti? [Tutup]

Pengembangan yang digerakkan oleh tes. Saya mengerti, menyukainya.

Tetapi tes menulis memang membutuhkan biaya tambahan. Jadi sebaiknya TDD digunakan secara universal di seluruh basis kode, atau apakah ada area di mana TDD menyediakan ROI tinggi dan area lain di mana ROI sangat rendah sehingga tidak layak untuk diikuti.

Saya akan mengatakan menghindari TDD di tempat-tempat di mana kode cenderung banyak berubah secara struktural. Yaitu, bagus untuk memiliki setumpuk tes untuk metode yang tanda tangannya jarang berubah tetapi mendapat refactored secara internal lebih sering, tetapi menyebalkan harus memperbaiki tes Anda setiap kali antarmuka yang sangat mudah berubah berubah secara dramatis.

Aplikasi yang saya kerjakan baru-baru ini adalah webapps berbasis data yang dibangun di atas arsitektur berbasis Gui> Presenter-> BusinessLogic-> Data Layer. Lapisan akses data saya diuji seperti urusan siapa pun. Lapisan logika bisnis diuji dengan cukup baik. Presenter hanya diuji di area yang lebih stabil, dan GUI, yang berubah setiap jam, hampir tidak memiliki tes.

Saya menyarankan untuk menulis test suite lengkap di area-area yang masuk akal dan praktis untuk dilakukan. Di area yang kurang praktis, tulis cek kewarasan.

Dalam pengalaman saya, overhead dari set lengkap kasus uji tentu layak dalam kebanyakan kasus, tetapi cakupan kode secara realistis memiliki hasil yang semakin berkurang. Pada titik tertentu, menulis lebih banyak tes hanya untuk meningkatkan cakupan kode tidak masuk akal.

Misalnya, tergantung pada bahasa / teknologi Anda, pengujian UI mungkin tidak praktis atau bahkan layak. Banyak tes mungkin akan bergantung pada apa yang dilihat pengguna dan tidak dapat diotomatisasi. Bagaimana Anda menguji bahwa metode untuk menghasilkan captcha menghasilkan gambar yang dapat dibaca oleh manusia misalnya?

Jika satu set tes lengkap akan membawa Anda tiga hari untuk menulis, kemungkinan bug yang diperkenalkan pada komponen itu di trek sangat rendah, dan fungsi itu sendiri hanya membutuhkan waktu setengah jam untuk menulis, Anda mungkin harus berpikir keras tentang apakah waktu itu sepadan. Mungkin hanya menulis cek kewarasan dasar untuk fungsi itu akan memberikan nilai?

Saran umum saya adalah bahwa Anda harus menguji komponen sepenuhnya di mana tes dapat ditulis dengan relatif mudah. Namun, jika itu adalah area yang sangat sulit untuk diuji, buat garis di pasir dan tulis tes yang akan menguji area tersebut pada level yang lebih tinggi daripada mengujinya sepenuhnya.

Dalam contoh captcha sebelumnya, mungkin menulis tes yang memeriksa gambar dengan ukuran dan format yang benar dikembalikan dan tidak ada pengecualian yang dilemparkan. Itu memberi Anda beberapa tingkat jaminan tanpa berlebihan.

Bagi saya, TDD bukan overhead. Itu hanya cara saya menulis kode. Mengapa Anda mengatakan bahwa tes menulis adalah "overhead"? Itu hanya bagian dari proses. Pandangan saya adalah bahwa debugging adalah overhead, dan itu adalah aktivitas yang pada dasarnya saya berhenti lakukan ketika saya mulai TDD-ing. Sebelum TDD, debugging adalah bagian integral dari proses penulisan perangkat lunak saya.

Saya pikir menyerah debugging untuk penulisan tes adalah tawaran yang sangat bagus.

Satu tempat di mana TDD benar-benar menyebalkan adalah ketika menguji tampilan di aplikasi MVC.

Karena Anda menguji fungsi yang mengembalikan string html yang gemuk, Anda terjebak melakukan penguraian html hanya untuk melihat apakah ada yang berhasil. Selain itu, itu bisa menjadi mimpi buruk rawatan. Suatu hari Anda memindahkan kotak centang dan kaboom, tes Anda rusak.

Saya suka TDD untuk banyak pengujian saya, tetapi itu bukan satu-satunya alat di sabuk programmer.