TDD: Apa yang terjadi sebelum unit test pertama?

Saya kebanyakan mengerti teori TDD, tapi saya tidak tahu bagaimana memulainya. Saya duduk untuk menulis tes unit untuk proyek pribadi dan menyadari. . . Saya tidak tahu apa yang saya uji. Objek apa, fungsi apa, dll.

Misalnya, katakanlah saya ingin menulis aplikasi untuk membantu keluarga kami mengelola tugas tugas. Berikut adalah beberapa pertanyaan dalam pikiran saya: Bagaimana saya beralih dari ide ini ke tes pertama saya? Berapa banyak yang harus diputuskan sebelum saya mulai, dan berapa banyak yang saya ketahui setelah saya mulai menulis tes? Kapan saya membuat keputusan seperti apakah akan menyimpan data dalam file teks atau database? Haruskah saya melakukan tes penerimaan pengguna sebelum memulai? Haruskah saya memiliki UI yang dirancang? Haruskah saya memiliki spec? (Saya menyadari setidaknya beberapa contoh pertanyaan ini mungkin berada di "area abu-abu").

Selain pertanyaan judul tentang mendapatkan tes unit pertama, bisakah Anda juga memberikan contoh seperti apa tes unit pertama untuk proyek seperti proyek sampel?

Saya suka memulai dengan daftar Fitur, dan untuk setiap Fitur tulis cerita pengguna, lalu untuk setiap cerita tulis deskripsi pengujian.

Pikirkan desainnya sebentar, lalu pilih deskripsi tes dan mulailah coding: red-green-refactor.

Ulangi sampai semua tes lulus.

Ya, tes penerimaan harus dianggap sebagai bagian dari ini, dilampirkan pada cerita yang sesuai.

Anda telah menemukan bagaimana TDD tentang Desain sejak awal. Sebelum Anda menulis tes pertama Anda, Anda harus berpikir tentang apa fungsi pertama Anda, dan seperti apa program Anda jika fungsi itu berfungsi.

Pengembang yang tidak menggunakan TDD juga harus memikirkan hal itu - tetapi mereka dapat "menyelami" dan mulai menulis sesuatu, apa saja. Tetapi "sesuatu, apa saja" tidak selalu berada di jalur menuju program yang Anda pikir akan Anda tulis. Apa yang? Nah, seperti apa program Anda jika bekerja? Tes apa yang akan lulus?

Saya ingin menulis aplikasi untuk membantu keluarga kami mengelola tugas-tugas rumah.

Keren. Jika aplikasi itu berfungsi, apa fungsinya? Nah, Tugas mungkin bisa ditugaskan untuk Orang, kan?

Person fred = new Person("fred")
Chore mow = new Chore("mow the lawn");
mow.assignTo(fred);
assertEquals(fred, mow.whoIsAssigned());

Ada awal. Bukan tempat yang harus Anda mulai, belum tentu tempat terbaik untuk memulai - tetapi ini adalah tempat. Ini adalah sesuatu yang Anda inginkan untuk didukung kode Anda (walaupun saya yakin Anda dapat menemukan nama yang lebih baik). Mulai dari sana, lihat itu gagal. Buat itu berlalu. Bersihkan. Busa, bilas, ulangi.

Ya, TDD memiliki masalah ini. Itu sebabnya saya sekarang merekomendasikan Bevenor Driven Development.

Mulai secara manual. Tuliskan sesuatu yang mirip dengan cerita pengguna:

• Sebagai pengguna
• Ketika saya memilih Tambah Ke Keranjang Belanja, saya ingin produk ditambahkan secara transparan di latar belakang
• Sehingga saya dapat melanjutkan pengalaman belanja saya tanpa gangguan

Sekarang apa saja fitur yang mendukung tujuan itu (bagian 'Jadi itu')?

• Ketika item ditambahkan ke keranjang belanja
  • Keranjang belanja untuk pengguna akan berisi item baru
  • Total barang dalam keranjang akan bertambah satu
  • Pengguna seharusnya tidak diarahkan
  • Opsi check out sekarang akan tersedia
• Ketika ada dua item di keranjang belanja dan pengguna memilih untuk check out
  • Pengguna akan diarahkan ke halaman check out
  • Kedua item akan terlihat

Ini adalah semua yang Anda bisa, dan harus diperiksa secara manual.

Lakukan ini sebentar. Kemudian, seperti pengembang yang baik, mulailah mencari cara untuk mengotomatisasi komponen yang berlebihan. Ini akan bervariasi tergantung pada apa platform Anda, tetapi sebagian besar memiliki kerangka kerja yang layak tersedia.

.Net memiliki WatiN untuk mengotomatisasi halaman web atau, jika Anda ingin menguji API, saya akan merekomendasikan penambahan Subspec ke xUnit atau MSpec (Anda juga dapat melakukan ini dengan kerangka pengujian apa pun, hanya yang membuatnya lebih mudah untuk menamai pengujian Anda dengan cara yang mendukung gaya berpikir ini).

Ruby memiliki mentimun untuk pengujian otomatisasi dan rspec untuk pengujian API tingkat rendah

Javascript memiliki melati dan qUnit.

titik titik titik

Bagaimana saya beralih dari ide ini ke tes pertama saya? Berapa banyak yang harus diputuskan sebelum saya mulai, dan berapa banyak yang saya ketahui setelah saya mulai menulis tes?

Hancurkan aplikasi Anda menjadi beberapa cerita seukuran gigitan. ("Sebagai pengguna, saya ingin mengklik dua kali pada ikon dan meluncurkan program." Atau "Sebagai pengguna, saya ingin membuka browser saya dan pergi ke program." Terserah.)

Kemudian uraikan cerita menjadi beberapa tugas. (mis. Buat proyek di Eclipse, atur repositori kode) Saat Anda mendapatkan tugas pengkodean, tulis tes pertama Anda.

Kapan saya membuat keputusan seperti apakah akan menyimpan data dalam file teks atau database?

Jika Anda tidak yakin, pilih yang mana yang tampak lebih sederhana dan lakukan itu. (mungkin file teks) Jika Anda menyadari Anda telah melakukan kesalahan, refactor. Jika tes Anda terstruktur dengan baik, Anda harus dapat membuat perubahan ujung belakang dan menangkap efek samping yang tidak diinginkan yang muncul.

Saya terkejut bahwa tidak ada jawaban yang berisi menyebutkan hal aktual yang Anda lakukan tepat sebelum menulis tes pertama Anda, yaitu membuat daftar tes . Daftar tes diinformasikan oleh fase penulisan cerita dan desain yang disebutkan dalam jawaban lain dan merupakan pendahulu langsung untuk menulis tes yang tampaknya Anda cari.

Untuk informasi lebih lanjut tentang TDD, saya akan merekomendasikan Test Driven Development By Example oleh Kent Beck. Dia juga memiliki screencast TDD yang mengikuti pengembangan perpustakaan non-sepele dalam gaya TDD murni dengan penjelasan oleh Kent pada setiap langkah dalam proses. Saya pikir ini adalah contoh yang bagus dari TDD dalam praktek, bahkan jika itu (karena kebutuhan) dilakukan dalam lingkungan yang dibuat-buat.

Sebelum tes unit pertama Anda berpikir tentang apa yang Anda inginkan terjadi dan kemudian berpikir tentang bagaimana Anda akan mengujinya. Kemudian tulis tes itu, lihat gagal dan terapkan beberapa kode untuk membuatnya lulus.

Bilas, ulangi, dll.

Bagi saya, pemikiran tentang bagaimana Anda akan mengujinya sedikit yang penting dan itulah yang dapat mendorong desain Anda.