Dalam kelompok produk kami, kami menargetkan cakupan kode 50-70% dari pengujian unit dan 90% + cakupan dari pengujian unit dan otomatisasi pengujian digabungkan. Waktu umum yang dianggarkan untuk tes unit penulisan adalah sekitar 1 hari untuk setiap fitur yang membutuhkan 3-4 hari pengkodean head down. Tapi itu bisa bervariasi dengan banyak faktor.
Cakupan kode 99% bagus. Tes unit sangat bagus. Tetapi 99% cakupan kode dari pengujian unit saja? Saya merasa sulit untuk percaya bahwa Anda bisa mendapatkan cakupan sebanyak itu dari pengujian unit saja.
Untuk kasus di mana Anda menghabiskan 3 hari menulis tes untuk kelas yang dinyatakan membutuhkan 1 hari untuk diterapkan. Anda tidak menjelaskan mengapa perlu waktu lama atau membagikan kode apa pun. Dari spekulasi, saya kira Anda tidak benar-benar menulis unit test yang benar untuk kelas Anda, tetapi sebenarnya menulis otomatisasi tes . Dan sebenarnya tidak ada yang salah dengan itu - selama Anda mengenali perbedaan antara dua jenis tes yang berbeda.
Tetapi Anda mengatakan tiga hari penulisan tes hanya untuk satu kelas. Mungkin kelas itu sendiri tidak dirancang untuk pengujian unit. Apakah kelas menerapkan UI? Jaringan? File I / O? Jika demikian, Anda mungkin akhirnya menulis lebih banyak kode untuk menguji runtime Java daripada logika bisnis Anda yang berinteraksi dengan runtime.
TDD membuat Anda berpikir dalam hal antarmuka dan antarmuka untuk dependensi. Kelas tunggal yang mengimplementasikan UI, jaringan, dan file / io untuk fitur tunggal mungkin lebih baik disajikan dibagi menjadi beberapa kelas - satu untuk jaringan, satu untuk file / io, dan UI dipecah menjadi desain model-viewer-controller. Kemudian Anda dapat menerapkan tes yang sesuai untuk masing-masing dengan objek tiruan sederhana untuk dependensi. Tentu saja, semua ini membutuhkan lebih banyak waktu. Jadi, daripada 1 hari untuk kode dan 3 hari untuk menulis tes, jenis desain ini mungkin memerlukan 3 hari pengkodean dan 1 hari tes menulis. Tetapi kode akan jauh lebih baik dipelihara dan digunakan kembali.