Dalam TDD saya harus menulis Test terlebih dahulu atau Interface dulu?

Saya belajar TDD menggunakan c #, sejauh yang saya tahu tes harus mendorong pengembangan , yaitu pertama - tama menulis tes gagal setelah menulis kode minimum untuk lulus tes kemudian melakukan refactoring.

Tetapi dikatakan juga bahwa " Program ke Antarmuka, bukan Implementasi ", jadi tulislah antarmuka terlebih dahulu . Di sinilah kebingungan saya dimulai, Jika saya menulis Antarmuka terlebih dahulu maka itu melanggar dua hal

1. Kode yang ditulis untuk antarmuka tidak didorong oleh tes .

2. Ini bukan minimum yang jelas saya bisa menulisnya dengan kelas sederhana.

Haruskah saya mulai dengan menulis tes untuk antarmuka juga? tanpa implementasi apa yang akan saya uji?

Jika pertanyaan ini terdengar konyol, maaf, tapi saya benar-benar bingung. Mungkin saya mengambil hal-hal yang terlalu harfiah.

Pelanggaran pertama Anda ("Kode yang ditulis untuk antarmuka tidak didorong oleh tes.") Tidak valid. Mari kita gunakan contoh sepele. Misalkan Anda sedang menulis kelas kalkulator, dan Anda sedang menulis operasi tambahan. Tes apa yang mungkin Anda tulis?

public class CalculatorTest {
    @Test
    public void testAddTwoIntegers() {
        Calculator calc = new Calculator();
        int result = calc.add(2, 2)
        Assert.assertEquals(4, result);
    }
}

Tes Anda baru saja mendefinisikan antarmuka. Ini addmetodenya, lihat? addmengambil dua argumen dan mengembalikan jumlah mereka. Anda nanti dapat menentukan bahwa Anda memerlukan beberapa Kalkulator, dan mengekstrak antarmuka Java (dalam hal ini) pada waktu itu. Tes Anda seharusnya tidak berubah, karena Anda menguji antarmuka publik dari kelas itu.

Pada tingkat yang lebih teoretis, pengujian adalah spesifikasi yang dapat dieksekusi untuk suatu sistem. Antarmuka ke sistem harus didorong oleh pengguna sistem itu, dan tes adalah metode pertama yang harus Anda tetapkan interaksi.

Saya tidak berpikir Anda dapat memisahkan desain antarmuka dari desain tes. Menentukan interaksi dan merancang tes untuk mereka adalah operasi mental yang sama - ketika saya mengirim informasi ini ke antarmuka, saya mengharapkan hasil tertentu. Ketika ada sesuatu yang salah dengan input saya, saya mengharapkan kesalahan ini. Anda dapat melakukan pekerjaan desain ini di atas kertas dan kemudian menulis tes Anda dari itu, atau Anda dapat melakukannya pada saat yang sama - tidak masalah.

Apa yang kita lakukan saat menulis interface? Apakah kita menulis kode, atau sedang merancang?

Saya bukan penggemar gagasan Test Driven Design, tapi saya suka Test Driven Development . Secara pribadi, saya mendapatkan hasil terbaik ketika merancang kelas di muka dengan mendesain antarmuka sebelum menulis tes. Saya tidak menghitung antarmuka sebagai kode. Antarmuka adalah desain yang akan saya implementasikan menggunakan TDD. Ini sepertinya akan mengubah sebuah evolusi saat saya bekerja, tetapi ini adalah peta jalan saya (bersama dengan daftar tes saya).

Saya akan berhenti sebelum saya mulai berteriak-teriak, tetapi mudah-mudahan itu cara yang bermanfaat bagi Anda untuk memikirkannya.

Dalam TDD saya harus menulis Test terlebih dahulu atau Interface dulu?

Itu semua tergantung pada seberapa ortodoks / religius Anda ingin melakukan TDD .

Saya sedang belajar TDD

Karena Anda sedang belajar, Anda harus bereksperimen untuk mendapatkan alur kerja pribadi, yang cocok untuk Anda.

1. Jika Anda ingin melakukannya sesuai dengan buku , Anda menulis pada awalnya tes, yang jelas akan gagal, karena Anda mulai tanpa kode sama sekali. Kemudian Anda menulis beberapa kode untuk lulus ujian. Jika itu dilakukan, Anda bebas untuk refactor kode yang ada, karena Anda memiliki tes yang menyediakan semacam jaring pengaman untuk refactor. Memutuskan untuk menggunakan Antarmuka adalah semacam refactoring.

2. Selain TDD atau tidak: Pertanyaannya, apakah menggunakan antarmuka atau tidak tidak menarik pada awalnya. Tentu saja jika Anda yakin, Anda memiliki perilaku berbeda yang ingin Anda sebarkan ke beberapa objek, masuk akal untuk berpikir tentang menggunakan Antarmuka: Misalnya, jika Anda memiliki semacam output ke tujuan yang berbeda, masuk akal untuk mengimplementasikannya melalui Writer antarmuka dan memiliki kelas yang berbeda untuk output ( FileWriter , Printer dll.) Meskipun itu adalah pepatah umum untuk menulis ke sebuah antarmuka , tetapi itu tidak berarti: gunakan antarmuka untuk semuanya . Terkadang itu satu tingkat tipuan untuk banyak. Btw. hal yang sama berlaku untuk layanan. Tapi itu topik yang berbeda.

3. Di sisi lain, Anda dapat mengembangkan tes didorong dengan cara lain: rancang kode Anda untuk testabilitas. Yang berarti, Anda menulis kode, yang mudah untuk diuji - meskipun Anda menulis tes sesudahnya . Tidak masalah jika Anda menulis tes sebelumnya atau sesudahnya, selama Anda melakukan tes.

TDD atau BDD berarti Melakukan antarmuka domain Anda terlebih dahulu dan kemudian menulis tes terhadap mereka dengan interpretasi saya. implementasi antarmuka memiliki perilaku yang diharapkan.

itu masih menguji sebelum kode karena suatu antarmuka tidak mengandung logika yang dapat diuji itu adalah struktur yang Anda tulis untuk diuji.

Saya Akan Melakukannya sebagai berikut

1. Tulis Perilaku Semi Formal (Diberikan: Kapan: Lalu :)

2. Tulis Antarmuka (untuk meng-host metode pengkodean perilaku)

3. Tulis Tes yang Diidentifikasi (masukan yang diberikan, panggil kapan, uji kemudian)

4. Tulis / Ubah Beton (Kelas yang mengimplementasikan antarmuka) untuk Lulus Tes

Jangan pernah menulis tes sebelum Anda mendesain antarmuka. Ketika Anda berpikir tentang jenis tes apa yang harus ditulis (desain tes) Anda tidak harus secara bersamaan merancang (merancang) aplikasi Anda. Jangan memikirkan dua hal sekaligus. Pernahkah Anda mendengar tentang pemisahan kekhawatiran? Ini berlaku tidak hanya untuk struktur fisik kode Anda tetapi juga untuk proses berpikir Anda.

Putuskan bagaimana aplikasi Anda harus dirancang terlebih dahulu. Ini berarti Anda mendesain antarmuka dan hubungan antar antarmuka ini. Sampai Anda selesai melakukan ini, Anda sebaiknya tidak mulai memikirkan tes. Setelah Anda tahu apa antarmuka Anda maka Anda dapat terlebih dahulu membuat mereka dan kemudian menulis tes terhadap mereka atau menulis tes pertama dan kemudian membuatnya. Dalam kasus terakhir jelas Anda tidak akan dapat mengkompilasi tes. Saya tidak melihat ada salahnya atau pelanggaran filosofi TDD dalam menciptakan antarmuka sebelum tes.

Tidak apa-apa untuk menulis antarmuka / kode / tes pada saat yang sama selama penggabungan mereka ke dalam proyek adalah atom.

Kecuali jika bos Anda religius dengan TDD, dalam hal ini Anda mungkin harus menulis antarmuka kosong -> tes -> kode minimal (langkah tanpa titik) -> lebih banyak tes -> lebih banyak kode tanpa titik -> lebih banyak tes -> akhirnya tulis kode sebenarnya - > selesai.