Bagaimana bayi Anda di TDD?

Hari ini kami melatih TDD dan menemukan titik kesalahpahaman berikut.

Tugasnya adalah untuk input "1,2" mengembalikan jumlah angka yang adalah 3. Apa yang saya tulis (dalam C #) adalah:

numbers = input.Split(',');
return int.Parse(numbers[0]) + int.Parse(numbers[1]); //task said we have two numbers and input is correct

Tapi cowok lain lebih suka melakukannya dengan cara lain. Pertama, untuk input "1,2" mereka menambahkan kode berikut:

if (input == "1,2")
   return 3;

Kemudian mereka memperkenalkan satu tes lagi untuk input "4,5" dan mengubah implementasi:

if (input == "1,2")
   return 3;
else if (input == "4,5")
   return 9;

Dan setelah itu mereka berkata "Oke, sekarang kita melihat polanya" dan menerapkan apa yang awalnya saya lakukan.

Saya pikir pendekatan kedua lebih cocok dengan definisi TDD tapi ... haruskah kita begitu ketat tentang hal itu? Bagi saya tidak apa-apa untuk melewati langkah-langkah bayi sepele dan menggabungkannya menjadi "langkah kembar" jika saya cukup yakin bahwa saya tidak akan melewatkan apa pun. Apakah aku salah?

Memperbarui. Saya telah membuat kesalahan dengan tidak menjelaskan bahwa itu bukan tes pertama. Sudah ada beberapa tes sehingga "return 3" sebenarnya bukan bagian kode yang paling sederhana untuk memenuhi persyaratan.

Tulis kode paling sederhana yang membuat tes lulus.

Tak satu pun dari Anda melakukan itu, sejauh yang saya bisa lihat.

Baby Step 1.

Uji: Untuk input "1,2" kembalikan jumlah angka yaitu 3

Buat tes gagal:

throw NotImplementedException();

Buat tes lulus:

return 3;

Baby Step 2.

Uji: Untuk input "1,2" kembalikan jumlah angka, yaitu 3

Uji: Untuk input "4,5" kembalikan jumlah angka, yaitu 9

Tes kedua gagal, jadi selesaikan:

numbers = input.Split(',');
return int.Parse(numbers[0]) + int.Parse(numbers[1]);

(Jauh lebih sederhana daripada daftar jika ... kembali)

Anda tentu saja dapat memperdebatkan Implementasi Jelas dalam kasus ini, tetapi jika Anda berbicara tentang melakukannya secara ketat dalam langkah-langkah kecil maka ini adalah langkah yang benar, IMO.

Argumennya adalah bahwa jika Anda tidak menulis tes kedua maka beberapa percikan terang dapat muncul kemudian dan "refactor" kode Anda untuk membaca:

return input.Length; # Still satisfies the first test

Dan, tanpa mengambil kedua langkah, Anda tidak pernah membuat tes kedua menjadi merah (artinya tes itu sendiri adalah dugaan).

Saya pikir cara kedua adalah pikiran mati rasa bodoh. Saya melihat nilai dalam membuat langkah-langkah yang cukup kecil, tetapi menulis zigot kecil itu (bahkan tidak bisa menyebutnya bayi) langkah-langkahnya sama saja dengan membuang-buang waktu. Apalagi jika masalah awal yang Anda selesaikan sudah sangat kecil.

Saya tahu ini pelatihan dan lebih tentang menunjukkan prinsip, tapi saya pikir contoh seperti itu melakukan TDD lebih buruk daripada baik. Jika Anda ingin menunjukkan nilai langkah bayi, setidaknya gunakan masalah di mana ada beberapa nilai di dalamnya.

Kent Beck membahas ini dalam bukunya, Test Driven Development: By Example.

Contoh Anda menunjukkan ' implementasi jelas ' - Anda ingin mengembalikan jumlah dua nilai input, dan ini adalah algoritma yang cukup mendasar untuk dicapai. Contoh tandingan Anda jatuh ke 'palsu sampai Anda berhasil' (meskipun kasus yang sangat sederhana).

Implementasi yang jelas dapat menjadi jauh lebih rumit dari ini - tetapi pada dasarnya itu muncul ketika spesifikasi untuk suatu metode cukup ketat - misalnya, kembalikan URL yang disandikan versi properti kelas - Anda tidak perlu membuang waktu dengan banyak pengkodean palsu.

Sebaliknya, rutinitas koneksi basis data akan memerlukan sedikit pemikiran dan pengujian sehingga tidak ada implementasi yang jelas (bahkan jika Anda mungkin telah menulis beberapa kali di proyek lain).

Dari buku:

Ketika saya menggunakan TDD dalam praktiknya, saya biasanya beralih di antara dua mode implementasi ini, Ketika semuanya berjalan lancar dan saya tahu apa yang harus diketik, saya memasukkan Obvious Implementation setelah Obvious Implementasi (menjalankan tes setiap kali untuk memastikan bahwa apa yang jelas bagi saya) masih jelas ke komputer). Segera setelah saya mendapatkan bilah merah yang tidak terduga, saya mencadangkan, beralih ke pemalsuan implementasi, dan refactor ke kode yang benar. Ketika kepercayaan diri saya kembali, saya kembali ke Obvious Implementations.

Saya melihat ini sebagai mengikuti surat hukum, tetapi tidak semangatnya.

Langkah bayi Anda harus:

Sesederhana mungkin, tetapi tidak sederhana.

Juga, kata kerja dalam metode ini adalah sum

if (input == "1,2")
   return 3;

bukan jumlah, ini adalah tes untuk input spesifik.

Bagi saya kelihatannya baik untuk menggabungkan beberapa langkah implementasi sepele menjadi satu yang sedikit kurang sepele - Saya juga selalu melakukannya. Saya tidak berpikir orang perlu menjadi religius tentang mengikuti TDD setiap kali surat itu.

OTOH ini hanya berlaku untuk langkah-langkah sepele seperti contoh di atas. Untuk sesuatu yang lebih kompleks, yang tidak dapat sepenuhnya saya ingat dalam pikiran saya sekaligus dan / atau di mana saya tidak yakin 110% tentang hasilnya, saya lebih suka melangkah satu langkah pada satu waktu.

Ketika pertama kali memulai jalan TDD ukuran langkah-langkah bisa menjadi masalah yang membingungkan, seperti yang digambarkan pertanyaan ini. Sebuah pertanyaan yang sering saya tanyakan pada diri saya ketika saya mulai menulis aplikasi yang digerakkan oleh tes adalah; Apakah tes yang saya tulis membantu mendorong pengembangan aplikasi saya? Ini mungkin tampak sepele dan tidak ada hubungannya dengan beberapa orang tetapi bertahan sebentar dengan saya.

Sekarang ketika saya mulai menulis aplikasi apa pun saya biasanya akan mulai dengan tes. Seberapa besar langkah yang sebagian besar dari tes ini berkaitan dengan pemahaman saya tentang apa yang saya coba lakukan. Jika saya pikir saya memiliki perilaku kelas di kepala saya maka langkahnya akan menjadi besar. Jika masalah yang saya coba selesaikan jauh lebih tidak jelas maka langkahnya mungkin saja saya tahu akan ada metode bernama X dan akan mengembalikan Y. Pada titik ini metode tersebut bahkan tidak akan memiliki parameter dan ada kemungkinan bahwa nama metode dan tipe pengembalian akan berubah. Dalam kedua kasus, tes mendorong perkembangan saya. Mereka memberi tahu saya hal-hal tentang aplikasi saya:

Apakah kelas ini yang ada di kepala saya benar-benar akan bekerja?

atau

Bagaimana aku bisa melakukan hal ini?

Intinya adalah saya bisa beralih antara langkah besar dan langkah kecil dalam sekejap mata. Misalnya, jika langkah besar tidak berhasil dan saya tidak bisa melihat jalan yang jelas, saya akan beralih ke langkah yang lebih kecil. Jika itu tidak berhasil saya akan beralih ke langkah yang lebih kecil. Lalu ada teknik lain seperti triangulasi jika saya benar-benar macet.

Jika seperti saya Anda adalah seorang pengembang dan bukan seorang tester maka tujuan menggunakan TDD bukan untuk menulis tes tetapi untuk menulis kode. Jangan terpaku pada penulisan banyak tes kecil jika tidak memberi Anda manfaat.

Saya harap Anda menikmati pelatihan Anda tongkat dengan TDD. IMHO jika lebih banyak orang yang terinfeksi tes maka dunia akan menjadi tempat yang lebih baik :)

Dalam sebuah primer tentang pengujian unit saya membaca pendekatan yang sama (langkah-langkah yang terlihat sangat, sangat kecil), dan sebagai jawaban untuk pertanyaan "seberapa kecil mereka seharusnya" sesuatu yang saya sukai, yang (diparafrasakan) seperti ini:

Ini tentang seberapa yakin Anda bahwa langkah-langkah itu berhasil. Anda dapat membuat langkah besar nyata jika Anda mau. Tapi, coba saja untuk beberapa waktu dan Anda akan menemukan banyak kepercayaan yang salah arah di tempat yang Anda anggap remeh. Jadi, tes ini membantu Anda membangun kepercayaan berbasis fakta.

Jadi, mungkin kolega Anda hanya pemalu :)

Bukankah seluruh poin bahwa implementasi metode ini tidak relevan, selama tes berhasil? Memperluas tes akan gagal lebih cepat dalam contoh kedua, tetapi dapat dibuat gagal dalam kedua kasus.

Saya setuju dengan orang-orang yang mengatakan bahwa tidak ada implementasi yang paling sederhana.

Alasan metodologi ini sangat ketat adalah karena mengharuskan Anda untuk menulis sebanyak mungkin tes yang relevan. Mengembalikan nilai konstan untuk satu test case dan menyebutnya lulus tidak apa-apa karena memaksa Anda untuk kembali dan menentukan apa yang benar-benar Anda inginkan untuk mendapatkan apa pun selain omong kosong dari program Anda. Menggunakan kasus sepele seperti menembak diri sendiri dalam beberapa hal, tetapi prinsipnya adalah bahwa kesalahan masuk ke dalam celah dalam spesifikasi Anda ketika Anda mencoba untuk melakukan 'terlalu banyak' dan merender persyaratan untuk implementasi paling sederhana yang memungkinkan memastikan bahwa Tes harus ditulis untuk setiap aspek perilaku unik yang Anda inginkan.