Kapan Anda menulis kode "nyata" dalam TDD?

johnny 08/19/2017. 11 answers, 20.464 views
tdd

Semua contoh yang saya baca dan lihat di video pelatihan memiliki contoh yang sederhana. Tetapi apa yang tidak saya lihat jika bagaimana saya melakukan kode "asli" setelah saya mendapatkan warna hijau. Apakah ini bagian "Refactor"?

Jika saya memiliki objek yang cukup kompleks dengan metode yang kompleks, dan saya menulis tes saya dan minimal untuk membuatnya lulus (setelah gagal pertama kali, Red). Kapan saya kembali dan menulis kode yang sebenarnya? Dan berapa banyak kode sebenarnya yang saya tulis sebelum saya tes ulang? Saya menduga yang terakhir lebih intuisi.

Edit: Terima kasih untuk semua yang menjawab. Semua jawaban Anda sangat membantu saya. Sepertinya ada ide yang berbeda tentang apa yang saya tanyakan atau bingung, dan mungkin ada, tetapi yang saya tanyakan adalah, katakanlah saya memiliki aplikasi untuk membangun sekolah.

Dalam desain saya, saya memiliki arsitektur yang ingin saya mulai dengan, Cerita Pengguna, seterusnya dan seterusnya. Dari sini, saya mengambil Cerita Pengguna tersebut, dan saya membuat tes untuk menguji Kisah Pengguna. Pengguna mengatakan, Kami memiliki orang yang mendaftar ke sekolah dan membayar biaya pendaftaran. Jadi, saya memikirkan cara untuk membuat itu gagal. Dengan demikian saya merancang kelas Tes untuk kelas X (mungkin Siswa), yang akan gagal. Saya kemudian membuat kelas "Pelajar." Mungkin "Sekolah" saya tidak tahu.

Tapi, dalam hal apapun, Design TD memaksa saya untuk memikirkan ceritanya. Jika saya bisa membuat tes gagal, saya tahu mengapa itu gagal, tetapi ini mengandaikan saya bisa berhasil lulus. Ini tentang perancangannya.

Saya menyamakan ini dengan berpikir tentang Rekursi. Rekursi bukanlah konsep yang sulit. Mungkin lebih sulit untuk benar-benar melacaknya di kepala Anda, tetapi dalam kenyataannya, bagian yang paling sulit adalah mengetahui, ketika rekursi "istirahat," kapan harus berhenti (pendapat saya, tentu saja.) Jadi saya harus memikirkan apa yang berhenti Rekursi pertama. Ini hanyalah analogi yang tidak sempurna, dan mengasumsikan bahwa setiap iterasi rekursif adalah "celah". Sekali lagi, hanya pendapat saja.

Dalam implementasinya, sekolah lebih sulit dilihat. Buku besar numerik dan bank adalah "mudah" dalam arti Anda dapat menggunakan aritmatika sederhana. Saya dapat melihat + b dan mengembalikan 0, dll. Dalam kasus sistem orang, saya harus berpikir lebih keras tentang bagaimana implement . Saya memiliki konsep gagal, lulus, refactor (kebanyakan karena belajar dan pertanyaan ini.)

Apa yang saya tidak tahu didasarkan pada kurangnya pengalaman, menurut saya. Saya tidak tahu bagaimana gagal mendaftarkan siswa baru. Saya tidak tahu bagaimana gagal seseorang mengetikkan nama belakang dan itu disimpan ke database. Saya tahu cara membuat + 1 untuk matematika sederhana, tetapi dengan entitas seperti seseorang, saya tidak tahu apakah saya hanya menguji untuk melihat apakah saya mendapatkan kembali ID unik basis data atau sesuatu yang lain ketika seseorang memasukkan nama dalam database atau keduanya atau tidak.

Atau, mungkin ini menunjukkan saya masih bingung.

5 Comments
187 hobbs 07/25/2017
Setelah orang-orang TDD pulang untuk malam.
14 Goyo 07/25/2017
Menurut Anda, mengapa kode yang Anda tulis tidak nyata?
2 johnny 07/26/2017
@RubberDuck Lebih dari jawaban yang lain. Saya yakin saya akan segera mengacunya. Itu masih agak asing, tapi saya tidak akan menyerah. Apa yang kamu katakan masuk akal. Saya hanya mencoba membuatnya masuk akal dalam konteks saya atau aplikasi bisnis biasa. Mungkin sistem persediaan atau sejenisnya. Saya harus mempertimbangkannya. Saya bersyukur atas waktu Anda. Terima kasih.
1 Edmund Reed 07/26/2017
Jawabannya sudah mengenai paku di kepala, tetapi selama semua tes Anda berlalu, dan Anda tidak memerlukan tes / fungsionalitas baru, dapat diasumsikan kode yang Anda miliki sudah selesai, bar linting.
3 Borjab 07/26/2017
Ada asumsi dalam pertanyaan yang mungkin bermasalah dalam "Saya memiliki objek yang cukup kompleks dengan metode yang kompleks". Dalam TDD Anda menulis tes Anda terlebih dahulu sehingga Anda mulai dengan kode yang cukup sederhana. Ini akan memaksa Anda untuk mengkodekan struktur yang mudah diuji yang perlu menjadi modular. Perilaku yang begitu kompleks akan dibuat dengan menggabungkan objek yang lebih sederhana. Jika Anda mengakhiri dengan objek atau metode yang cukup kompleks maka adalah ketika Anda refactor

11 Answers


RubberDuck 07/27/2017.

Jika saya memiliki objek yang cukup kompleks dengan metode yang kompleks, dan saya menulis tes saya dan minimal untuk membuatnya lulus (setelah gagal pertama kali, Red). Kapan saya kembali dan menulis kode yang sebenarnya? Dan berapa banyak kode sebenarnya yang saya tulis sebelum saya tes ulang? Saya menduga yang terakhir lebih intuisi.

Anda tidak "kembali" dan menulis "kode asli". Ini semua kode asli. Apa yang Anda lakukan adalah kembali dan tambahkan tes lain yang forces Anda untuk change kode Anda agar lulus tes baru.

Adapun berapa banyak kode yang Anda tulis sebelum Anda menguji ulang? Tidak ada. Anda menulis kode zero tanpa tes gagal yang forces Anda untuk menulis lebih banyak kode.

Perhatikan polanya?

Mari kita telusuri contoh lain (yang sederhana) dengan harapan bahwa itu membantu.

 Assert.Equal("1", FizzBuzz(1)); 

Mudah mudah.

 public String FizzBuzz(int n) {
    return 1.ToString();
} 

Bukan apa yang Anda sebut kode asli, bukan? Mari tambahkan tes yang memaksa perubahan.

 Assert.Equal("2", FizzBuzz(2)); 

Kita bisa melakukan sesuatu yang konyol seperti if n == 1 , tetapi kita akan melompat ke solusi yang waras.

 public String FizzBuzz(int n) {
    return n.ToString();
} 

Keren. Ini akan berfungsi untuk semua nomor non-FizzBuzz. Apa masukan selanjutnya yang akan memaksa kode produksi berubah?

 Assert.Equal("Fizz", FizzBuzz(3));

public String FizzBuzz(int n) {
    if (n == 3)
        return "Fizz";
    return n.ToString();
} 

Dan lagi. Tulis tes yang belum lulus.

 Assert.Equal("Fizz", FizzBuzz(6));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    return n.ToString();
} 

Dan kita sekarang telah mencakup semua kelipatan tiga (yang tidak juga kelipatan lima, kami akan mencatatnya dan kembali).

Kami belum menulis tes untuk "Buzz", jadi mari tulis itu.

 Assert.Equal("Buzz", FizzBuzz(5));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n == 5)
        return "Buzz"
    return n.ToString();
} 

Dan lagi, kita tahu ada kasus lain yang perlu kita tangani.

 Assert.Equal("Buzz", FizzBuzz(10));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n % 5 == 0)
        return "Buzz"
    return n.ToString();
} 

Dan sekarang kita bisa menangani semua kelipatan 5 yang juga bukan kelipatan 3.

Sampai saat ini, kami telah mengabaikan langkah refactoring, tetapi saya melihat beberapa duplikasi. Mari bersihkan itu sekarang.

 private bool isDivisibleBy(int divisor, int input) {
    return (input % divisor == 0);
}

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
} 

Keren. Sekarang kami telah menghapus duplikasinya dan membuat fungsi bernama baik. Apa tes selanjutnya yang bisa kita tulis yang akan memaksa kita untuk mengubah kode? Nah, kami telah menghindari kasus di mana jumlahnya terbagi oleh 3 dan 5. Mari menulisnya sekarang.

 Assert.Equal("FizzBuzz", FizzBuzz(15));

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n) && isDivisibleBy(5, n))
        return "FizzBuzz";
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
} 

Tes lulus, tetapi kami memiliki lebih banyak duplikasi. Kami memiliki opsi, tetapi saya akan menerapkan "Ekstrak Variabel Lokal" beberapa kali sehingga kami melakukan refactoring alih-alih menulis ulang.

 public String FizzBuzz(int n) {

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
} 

Dan kami telah mencakup setiap masukan yang masuk akal, tetapi bagaimana dengan masukan yang unreasonable ? Apa yang terjadi jika kita melewati 0 atau negatif? Tuliskan kasus uji tersebut.

 public String FizzBuzz(int n) {

    if (n < 1)
        throw new InvalidArgException("n must be >= 1);

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
} 

Apakah ini mulai terlihat seperti "kode sebenarnya"? Lebih penting lagi, pada titik mana ia berhenti menjadi "kode tidak nyata" dan bertransisi menjadi "nyata"? Itu sesuatu yang perlu dipikirkan ...

Jadi, saya bisa melakukan ini hanya dengan mencari tes yang saya tahu tidak akan lulus pada setiap langkah, tetapi saya sudah banyak berlatih. Ketika saya sedang bekerja, segala sesuatunya tidak semudah ini dan saya mungkin tidak selalu tahu tes apa yang akan memaksa perubahan. Kadang-kadang saya akan menulis tes dan terkejut melihat itu sudah berlalu! Saya sangat menyarankan Anda untuk terbiasa membuat "Daftar Uji" sebelum Anda memulai. Daftar tes ini harus berisi semua masukan "menarik" yang dapat Anda pikirkan. Anda mungkin tidak menggunakan semuanya dan kemungkinan Anda akan menambahkan kasus saat Anda pergi, tetapi daftar ini berfungsi sebagai peta jalan. Daftar pengujian saya untuk FizzBuzz akan terlihat seperti ini.

  • Negatif
  • Nol
  • Satu
  • Dua
  • Tiga
  • Empat
  • Lima
  • Enam (kelipatan tidak sepele dari 3)
  • Sembilan (3 kuadrat)
  • Sepuluh (kelipatan tidak sepele dari 5)
  • 15 (kelipatan 3 & 5)
  • 30 (bukan kelipatan sepele dari 3 & 5)
5 comments
3 maple_shaft♦ 07/27/2017
Komentar bukan untuk diskusi panjang; percakapan ini telah dipindahkan ke obrolan .
40 GManNickG 07/27/2017
Kecuali saya benar-benar salah memahami jawaban ini: "Kita bisa melakukan sesuatu yang konyol seperti jika n == 1, tetapi kita akan melompat ke solusi yang waras." - semuanya konyol. Jika Anda tahu di depan Anda menginginkan fungsi yang melakukan <spec>, tuliskan pengujian untuk <spec> dan lewati bagian di mana Anda menulis versi yang jelas-jelas gagal <spec>. Jika Anda menemukan bug di <spec> maka yakin: tuliskan tes terlebih dahulu untuk memverifikasi bahwa Anda dapat melatihnya sebelum memperbaiki dan mengamati lintasan uji setelah perbaikan. Tapi tidak perlu memalsukan semua langkah menengah ini.
15 user3791372 07/28/2017
Komentar yang menunjukkan kekurangan utama dalam jawaban ini dan TDD secara umum telah dipindahkan ke obrolan. Jika Anda mempertimbangkan untuk menggunakan TDD, silakan baca 'obrolan'. Sayangnya komentar 'kualitas' kini tersembunyi di antara banyak obrolan untuk dibaca oleh para siswa di masa depan.
nbro 07/28/2017
Saya akan lebih tepat mengenai isi "daftar uji" ini, jika Anda ingin memperbaiki jawaban ini. Saya akan secara eksplisit berbicara tentang "nilai-nilai batas" dan "partisi kelas".
2 hvd 07/30/2017
@GManNickG Saya percaya intinya adalah untuk mendapatkan jumlah tes yang tepat. Menulis tes terlebih dahulu membuatnya mudah untuk melewatkan kasus-kasus khusus apa yang harus diuji, yang mengarah ke situasi yang tidak tercakup secara memadai dalam tes, atau pada dasarnya situasi yang sama yang tanpa banyak hal telah dilalui banyak kali dalam tes. Jika Anda dapat melakukannya tanpa langkah-langkah lanjutan ini, bagus! Namun, tidak semua orang bisa melakukannya, itu adalah sesuatu yang perlu latihan.

GenericJon 07/24/2017.

Kode "asli" adalah kode yang Anda tulis untuk lulus tes. Really . Sesederhana itu.

Ketika orang berbicara tentang menulis minimal untuk membuat tes hijau, itu hanya berarti bahwa kode asli Anda harus mengikuti prinsip YAGNI .

Ide langkah refactor hanya untuk membersihkan apa yang telah Anda tulis setelah Anda senang bahwa itu memenuhi persyaratan.

Selama tes yang Anda tulis benar-benar mencakup persyaratan produk Anda, begitu mereka melewati maka kode selesai. Pikirkanlah, jika semua persyaratan bisnis Anda memiliki pengujian dan semua tes tersebut berwarna hijau, apa lagi yang harus ditulis? (Oke, dalam kehidupan nyata kita tidak cenderung memiliki cakupan tes yang lengkap, tetapi teorinya adalah suara.)

5 comments
44 Derek Elkins 07/24/2017
Tes unit tidak dapat benar-benar mencakup persyaratan produk Anda bahkan untuk persyaratan yang relatif sepele. Paling baik, mereka mencicipi ruang input-output dan idenya adalah bahwa Anda (dengan benar) menggeneralisasi ke ruang input-output penuh. Tentu saja, kode Anda bisa menjadi switch besar dengan kasus untuk setiap tes unit yang akan lulus semua tes dan gagal untuk input lainnya.
8 Taemyr 07/25/2017
@DerekElkins TDD mengamanatkan pengujian yang gagal. Tidak gagal dalam tes unit.
6 jonrsharpe 07/25/2017
@DerekElkins itulah mengapa Anda tidak hanya menulis tes unit, dan juga mengapa ada anggapan umum bahwa Anda mencoba membuat sesuatu bukan hanya memalsukannya!
35 Derek Elkins 07/25/2017
@jonrsharpe Dengan logika itu, saya tidak akan pernah menulis implementasi sepele. Misalnya dalam contoh FizzBuzz dalam jawaban RubberDuck (yang hanya menggunakan tes unit), implementasi pertama jelas "hanya memalsukannya". Pemahaman saya tentang pertanyaan adalah persis dikotomi antara menulis kode yang Anda tahu tidak lengkap dan kode yang benar-benar Anda yakini akan mengimplementasikan persyaratan, "kode asli". " switch besar" saya dimaksudkan sebagai ekstrem logis "menulis minimal untuk membuat tes menjadi hijau". Saya melihat pertanyaan OP sebagai: di mana TDD adalah prinsip yang menghindari switch besar ini?
2 Luaan 07/25/2017
@GenericJon Itu agak terlalu optimis dalam pengalaman saya :) Untuk satu, ada orang-orang yang menikmati pekerjaan berulang yang tak beralasan. Mereka akan lebih bahagia dengan pernyataan switch raksasa daripada dengan "pembuatan keputusan yang rumit". Dan kehilangan pekerjaan mereka, mereka akan membutuhkan seseorang yang memanggil mereka pada teknik (dan mereka lebih baik memiliki bukti yang baik itu benar-benar kehilangan peluang / uang perusahaan!), Atau melakukan sangat buruk. Setelah mengambil alih pemeliharaan pada banyak proyek seperti itu, saya dapat mengatakan bahwa kode mudah sekali sangat naif untuk bertahan selama beberapa dekade, selama itu membuat pelanggan senang (dan membayar).

Carl Raymond 07/24/2017.

Jawaban singkatnya adalah bahwa "kode asli" adalah kode yang membuat lulus tes. Jika Anda dapat lulus tes dengan sesuatu selain kode asli, tambahkan lebih banyak tes!

Saya setuju bahwa banyak tutorial tentang TDD sederhana. Itu berhasil melawan mereka. Tes yang terlalu sederhana untuk metode yang, katakanlah, menghitung 3 + 8 benar-benar tidak memiliki pilihan selain juga menghitung 3 + 8 dan membandingkan hasilnya. Itu membuatnya tampak seperti Anda hanya akan menduplikasi seluruh kode, dan pengujian itu tidak ada gunanya, pekerjaan ekstra yang rawan kesalahan.

Ketika Anda pandai menguji, itu akan menginformasikan bagaimana Anda menyusun aplikasi Anda, dan bagaimana Anda menulis kode Anda. Jika Anda kesulitan datang dengan tes yang masuk akal dan membantu, Anda mungkin harus berpikir ulang tentang desain Anda. Sistem yang dirancang dengan baik mudah untuk diuji - artinya tes yang masuk akal mudah dipikirkan, dan diimplementasikan.

Ketika Anda menulis tes Anda terlebih dahulu, melihat mereka gagal, dan kemudian menulis kode yang membuat mereka lulus, itu adalah disiplin untuk memastikan bahwa semua kode Anda memiliki tes yang sesuai. Saya tidak membudak mengikuti aturan itu ketika saya coding; sering saya menulis tes setelah fakta. Tetapi melakukan tes pertama membantu Anda tetap jujur. Dengan beberapa pengalaman, Anda akan mulai memperhatikan saat Anda membuat kode sendiri, bahkan ketika Anda tidak menulis tes terlebih dahulu.

4 comments
6 Steve Jessop 07/26/2017
Secara pribadi, tes yang akan saya tulis adalah assertEqual(plus(3,8), 11) , bukan assertEqual(plus(3,8), my_test_implementation_of_addition(3,8)) . Untuk kasus yang lebih kompleks, Anda selalu mencari cara untuk membuktikan hasil yang benar, other than secara dinamis menghitung hasil yang benar dalam pengujian dan memeriksa kesetaraan.
Steve Jessop 07/26/2017
Jadi untuk cara yang benar-benar konyol dalam melakukannya untuk contoh ini, Anda dapat membuktikan bahwa plus(3,8) telah mengembalikan hasil yang benar dengan mengurangi 3 dari itu, mengurangi 8 dari itu, dan memeriksa hasilnya terhadap 0. Ini sangat jelas setara dengan assertEqual(plus(3,8), 3+8) menjadi sedikit tidak masuk akal, tetapi jika kode yang diuji membangun sesuatu yang lebih rumit daripada hanya integer, kemudian mengambil hasil dan memeriksa setiap bagian untuk kebenaran sering pendekatan yang tepat. Atau, sesuatu seperti for (i=0, j=10; i < 10; ++i, ++j) assertEqual(plus(i, 10), j)
Steve Jessop 07/26/2017
... karena itu menghindari rasa takut yang besar, yaitu ketika menulis tes, kami akan membuat kesalahan yang sama pada subjek "bagaimana cara menambahkan 10" yang kami buat dalam kode langsung. Jadi, pengujian dengan hati-hati menghindari penulisan kode apa pun yang menambahkan 10 pada apa pun, dalam pengujian bahwa plus() dapat menambah 10 hal. Kami masih mengandalkan nilai loop awal yang diprogram programmer, tentu saja.
3 Warbo 07/28/2017
Hanya ingin menunjukkan bahwa bahkan jika Anda menulis tes setelah fakta, itu masih ide yang baik untuk melihat mereka gagal; temukan beberapa bagian dari kode yang tampaknya penting untuk apa pun yang sedang Anda kerjakan, sesuaikan sedikit (misalnya ganti + dengan -, atau apa pun), jalankan pengujian dan saksikan mereka gagal, batalkan perubahan dan perhatikan mereka lulus. Banyak kali saya melakukan tes ini tidak benar-benar gagal, membuatnya lebih buruk daripada tidak berguna: tidak hanya tidak menguji apa pun, itu memberi saya keyakinan palsu bahwa ada sesuatu yang sedang diuji!

Victor Cejudo 07/25/2017.

Terkadang beberapa contoh tentang TDD dapat menyesatkan. Seperti yang orang lain tunjukkan sebelumnya, kode yang Anda tulis untuk membuat tes lulus adalah kode yang sebenarnya.

Tapi jangan berpikir bahwa kode yang sebenarnya muncul seperti sihir - itu salah. Anda perlu pemahaman yang lebih baik tentang apa yang ingin Anda capai dan kemudian Anda harus memilih tes yang sesuai, mulai dari kasus termudah dan kasus sudut.

Misalnya, jika Anda perlu menulis lexer, Anda mulai dengan string kosong, kemudian dengan sekelompok spasi putih, lalu angka, lalu dengan nomor yang dikelilingi oleh spasi putih, lalu nomor yang salah, dll. Transformasi kecil ini akan mengarahkan Anda ke algoritma yang tepat, tetapi Anda tidak melompat dari kasus termudah ke kasus yang sangat rumit yang dipilih dengan bodoh untuk mendapatkan kode yang sebenarnya dilakukan.

Bob Martin menjelaskannya dengan sempurna di sini .


CandiedOrange 07/25/2017.

Bagian refactor bersih ketika Anda lelah dan ingin pulang.

Ketika Anda akan menambahkan fitur bagian refactor adalah apa yang Anda ubah sebelum tes berikutnya. Anda mem-refactor kode untuk memberi ruang bagi fitur baru. Anda melakukan ini ketika Anda know apa fitur baru itu nantinya. Tidak ketika Anda hanya membayangkannya.

Ini bisa sesederhana mengubah nama GreetImpl menjadi GreetWorld sebelum Anda membuat kelas GreetMom (setelah menambahkan tes) untuk menambahkan fitur yang akan mencetak "Hai Mom".


graeme 07/27/2017.

Tetapi kode sebenarnya akan muncul di tahap refactor fase TDD. Yakni kode yang harus menjadi bagian dari rilis final.

Tes harus dijalankan setiap kali Anda membuat perubahan.

Moto siklus hidup TDD adalah: RED GREEN REFACTOR

RED : Tulis tes

GREEN : Buatlah upaya yang jujur ​​untuk mendapatkan kode fungsional yang lolos tes secepat mungkin: kode duplikat, variabel yang dinamai dengan jelas dari urutan tertinggi, dll.

REFACTOR : Bersihkan kode, REFACTOR nama variabel dengan tepat. KERINGKAN kode.

5 comments
5 mcottle 07/25/2017
Saya tahu apa yang Anda katakan tentang fase "Hijau" tetapi ini menyiratkan bahwa nilai pengembalian kabel yang sulit untuk membuat tes lulus mungkin tepat. Dalam pengalaman saya, "Hijau" seharusnya merupakan upaya yang jujur ​​untuk membuat kode kerja untuk memenuhi persyaratan, itu mungkin tidak sempurna tetapi harus selengkap dan "dapat dipatahkan" karena pengembang dapat mengelola dalam lulus pertama. Refactoring mungkin paling baik dilakukan beberapa waktu kemudian setelah Anda melakukan pengembangan lebih lanjut dan masalah dengan lulus pertama menjadi lebih jelas dan peluang untuk KERING muncul.
graeme 07/25/2017
@mcottle saya menganggap ini semua bagian dari tugas yang sama. selesaikan, lalu bersihkan. Lebih lanjut refactorings harus berlangsung seiring waktu sebagai bagian dari tugas-tugas lainnya.
1 Bryan Boettcher 07/25/2017
@mcottle: Anda mungkin terkejut berapa banyak implementasi dari repositori get-only yang dapat menjadi nilai hardcoding dalam basis kode. :)
6 Kaz 07/25/2017
Mengapa saya harus menulis kode sampah dan membersihkannya, ketika saya bisa membuat kode kualitas produksi yang bagus secepat yang bisa saya ketik? :)
1 Kaz 07/27/2017
@TimothyTruckle Bagaimana jika membutuhkan waktu 50 menit untuk menemukan perubahan sederhan mungkin, tetapi hanya 5 untuk menemukan perubahan kedua yang paling sederhana? Apakah kita pergi dengan yang paling sederhana atau tetap mencari yang paling sederhana?

Timothy Truckle 07/27/2017.

Kapan Anda menulis kode "nyata" dalam TDD?

Fase red adalah tempat Anda write kode.

Pada fase refactoring , tujuan utamanya adalah delete kode.

Dalam fase red Anda melakukan apa saja untuk lulus tes as quick as possible dan at any cost . Anda benar-benar mengabaikan apa yang pernah Anda dengar tentang praktik pengkodean yang baik atau pola desain yang sama. Membuat tes hijau adalah yang terpenting.

Dalam fase refactoring Anda membersihkan kekacauan yang baru saja Anda buat. Sekarang Anda pertama-tama melihat apakah perubahan yang baru saja Anda buat adalah jenis paling atas dalam daftar Prioritas Transformasi dan jika ada duplikasi kode Anda dapat menghapus kemungkinan besar dengan menerapkan derai desain.

Akhirnya Anda meningkatkan keterbacaan dengan mengganti nama pengidentifikasi dan mengekstrak magic numbers dan / atau string literal ke konstanta.


Itu bukan red-refactor, itu refactor hijau-merah. - Rob Kinyon

Terima kasih telah menunjukkan ini.

Jadi itu adalah fase green mana Anda menulis real code

Dalam fase red Anda menulis executable specification ...

2 comments
Rob Kinyon 07/27/2017
Itu bukan red-refactor, itu refactor hijau-merah. The "merah" adalah Anda mengambil suite uji Anda dari hijau (semua tes lulus) menjadi merah (satu tes gagal). The "hijau" adalah di mana Anda sembarangan mengambil tes Anda dari merah (satu tes gagal) ke hijau (semua tes lulus). The "refactor" adalah tempat Anda mengambil kode Anda dan membuatnya cantik sambil menjaga semua tes berlalu.
Timothy Truckle 07/27/2017
@RobKinyon Terima kasih, perbarui jawabannya.

Robert Andrzejuk 07/27/2017.

Anda menulis Real Code sepanjang waktu.

Pada setiap langkah Anda menulis kode untuk memenuhi persyaratan yang akan dipenuhi kode Anda untuk penelepon selanjutnya dari kode Anda (yang mungkin Anda atau bukan ...).

Anda pikir Anda tidak menulis kode yang berguna ( real ), karena suatu saat Anda dapat mem-refactornya.

Refactoring Kode adalah proses restrukturisasi kode komputer yang ada — mengubah faktorisasi — tanpa mengubah perilaku eksternal.

Apa artinya ini adalah bahwa meskipun Anda mengubah kode, kondisi kode terpenuhi, dibiarkan tidak berubah. Dan pemeriksaan ( tests ) Anda mengimplementasikan untuk memverifikasi Kode Anda sudah ada di sana untuk memverifikasi apakah modifikasi Anda mengubah apa pun. Jadi kode yang Anda tulis sepanjang waktu ada di sana, hanya dengan cara yang berbeda.

Alasan lain Anda mungkin berpikir bahwa itu bukan kode sebenarnya, adalah bahwa Anda sedang melakukan contoh di mana program akhir sudah bisa dilihat sebelumnya oleh Anda. Ini sangat bagus, karena menunjukkan Anda memiliki pengetahuan tentang domain Anda program.
Tetapi banyak kali programmer berada dalam domain yang new , unknown oleh mereka. Mereka tidak tahu apa hasil akhirnya dan TDD adalah technique untuk menulis program selangkah demi selangkah, mendokumentasikan knowledge kita tentang bagaimana sistem ini harus bekerja dan memverifikasi bahwa kode kita bekerja dengan cara itu.

Ketika saya membaca The Book (*) pada TDD, bagi saya fitur yang paling penting yang menonjol adalah: TODO list. Ini menunjukkan kepada saya bahwa, TDD juga merupakan teknik untuk membantu pengembang fokus pada satu hal pada suatu waktu. Jadi ini juga jawaban untuk pertanyaan Anda tentang How much Real code to write ? Saya akan mengatakan cukup banyak kode untuk fokus pada satu hal pada satu waktu.

(*) "Test Driven Development: By Example" oleh Kent Beck

1 comments
2 Robert Andrzejuk 07/27/2017
"Test Driven Development: By Example" oleh Kent Beck

Zenilogix 07/31/2017.

Anda tidak menulis kode untuk membuat tes Anda gagal.

Anda menulis tes Anda untuk menentukan seperti apa kesuksesan itu, yang semuanya harus gagal karena Anda belum menulis kode yang akan lulus.

Inti dari penulisan tes yang gagal adalah untuk melakukan dua hal:

  1. Tutup semua kasus - semua kasus nominal, semua kasus tepi, dll.
  2. Validasi tes Anda. Jika Anda hanya melihat mereka lulus, bagaimana Anda bisa yakin mereka akan melaporkan kegagalan ketika terjadi?

Titik di balik red-green-refactor adalah bahwa menulis tes yang benar pertama memberi Anda kepercayaan diri untuk mengetahui bahwa kode yang Anda tulis untuk lulus tes adalah benar, dan memungkinkan Anda untuk refactor dengan keyakinan bahwa tes Anda akan memberi tahu Anda segera setelah ada yang rusak, jadi Anda dapat segera kembali dan memperbaikinya.

Dalam pengalaman saya sendiri (C # /. NET), tes murni pertama adalah sedikit ideal yang tidak dapat dicapai, karena Anda tidak dapat mengkompilasi panggilan ke metode yang belum ada. Jadi "test first" adalah benar-benar meng-coding antarmuka dan menghentikan implementasi pertama, kemudian menulis tes terhadap stub (yang pada awalnya akan gagal) hingga stub-stubnya disempurnakan dengan benar. Saya tidak pernah menulis "kode gagal", hanya membangun dari stub.


Zan Lynx 07/27/2017.

Saya pikir Anda mungkin bingung antara tes unit dan tes integrasi. Saya percaya mungkin juga ada tes penerimaan, tetapi itu tergantung pada proses Anda.

Setelah Anda menguji semua "unit" kecil itu, maka Anda menguji semuanya, atau "terintegrasi." Itu biasanya keseluruhan program atau perpustakaan.

Dalam kode yang saya tulis, integrasi menguji pustaka dengan berbagai program pengujian yang membaca data dan memberikannya ke pustaka, lalu periksa hasilnya. Lalu saya melakukannya dengan benang. Lalu saya melakukannya dengan benang dan garpu () di tengah. Lalu saya jalankan dan bunuh -9 setelah 2 detik, kemudian saya memulainya dan memeriksa mode pemulihannya. Saya mengelabui itu. Saya menyiksanya dengan berbagai cara.

Semua itu adalah pengujian JUGA, tetapi saya tidak memiliki tampilan merah / hijau yang cantik untuk hasilnya. Ini berhasil, atau saya menggali beberapa ribu baris kode kesalahan untuk mencari tahu mengapa.

Di situlah Anda menguji "kode asli."

Dan saya hanya memikirkan ini, tetapi mungkin Anda tidak tahu kapan Anda seharusnya selesai menulis tes unit. Anda selesai menulis tes unit ketika tes Anda menggunakan semua yang Anda tentukan. Kadang-kadang Anda dapat kehilangan jejak itu di antara semua penanganan kesalahan dan kasus tepi, sehingga Anda mungkin ingin membuat tes kelompok uji jalur bahagia yang bagus yang langsung melalui spesifikasi.

1 comments
Peter Mortensen 07/27/2017
(nya = posesif, itu = "itu" atau "sudah". Lihat misalnya How to Use Its and It's .)

user3791372 07/27/2017.

Sebagai jawaban atas judul pertanyaan: "Kapan Anda menulis kode" asli "dalam TDD?", Jawabannya adalah: "hampir tidak pernah" atau "sangat lambat".

Anda terdengar seperti seorang siswa, jadi saya akan menjawab seolah-olah menasihati seorang siswa.

Anda akan belajar banyak 'teori' dan 'teknik' pengkodean. Mereka sangat bagus untuk melewatkan waktu di kursus mahasiswa yang terlalu mahal, tetapi sangat sedikit manfaatnya bagi Anda yang tidak bisa Anda baca di sebuah buku di separuh waktu.

Pekerjaan seorang pembuat kode adalah semata-mata untuk menghasilkan kode. Kode yang berfungsi dengan sangat baik. Itulah mengapa Anda, pembuat kode merencanakan kode di pikiran Anda, di atas kertas, dalam aplikasi yang sesuai, dll., Dan Anda berencana untuk mengatasi kemungkinan kesalahan / lubang di muka dengan berpikir logis dan lateral sebelum pengkodean.

Tetapi Anda perlu tahu cara mematahkan aplikasi Anda untuk dapat mendesain kode yang layak. Misalnya, jika Anda tidak tahu tentang Little Bobby Table (xkcd 327), maka Anda mungkin tidak akan menyanitasi input Anda sebelum bekerja dengan database, sehingga Anda tidak akan dapat mengamankan data Anda di sekitar konsep itu.

TDD hanyalah alur kerja yang dirancang untuk meminimalkan bug dalam kode Anda dengan membuat tes tentang apa yang bisa salah sebelum Anda mengkode aplikasi Anda karena pengkodean bisa mendapatkan kode yang secara eksponensial sulit Anda perkenalkan dan Anda melupakan bug yang pernah Anda pikirkan. Setelah Anda berpikir Anda telah menyelesaikan aplikasi Anda, Anda menjalankan tes dan boom, semoga bug tertangkap dengan tes Anda.

TDD tidak - karena beberapa orang percaya - tulis tes, dapatkan lewat dengan kode minimal, tulis tes lain, dapatkan lewat itu dengan kode minimal, dll. Sebaliknya, ini adalah cara membantu Anda membuat kode dengan percaya diri. Ide ideal dari kode refactoring berkelanjutan untuk membuatnya bekerja dengan tes adalah bodoh, tetapi ini adalah konsep yang bagus di antara siswa karena itu membuat mereka merasa hebat ketika mereka menambahkan fitur baru dan mereka masih belajar bagaimana kode ...

Tolong jangan jebakan ini dan lihat peran Anda untuk apa itu - pekerjaan seorang pembuat kode semata-mata untuk menghasilkan kode. Kode yang berfungsi dengan sangat baik. Sekarang, ingat Anda akan berada di jam sebagai coder profesional, dan klien Anda tidak akan peduli jika Anda menulis 100.000 pernyataan, atau 0. Mereka hanya ingin kode yang berfungsi. Sangat baik, sebenarnya.

5 comments
3 johnny 07/25/2017
Saya bahkan tidak dekat dengan seorang siswa, tetapi saya membaca dan mencoba menerapkan teknik yang baik dan menjadi profesional. Jadi dalam arti itu, saya seorang "siswa." Saya hanya mengajukan pertanyaan yang sangat mendasar karena begitulah saya. Saya ingin tahu persis mengapa saya melakukan apa yang saya lakukan. Inti dari masalah ini. Jika saya tidak mengerti, saya tidak menyukainya dan mulai mengajukan pertanyaan. Saya perlu tahu mengapa, jika saya akan menggunakannya. TDD nampak baik secara intuitif dalam beberapa hal seperti mengetahui apa yang Anda butuhkan untuk membuat dan memikirkan berbagai hal, tetapi penerapannya sulit untuk dipahami. Saya pikir saya memiliki pemahaman yang lebih baik sekarang.
4 Sean Burton 07/27/2017
Itu adalah aturan TDD. Anda bebas menulis kode apa pun yang Anda inginkan, tetapi jika Anda tidak mengikuti ketiga aturan itu, Anda tidak melakukan TDD.
2 user3791372 07/27/2017
"Aturan" satu orang? TDD adalah saran untuk membantu Anda membuat kode, bukan agama. Sungguh menyedihkan melihat begitu banyak orang mengikuti sebuah ide secara anal. Bahkan asal-usul TDD masih kontroversial.
2 Alex 07/28/2017
@ user3791372 TDD adalah proses yang sangat ketat dan jelas. Bahkan jika banyak yang berpikir itu hanya berarti "Lakukan beberapa pengujian ketika Anda memprogram", bukan. Mari kita coba untuk tidak mencampuradukkan istilah di sini, pertanyaan ini adalah tentang proses TDD, bukan pengujian umum.

HighResolutionMusic.com - Download Hi-Res Songs

1 The Chainsmokers

Beach House flac

The Chainsmokers. 2018. Writer: Andrew Taggart.
2 (G)I-DLE

POP/STARS flac

(G)I-DLE. 2018. Writer: Riot Music Team;Harloe.
3 Anne-Marie

Rewrite The Stars flac

Anne-Marie. 2018. Writer: Benj Pasek;Justin Paul.
4 Ariana Grande

​Thank U, Next flac

Ariana Grande. 2018. Writer: Crazy Mike;Scootie;Victoria Monét;Tayla Parx;TBHits;Ariana Grande.
5 Diplo

Close To Me flac

Diplo. 2018. Writer: Ellie Goulding;Savan Kotecha;Peter Svensson;Ilya;Swae Lee;Diplo.
6 BTS

Waste It On Me flac

BTS. 2018. Writer: Steve Aoki;Jeff Halavacs;Ryan Ogren;Michael Gazzo;Nate Cyphert;Sean Foreman;RM.
7 Clean Bandit

Baby flac

Clean Bandit. 2018. Writer: Jack Patterson;Kamille;Jason Evigan;Matthew Knott;Marina;Luis Fonsi.
8 Imagine Dragons

Bad Liar flac

Imagine Dragons. 2018. Writer: Jorgen Odegard;Daniel Platzman;Ben McKee;Wayne Sermon;Aja Volkman;Dan Reynolds.
9 BlackPink

Kiss And Make Up flac

BlackPink. 2018. Writer: Soke;Kny Factory;Billboard;Chelcee Grimes;Teddy Park;Marc Vincent;Dua Lipa.
10 Nicki Minaj

No Candle No Light flac

Nicki Minaj. 2018. Writer: Denisia “Blu June” Andrews;Kathryn Ostenberg;Brittany "Chi" Coney;Brian Lee;TJ Routon;Tushar Apte;ZAYN;Nicki Minaj.
11 Rita Ora

Cashmere flac

Rita Ora. 2018. Writer: Sean Douglas;Lindy Robbins.
12 Backstreet Boys

Chances flac

Backstreet Boys. 2018.
13 Brooks

Limbo flac

Brooks. 2018.
14 Rita Ora

Velvet Rope flac

Rita Ora. 2018.
15 Fitz And The Tantrums

HandClap flac

Fitz And The Tantrums. 2017. Writer: Fitz And The Tantrums;Eric Frederic;Sam Hollander.
16 Little Mix

Woman Like Me flac

Little Mix. 2018. Writer: Nicki Minaj;Steve Mac;Ed Sheeran;Jess Glynne.
17 Cher Lloyd

None Of My Business flac

Cher Lloyd. 2018. Writer: ​iamBADDLUCK;Alexsej Vlasenko;Kate Morgan;Henrik Meinke;Jonas Kalisch;Jeremy Chacon.
18 Billie Eilish

When The Party's Over flac

Billie Eilish. 2018. Writer: Billie Eilish;FINNEAS.
19 Kelly Clarkson

Never Enough flac

Kelly Clarkson. 2018. Writer: Benj Pasek;Justin Paul.
20 Lil Pump

Arms Around You flac

Lil Pump. 2018. Writer: Rio Santana;Lil Pump;Edgar Barrera;Mally Mall;Jon Fx;Skrillex;Maluma;Swae Lee;XXXTENTACION.

Related questions

Hot questions

Language

Popular Tags