Bagaimana orang yang melakukan TDD menangani kehilangan pekerjaan saat melakukan refactoring besar

Untuk sementara saya mencoba belajar menulis unit test untuk kode saya.

Awalnya saya mulai melakukan TDD sejati, di mana saya tidak akan menulis kode apa pun sampai saya menulis tes gagal terlebih dahulu.

Namun, saya baru-baru ini memiliki masalah pelik yang harus diselesaikan yang melibatkan banyak kode. Setelah menghabiskan beberapa minggu baik menulis tes dan kemudian kode, saya sampai pada kesimpulan yang disayangkan bahwa seluruh pendekatan saya tidak akan berhasil, dan saya harus membuang dua minggu kerja dan mulai lagi.

Ini adalah keputusan yang cukup buruk untuk muncul ketika Anda baru saja menulis kode, tetapi ketika Anda juga telah menulis beberapa ratus unit tes menjadi lebih sulit secara emosional untuk membuang semuanya.

Saya tidak dapat menahan diri untuk berpikir bahwa saya telah menghabiskan 3 atau 4 hari usaha untuk menulis tes-tes itu ketika saya dapat menyatukan kode untuk bukti konsep dan kemudian menulis tes-tes itu setelah saya puas dengan pendekatan saya.

Bagaimana orang yang berlatih TDD menangani situasi seperti itu dengan benar? Apakah ada kasus untuk menekuk aturan dalam beberapa kasus atau apakah Anda selalu menulis tes dengan rendah hati, bahkan ketika kode itu ternyata tidak berguna?

Saya merasa ada dua masalah di sini. Yang pertama adalah Anda tidak menyadari sebelumnya bahwa desain asli Anda mungkin bukan pendekatan terbaik. Seandainya Anda mengetahui hal ini sebelumnya, Anda mungkin telah memilih untuk mengembangkan satu atau dua prototipe membuang- cepat , untuk mengeksplorasi opsi desain yang mungkin dan untuk menilai mana yang merupakan cara yang paling menjanjikan untuk diikuti. Dalam membuat prototipe, Anda tidak perlu menulis kode kualitas produksi dan tidak perlu menguji unit setiap sudut dan celah (atau sama sekali), karena fokus utama Anda adalah pada pembelajaran, bukan pada pemolesan kode.

Sekarang, menyadari bahwa Anda memerlukan prototipe dan eksperimen daripada memulai pengembangan kode produksi segera, tidak selalu mudah, dan bahkan tidak selalu mungkin. Berbekal pengetahuan yang baru saja didapat, Anda mungkin bisa mengenali kebutuhan untuk membuat prototipe di lain waktu. Atau mungkin juga tidak. Tetapi setidaknya Anda tahu sekarang bahwa opsi ini harus dipertimbangkan. Dan ini sendiri adalah pengetahuan penting.

Masalah lainnya adalah IMHO dengan persepsi Anda. Kita semua membuat kesalahan, dan sangat mudah untuk melihat dalam retrospeksi apa yang seharusnya kita lakukan secara berbeda. Inilah cara kita belajar. Tuliskan investasi Anda dalam unit test karena harga belajar bahwa prototyping mungkin penting, dan selesaikan. Berusahalah untuk tidak melakukan kesalahan yang sama dua kali :-)

Inti dari TDD adalah ia memaksa Anda untuk menulis sedikit peningkatan kode dalam fungsi-fungsi kecil , tepatnya untuk menghindari masalah ini. Jika Anda telah menghabiskan waktu berminggu-minggu menulis kode pada satu domain, dan setiap metode utilitas tunggal yang Anda tulis menjadi tidak berguna ketika Anda memikirkan kembali arsitekturnya, maka metode Anda hampir pasti terlalu besar. (Ya, saya sadar ini tidak benar-benar menghibur sekarang ...)

Brooks berkata "rencanakan untuk membuang satu; Anda akan, bagaimanapun". Sepertinya saya yang melakukan hal itu. Yang mengatakan, Anda harus menulis unit test Anda untuk menguji unit kode dan bukan petak besar kode. Itu adalah tes yang lebih fungsional dan karena itu harus atas implementasi internal.

Misalnya, jika saya ingin menulis pemecah PDE (persamaan diferensial parsial), saya akan menulis beberapa tes yang mencoba menyelesaikan hal-hal yang dapat saya selesaikan secara matematis. Itu adalah tes "unit" pertama saya - baca: tes fungsional dijalankan sebagai bagian dari kerangka kerja xUnit. Itu tidak akan berubah tergantung pada algoritma apa yang saya gunakan untuk menyelesaikan PDE. Yang saya pedulikan adalah hasilnya. Tes unit kedua akan fokus pada fungsi yang digunakan untuk mengkodekan algoritma dan dengan demikian akan spesifik algoritma - katakanlah Runge-Kutta. Jika saya mengetahui bahwa Runge-Kutta tidak cocok, maka saya masih akan menjalani tes tingkat atas (termasuk yang menunjukkan bahwa Runge-Kutta tidak cocok). Jadi iterasi kedua masih akan memiliki banyak tes yang sama dengan yang pertama.

Masalah Anda mungkin pada desain dan belum tentu kode. Tetapi tanpa rincian lebih lanjut, sulit untuk mengatakannya.

Anda harus ingat bahwa TDD adalah proses berulang. Tulis tes kecil (dalam kebanyakan kasus beberapa baris sudah cukup) dan jalankan. Tes harus gagal, sekarang langsung bekerja pada sumber utama Anda dan cobalah untuk mengimplementasikan fungsionalitas yang diuji sehingga tes lulus. Sekarang mulailah dari awal lagi.

Anda sebaiknya tidak mencoba menulis semua tes sekaligus, karena, seperti yang telah Anda perhatikan, ini tidak akan berhasil. Ini mengurangi risiko membuang-buang waktu untuk menulis tes yang tidak akan digunakan.

Saya pikir Anda mengatakannya sendiri: Anda tidak yakin tentang pendekatan Anda sebelum mulai menulis semua tes unit Anda.

Hal yang saya pelajari membandingkan proyek TDD kehidupan nyata yang saya kerjakan (tidak banyak sebenarnya, hanya 3 yang mencakup 2 tahun kerja) dengan apa yang saya pelajari secara teoritis, adalah bahwa Pengujian Otomatis! = Pengujian Unit (tanpa tentu saja saling terkait eksklusif).

Dengan kata lain, T dalam TDD tidak harus memiliki U dengan itu ... Itu otomatis, tetapi kurang tes unit (seperti dalam kelas dan metode pengujian) daripada tes fungsional otomatis: itu pada tingkat yang sama granularity fungsional sebagai arsitektur yang sedang Anda kerjakan. Anda memulai level tinggi, dengan beberapa tes dan hanya gambaran besar fungsional, dan hanya pada akhirnya Anda berakhir dengan ribuan UT, dan semua kelas Anda didefinisikan dengan baik dalam arsitektur yang indah ...

Tes unit memberi Anda banyak bantuan saat Anda bekerja dalam tim, untuk menghindari perubahan kode yang menciptakan siklus bug tanpa akhir. Tapi saya tidak pernah menulis sesuatu yang begitu tepat ketika mulai mengerjakan proyek, sebelum memiliki setidaknya POC global untuk setiap kisah pengguna.

Mungkin ini hanya cara pribadi saya untuk melakukan ini. Saya tidak memiliki pengalaman yang cukup untuk memutuskan dari awal apa pola atau struktur proyek saya akan miliki, jadi memang saya tidak akan membuang waktu saya menulis 100-an UT sejak awal ...

Secara umum, ide untuk menghancurkan segalanya dan membuang semuanya akan selalu ada. Sebagai "terus menerus" seperti yang bisa kita coba dengan alat dan metode kita, kadang-kadang satu-satunya cara untuk melawan entropi adalah memulai dari awal. Tetapi tujuannya adalah bahwa ketika itu terjadi, pengujian otomatis dan unit yang Anda laksanakan akan membuat proyek Anda sudah lebih murah daripada jika tidak ada di sana - dan itu akan terjadi, jika Anda menemukan keseimbangannya.

Bagaimana orang yang berlatih TDD menangani situasi seperti itu dengan benar?

1. dengan mempertimbangkan kapan membuat prototipe vs kapan membuat kode
2. dengan menyadari bahwa pengujian unit tidak sama dengan TDD
3. dengan tulisan tes TDD untuk memverifikasi fitur / cerita, bukan unit fungsional

Penggabungan unit pengujian dengan pengembangan yang digerakkan oleh tes adalah sumber dari banyak kesedihan dan kesengsaraan. Jadi mari kita tinjau sekali lagi:

• unit testing berkaitan dengan memverifikasi setiap modul dan fungsi individu dalam implementasi ; di UT Anda akan melihat penekanan pada hal-hal seperti metrik cakupan kode dan tes yang dijalankan dengan sangat cepat
• pengembangan uji coba berkaitan dengan memverifikasi setiap fitur / cerita dalam persyaratan ; di TDD Anda akan melihat penekanan pada hal-hal seperti menulis tes terlebih dahulu, memastikan bahwa kode yang ditulis tidak melebihi ruang lingkup yang dimaksudkan, dan refactoring untuk kualitas

Singkatnya: pengujian unit memiliki fokus implementasi, TDD memiliki fokus persyaratan. Mereka bukan hal yang sama.

Pengembangan yang digerakkan oleh tes dimaksudkan untuk mendorong pengembangan Anda. Tes yang Anda tulis membantu Anda menegaskan kebenaran kode yang sedang Anda tulis dan meningkatkan kecepatan pengembangan dari baris pertama dan seterusnya.

Anda tampaknya percaya bahwa tes adalah beban dan hanya dimaksudkan untuk pengembangan tambahan nanti. Garis pemikiran ini tidak sejalan dengan TDD.

Mungkin Anda dapat membandingkannya dengan pengetikan statis: meskipun seseorang dapat menulis kode tanpa menggunakan informasi jenis statis, menambahkan jenis statis ke kode membantu dalam menegaskan sifat-sifat tertentu dari kode, membebaskan pikiran dan memungkinkan fokus pada struktur penting sebagai gantinya, sehingga meningkatkan kecepatan dan kemanjuran.

Masalah dengan melakukan refactoring besar adalah Anda bisa dan kadang-kadang akan mengikuti jalan yang membuat Anda sadar bahwa Anda telah menggigit lebih banyak daripada yang bisa Anda kunyah. Refactoring raksasa adalah kesalahan. Jika desain sistem cacat sejak awal, maka refactoring hanya akan membawa Anda sejauh ini sebelum Anda harus membuat keputusan sulit. Baik meninggalkan sistem apa adanya dan bekerja di sekitarnya, atau berencana untuk mendesain ulang dan membuat beberapa perubahan besar.

Namun ada cara lain. Manfaat nyata dari kode refactoring adalah membuat segala sesuatunya lebih sederhana, lebih mudah dibaca, dan bahkan lebih mudah dipelihara. Di mana Anda mendekati masalah yang memiliki ketidakpastian, Anda lonjakan perubahan, melangkah sejauh ini untuk melihat di mana itu mengarah untuk mempelajari lebih lanjut tentang masalah, kemudian membuang lonjakan, dan menerapkan refactoring baru berdasarkan pada apa lonjakan mengajarimu. Masalahnya, Anda benar-benar hanya dapat meningkatkan kode Anda dengan pasti jika langkah-langkahnya kecil dan upaya refactoring Anda tidak menyerbu kemampuan Anda untuk menulis tes Anda terlebih dahulu. Godaannya adalah menulis tes, lalu kode, lalu kode lagi karena sebuah solusi mungkin tampak jelas, tetapi segera Anda menyadari bahwa perubahan Anda akan mengubah lebih banyak tes, jadi Anda harus berhati-hati untuk hanya mengubah satu hal pada satu waktu.

Karena itu jawabannya adalah jangan pernah menjadikan refactoring Anda sebagai yang utama. Langkah kecil. Mulai dengan mengekstraksi metode, lalu lihat untuk menghapus duplikasi. Kemudian pindah ke kelas penggalian. Masing-masing dalam langkah kecil satu perubahan kecil pada satu waktu. JIKA Anda mengekstraksi kode, tulis tes terlebih dahulu. Jika Anda menghapus kode, maka hapus dan jalankan tes Anda, dan putuskan apakah tes yang rusak akan diperlukan lagi. Satu bayi mungil melangkah sekaligus. Sepertinya itu akan memakan waktu lebih lama, tetapi sebenarnya akan mempersingkat waktu refactoring Anda.

Namun kenyataannya adalah bahwa setiap lonjakan tampaknya merupakan pemborosan usaha yang potensial. Perubahan kode terkadang tidak ke mana-mana, dan Anda menemukan diri Anda memulihkan kode dari vcs. Ini hanya kenyataan dari apa yang kita lakukan dari hari ke hari. Namun setiap lonjakan yang gagal tidak sia-sia, jika itu mengajarkan Anda sesuatu. Setiap upaya refactoring yang gagal akan mengajarkan Anda bahwa Anda mencoba melakukan terlalu banyak terlalu cepat, atau bahwa pendekatan Anda mungkin salah. Itu juga bukan buang-buang waktu jika Anda belajar sesuatu darinya. Semakin banyak Anda melakukan hal ini, semakin banyak Anda belajar dan semakin efisien Anda jadinya. Saran saya adalah hanya memakainya untuk saat ini, belajar untuk melakukan lebih banyak dengan melakukan lebih sedikit, dan menerima bahwa ini adalah hal yang mungkin perlu sampai Anda menjadi lebih baik dalam mengidentifikasi seberapa jauh untuk mengambil lonjakan sebelum itu membawa Anda ke mana-mana.

Saya tidak yakin tentang alasan mengapa pendekatan Anda ternyata cacat setelah 3 hari. Bergantung pada ketidakpastian dalam arsitektur Anda, Anda dapat mempertimbangkan untuk mengubah strategi pengujian Anda:

• Jika Anda tidak yakin tentang kinerja, Anda mungkin ingin memulai dengan beberapa tes integrasi yang menyatakan kinerja?

• Ketika kompleksitas API adalah apa yang Anda selidiki, tulis beberapa tes unit kecil yang nyata, untuk mengetahui apa yang akan menjadi cara terbaik untuk melakukannya. Jangan repot-repot mengimplementasikan apa pun, buat saja kelas Anda mengembalikan nilai yang dikodekan atau buat mereka membuang NotImplementedExceptions.

Bagi saya tes unit juga sebagai kesempatan untuk menempatkan antarmuka di bawah penggunaan "nyata" (well, senyata unit test pergi!).

Jika saya dipaksa untuk melakukan tes saya harus menjalankan desain saya. Ini membantu menjaga hal-hal tetap waras (jika ada sesuatu yang begitu rumit sehingga menulis ujian untuk itu adalah beban, bagaimana rasanya menggunakannya?).

Ini tidak menghindari perubahan dalam desain, melainkan memperlihatkan kebutuhan mereka. Ya, penulisan ulang yang lengkap adalah rasa sakit. Untuk (mencoba) menghindarinya, saya biasanya membuat (satu atau lebih) prototipe, mungkin dengan Python (dengan pengembangan akhir dalam c ++).

Memang, Anda tidak selalu punya waktu untuk semua barang ini. Itulah tepatnya kasus ketika Anda akan membutuhkan jumlah waktu yang LEBIH BESAR untuk mencapai tujuan Anda ... dan / atau untuk menjaga semuanya terkendali.

Selamat datang di sirkus pengembang kreatif .

Alih-alih menghormati semua cara 'legal / masuk akal' untuk kode pada awalnya,
cobalah intuisi , terutama jika itu penting dan baru untuk Anda dan jika tidak ada sampel di sekitar yang Anda inginkan:

- Tulis dengan naluri Anda, dari hal-hal yang sudah Anda ketahui , tidak dengan mental dan imajinasi Anda.
- Dan berhenti.
- Ambil kaca pembesar dan periksa semua kata yang Anda tulis: Anda menulis "teks" karena "teks" dekat dengan String, tetapi "kata kerja", "kata sifat" atau sesuatu yang lebih akurat diperlukan, baca lagi dan sesuaikan metode dengan pengertian baru
. .. atau, Anda menulis sepotong kode memikirkan masa depan? hapus
- Benar, lakukan tugas lain (olahraga, budaya, atau hal lain di luar bisnis), kembali dan baca lagi.
- Semua cocok,
- Benar, lakukan tugas lain, kembali dan baca lagi.
- Semua cocok, beralih ke TDD
- Sekarang semuanya benar, bagus
- Coba patok untuk menunjukkan hal-hal yang akan dioptimalkan, lakukanlah.

Apa yang muncul:
- Anda menulis kode yang menghormati semua aturan
- Anda mendapatkan pengalaman, cara baru untuk bekerja,
- sesuatu berubah dalam pikiran Anda, Anda tidak akan pernah takut dengan konfigurasi baru.

Dan sekarang, jika Anda melihat UML yang terlihat seperti di atas, Anda akan dapat mengatakan
"Bos, saya mulai dengan TDD untuk ini ...."
itu adalah hal baru lainnya?
"Bos, saya akan mencoba sesuatu sebelum memutuskan cara saya akan kode .."

Salam dari PARIS
Claude