Saya ingin mengajukan pertanyaan ini, untuk melihat berapa banyak perusahaan yang benar-benar mempraktikkan TDD.
Dalam 11 tahun saya telah memprogram secara profesional hanya dua organisasi terakhir yang bahkan menyadari TDD (yang terbentang hampir 5 tahun, sebelum waktu itu TDD tidak sepopuler sekarang). Saya akan memotong untuk mengejar dan menjawab pertanyaan Anda sebelum menyimpang ke penjualan saya untuk TDD :)
Di perusahaan terakhir tempat saya bekerja (penerbit akademis online untuk koleksi humaniora dan sains), kami tahu kami perlu berlatih TDD tetapi kami tidak pernah berhasil. Dalam pembelaan kami, kami memiliki basis kode 250k, jadi menambahkan tes ke basis kode yang tidak dapat diuji ukurannya terasa tidak dapat diatasi (saya merasa bersalah mengetik itu sekarang!). Bahkan yang terbaik dari kita membuat kesalahan .
Siapa pun yang telah melakukan bahkan sejumlah kecil TDD tahu betapa menyakitkannya pengujian retrofit pada kode brown field yang tidak dapat diuji dapat menjadi ... Penyebab utama adalah dependensi implisit (Anda tidak dapat menarik semua tuas untuk menegaskan hasil dari kode - Anda tidak dapat mengejek skenario) dan pelanggaran prinsip tanggung jawab tunggal (tes rumit, dibuat-buat, membutuhkan terlalu banyak pengaturan dan sulit dipahami ).
Kami sementara meningkatkan tim QA kami (dari satu, mungkin dua orang menjadi setengah lusin atau lebih) untuk menguji platform sebelum rilis. Itu adalah waktu yang sangat mahal dan secara finansial bijaksana, beberapa rilis akan memakan waktu tiga bulan untuk menyelesaikan 'pengujian'. Bahkan pada saat itu kami tahu kami menghadapi masalah, mereka bukan 'pemblokir' atau 'kritis', hanya 'prioritas tinggi'.
Jika Anda memiliki pengalaman komersial selama bertahun-tahun, Anda akan menghargai bahwa setiap perusahaan menegaskan tugas - tugas penting , dan kemudian menciptakan tingkat prioritas yang lebih tinggi di atas itu, dan kemungkinan besar satu di atas itu juga - terutama ketika seseorang dari atas mendorong perbaikan fitur / bug. Saya ngelantur ...
Saya senang melaporkan saya sedang berlatih TDD di perusahaan saya saat ini (telekomunikasi, web, dan rumah pengembangan aplikasi seluler), ditambah dengan Jenkins CI untuk memberikan laporan analisis statis lainnya (cakupan kode menjadi yang paling berguna setelah menegaskan test suite lulus) . Proyek tempat saya menggunakan TDD adalah sistem pembayaran dan sistem komputasi grid.
Promosi penjualan ...
Ini seringkali bisa menjadi perjuangan berat yang membenarkan pengujian otomatis untuk anggota tim non-teknis. Tes menulis memang menambah lebih banyak pekerjaan pada proses pengembangan tetapi ... saat Anda berinvestasi dalam pengujian sekarang, Anda akan menghemat dalam upaya pemeliharaan nanti. Anda benar-benar hanya meminjam waktu . Semakin lama produk digunakan, semakin besar penghematan yang akan Anda buat - dan itu akan membantu Anda menghindari penulisan ulang yang besar .
Tes pertama berarti Anda mengkode niat Anda terlebih dahulu, dan kemudian mengonfirmasi kode Anda memenuhi niat itu. Ini memberikan fokus dan menyaring kode Anda untuk hanya melakukan apa yang dimaksudkan dan tidak lebih (baca tanpa mengasapi). Ini adalah spesifikasi dan dokumentasi yang dapat dieksekusi pada saat yang sama (jika tes Anda ditulis dengan baik, dan tes harus dapat dibaca / bersih seperti kode sistem Anda, jika tidak lebih!).
Non-programmer tidak akan (sering) tidak memiliki wawasan ini sehingga TDD tidak memiliki banyak nilai untuk mereka, dan dianggap sebagai jalan pintas sekali pakai ke tanggal rilis sebelumnya.
Pemrograman adalah domain kami , dan menurut saya ini menjadikannya tanggung jawab kami , sebagai profesional, untuk memberi saran tentang praktik terbaik seperti TDD. Bukan untuk manajer proyek untuk memutuskan apakah itu dilakukan untuk mengurangi waktu pengembangan, itu di luar yurisdiksi mereka . Dengan cara yang sama mereka tidak memberi tahu Anda apa kerangka kerja, solusi caching atau algoritma pencarian untuk digunakan, mereka seharusnya tidak memberi tahu Anda jika Anda harus menggunakan pengujian otomatis.
Menurut pendapat saya industri pengembangan perangkat lunak (secara keseluruhan) rusak saat ini, fakta bahwa memiliki tes untuk perangkat lunak Anda BUKAN norma.
Bayangkan ini di industri lain: medis, penerbangan, mobil, kosmetik, mainan lunak, minuman beralkohol dll. Saya meminta tunangan saya untuk menyebutkan sebuah industri di mana mereka tidak menguji produk dan dia tidak bisa!
Mungkin tidak adil untuk mengatakan tidak ada pengujian yang terjadi karena ... tetapi di perusahaan tanpa pengujian otomatis, prosesnya sangat manual / manusiawi (baca kikuk dan sering rawan kesalahan).
Satu hal yang saya akan pertanyakan dalam pertanyaan Anda ...
Mereka biasanya ingin pengembangan dimulai segera, atau setelah bertugas desain pendek. Lebih mirip dengan Agile.
Menjadi "Agile" tidak meresepkan proses tanpa tes, anggota pertama yang terdaftar di agilemanifesto.org adalah Kent Beck , pencipta XP dan TDD!
Dua buku yang saya sangat sarankan jika Anda tertarik pada TDD, atau hanya belum membacanya dan merupakan programmer yang tertarik (semua orang membaca ini kan?;)
Tumbuh Perangkat Lunak Berorientasi Objek Dipandu oleh Tes
Kode Bersih - Robert C Martin ("Paman Bob") Seri
Dua buku ini saling melengkapi satu sama lain dan memadatkan banyak arti menjadi beberapa halaman.
Terima kasih telah mengajukan pertanyaan ini :)