Jika TDD adalah tentang desain mengapa saya membutuhkannya? [Tutup]


10

Guru TDD semakin banyak memberi tahu kami bahwa TDD bukan tentang tes, ini tentang desain . Jadi saya tahu beberapa pengembang yang membuat desain hebat tanpa TDD. Haruskah mereka berlatih TDD?


14
Jika mereka baik-baik saja tanpa itu, maka mereka tidak membutuhkannya. Tidak setiap "praktik terbaik" bekerja untuk semua orang.
Benteng

1
Jawaban saya untuk pertanyaan serupa: programmers.stackexchange.com/questions/98485/…
Rei Miyasaka

Jawaban:


18

TDD tidak hanya membantu saya mencapai desain akhir terbaik, ini membantu saya sampai di sana dalam upaya yang lebih sedikit.

Dulu saya memiliki dua atau tiga tusukan pada suatu masalah sebelum memutuskan desain mana yang saya pikir terbaik. Sekarang, waktu yang sama persis dihabiskan untuk menulis tes dan memfokuskan pikiran saya pada desain yang benar. Dan, sebagai bonus, itu membuat saya dengan serangkaian tes berulang. Menang!

Yang mengatakan, pasti akan ada orang-orang yang TDD tidak menawarkan apa-apa. Selama mereka masih memiliki tes otomatis yang dapat diulang di akhir, itu bagus.


4
dalam upaya yang lebih sedikit, benarkah?
SiberianGuy

3
Ya benar TDD memaksa saya untuk berpikir tentang kelas dalam hal kode panggilan, serta fungsinya, karena Anda mulai dengan menulis kode yang Anda harapkan dapat menulis untuk mengkonsumsi kelas. Ketika saya menulis kelas "buta" saya cenderung fokus pada apa yang dilakukannya lebih dari apa yang diharapkan oleh kelas panggilan, yang hampir selalu merupakan kesalahan.
pdr

4
Lihat, ada kata itu lagi forced,. Saya tidak tahu mengapa orang tidak lebih sering terganggu oleh frekuensi kata "terpaksa" seperti yang terjadi dalam diskusi tentang TDD. Seseorang seharusnya tidak perlu dipaksa untuk merancang sesuatu dengan benar; mereka harus belajar bagaimana merancang sesuatu dengan benar, dan kemudian terus melakukannya tanpa dipaksa ke dalamnya, terutama ketika tindakan pemaksaan itu sangat memakan waktu.
Rei Miyasaka

3
@Rei: Orang-orang tidak lebih sering terganggu karena mereka tahu bahwa orang lain benar-benar berarti "didorong" atau "dibimbing" atau ... dan inilah wahyu ketika Anda berbicara tentang Test Driven Development ... mungkin "didorong" . Dan ya, beberapa mungkin menemukan bahwa mereka berpikir seperti itu secara alami, tanpa didorong, saya mengatakan itu di posting. Tetapi Anda masih harus menguji perangkat lunak Anda sehingga Anda tidak jauh lebih baik.
pdr

3
Ketika seseorang mengatakan "gaya desain modular", mereka memang dipaksa. Sangat sulit (jika bukan tidak mungkin) untuk membuat desain non-komposable dengan TDD, dan itu hal yang baik. Masalahnya bukanlah hasil akhir dari menjadi kuat; itu adalah jumlah upaya kasar, hafalan yang dibutuhkan. Desain yang tepat adalah keterampilan yang dapat diajar dan dipelajari, dan waktu harus dihabiskan untuk belajar. Juga, tes yang ditulis untuk TDD tidak terlihat seperti tes yang ditulis untuk menangkap bug. Jika mereka melakukannya, ada sesuatu yang salah .
Rei Miyasaka

12

Apa ini khususnya guru TDD benar-benar mencoba untuk mengatakan tidak bahwa TDD adalah proses desain (meskipun sejumlah orang telah sayangnya ditafsirkan seperti itu). Pesan di sini adalah bahwa menggunakan proses seperti TDD, jika Anda melakukannya dengan benar , akan cenderung meningkatkan desain Anda secara keseluruhan.

Konsep dasar adalah yang jauh lebih tua dari TDD; mendesain untuk testability . Jika Anda secara ketat mematuhi prinsip-prinsip SOLID , terutama Prinsip Tanggung Jawab Tunggal , Anda akan menemukan kode sangat mudah untuk diuji. Di sisi lain, jika Anda cenderung sedikit ceroboh dalam desain Anda, Anda mungkin akan menemukan proses penulisan unit test untuk memaksa Anda melakukan ini lebih sering, untuk menghindari frustrasi dari (a) mencari tahu apa yang perlu diuji, dan (b) menghabiskan lebih banyak waktu mengatur dependensi daripada menulis tes yang sebenarnya.

Anda tidak harus mengikuti TDD untuk mendapatkan manfaat ini, tetapi tidak membantu untuk menulis tes awal - sebaiknya segera setelah Anda menerapkan kelas, jika tidak sebelum atau selama. Jika Anda menunggu terlalu lama, Anda berisiko melakukan tes "hybrid kotor" yang dibicarakan penulis, yang tidak memiliki banyak nilai karena rapuh dan cenderung pecah selama refactoring yang tidak berbahaya - belum lagi membuat lebih besar -Resain ulang skala proses yang sangat sulit.

Anda tidak dapat mengetahui apakah Anda benar-benar merancang pengujian jika Anda tidak menulis tes, dan "tes fitur" yang serampangan dengan hanya 15% cakupan kode tidak masuk hitungan.

Tentu saja Anda dapat membuat desain yang bagus tanpa harus menulis tes tunggal - tetapi apakah Anda yakin itu desain yang hebat? Bagaimana Anda tahu, jika Anda tidak ditentukan dengan jelas oleh tes? Pengujian mengungkap banyak masalah, dan sementara proses QA mungkin menemukan bug yang terlihat, mereka tidak akan mengungkap keputusan desain yang buruk.


1
Inti dari desain yang baik tidak hanya sedang diuji. Tapi ya, TDD adalah alat yang baik untuk melihat desain yang cacat.
deadalnix

4

Jawaban sederhana yang datang dari seseorang yang berusaha mempelajari TDD: Anda tidak membutuhkannya , tetapi manfaat utama yang diberikannya kepada Anda adalah, cukup sederhana, kepercayaan diri : Keyakinan bahwa aplikasi Anda berfungsi. Keyakinan bahwa kasus penggunaan puas. Keyakinan bahwa logika Anda cocok untuk modul "Foobar". Keyakinan bahwa kode Anda disusun dengan benar agar dapat dipertahankan dan dapat diperpanjang enam bulan ke depan ketika CEO ingin menambahkan beberapa fitur gila baru yang ia baca. Percaya diri bahwa, ketika aplikasi Anda tumbuh, fondasi telah diletakkan agar arsitektur tidak berantakan atau membutuhkan sekumpulan peretasan berantakan untuk fitur baru juri.

Saya menyadari hal di atas terdengar agak evangelis tetapi itulah bagaimana saya melihat manfaat TDD. Bahkan jika Anda dapat membuat desain yang bagus, solid, dan dirancang dengan baik menggunakan TDD memaksa tangan Anda untuk melakukan hal-hal yang benar, dan kemudian membuktikan bahwa segala sesuatunya dilakukan dengan benar, dan yang lebih penting memberikan garis dasar untuk menjaga hal-hal yang benar. Dari sangat sedikit saya mencoba-coba di TDD, menggunakannya memaksa saya untuk membuat kode bersih dan mengikuti konsep rekayasa perangkat lunak yang tepat, di mana kalau tidak saya akan melakukan "hal tercepat mungkin" yang sering mengakibatkan kode "hack" berantakan.


+1 TDD adalah umpan balik. Karena sebagian besar pengukuran umpan balik berjalan, itu cukup objektif dan sepenuhnya otomatis, sehingga dapat dibagikan oleh anggota tim dari semua tingkat keterampilan. Sebelum TDD, kode yang baik adalah sesuatu yang Anda "rasakan", atau dikonfirmasi beberapa saat setelah pengguna mendapatkan perangkat lunak. Semakin pendek loop, semakin Anda merasa percaya diri. Sayangnya TDD cenderung terlalu percaya diri sebagai "merasa" desain yang baik, tetapi jauh lebih mudah untuk mengoreksi diri.
Steve Jackson

2

Saya hanya dapat berbicara dari pengalaman saya. Bagi saya TDD membawa beberapa hal yang sebelumnya tidak saya miliki di kotak alat saya. Meskipun demikian, perlu dikatakan lagi bahwa TDD bukanlah solusi untuk semuanya. Saya selalu mencoba untuk memisahkan implementasi eksplorasi dan siap produksi. TDD dalam fase eksplorasi sama sekali tidak diperlukan dan bahkan melambat. Di sisi lain untuk kode siap produksi itu membawa beberapa manfaat yang dalam jangka pendek dan panjang sangat berharga bagi kesehatan mental pengembang dan karma proyek.

  • TDD membuat saya berpikir sebelum menerapkan, yang biasanya merupakan praktik yang sangat baik yang mencegah banyak pemotretan dan melupakan solusi
  • Itu membuat saya berpikir dalam sebagian kecil masalah, memaksa saya untuk memecah solusi untuk potongan-potongan kecil yang cocok bersama.
  • Itu membuat saya menulis kode yang sangat terpisah karena setiap kali saya harus mematikan / mengejek / memalsukan sesuatu yang tidak sesuai dengan masalah saya secara alami melemparkan satu "WTF, mengapa saya harus melakukan ini jika saya tidak harus digabungkan dengan itu" . Dan itu membuat saya menyadari hubungan antara hal-hal yang lebih baik.
  • Ini memberi saya serangkaian pemeriksaan yang mudah dieksekusi untuk kode saya, jadi saya tidak harus melalui "var_dump" yang menyakitkan, "p", "pp", "echo" gaya debugging kode. Hanya melaporkan apa yang salah, kapan salah. Dan jika saya belum memiliki cek untuk itu, itu hanya soal menambahkan tes sederhana untuk memeriksanya berulang kali.
  • Itu membuat saya yakin bahwa kode saya berfungsi jika semua tes lulus sebelum kami menyebarkan. Kemudian alih-alih memakan kukuku, aku pergi makan kue dan minum kopi dan menikmati sore hari.
  • Tes tingkat tinggi sangat bagus jika Anda harus memperbaiki sesuatu. Jika modul saya harus menyediakan beberapa fungsionalitas ke dunia luar dan saya telah mengembangkan tes fungsional / integrasi / mentimun untuk membuktikannya berfungsi dengan benar, saya akan sangat berani untuk memperbaiki kode itu. Beberapa kali saya dihadapkan dengan kode yang tidak memiliki tes dan perlu memperbaikinya. Dalam hal ini ada dua cara untuk berlatih. 1) jatuhkan kode 2) lewati perubahan dan biarkan apa adanya.

Ada satu hal yang tidak diperbaiki TDD. Jika Anda tidak tahu cara membangun benda yang sedang Anda bangun, maka TDD tidak akan menghasilkan solusi untuk Anda. Anda harus memiliki "desain" kasar atau gambaran umum masalah dan solusi. TDD akan membuat Anda menerapkannya dengan cara yang lebih elegan dan terpelihara dengan kode yang lebih berkualitas.

Akhirnya, saya lebih suka berpikir dalam istilah BDD yang bersandar pada praktik TDD. BDD membuat saya untuk mengimplementasikan solusi menggunakan kosa kata domain dan membuat perangkat lunak sesuai dengan masalah dengan lebih baik.


1

Mungkin ada banyak cara untuk mencapai desain hebat, dan ada banyak interpretasi berbeda tentang apa yang disebut "hebat" - atau bahkan "baik". Saya menduga sebagian besar TDDers tidak akan setuju dengan Anda tentang definisi - bahwa jika kita melihat kode yang Anda rasa bagus, kami akan menganggapnya kurang bagus. TDD mengarahkan kita ke beberapa kualitas yang sangat spesifik, dan kualitas ini jarang ditemukan dalam kode non-TDD.

Jelas, kemampuan ujian adalah salah satu dari kualitas-kualitas itu, dan yang paling utama. Metode dan kelas yang sangat kecil mungkin merupakan sub-karakteristik, dan ini mengarah pada penamaan yang sangat baik. Mungkin Anda mengenal programmer yang mencapai kualitas ini tanpa melakukan TDD, tapi saya tidak.


1
Anda hampir pasti menemukan kualitas yang sama dalam kode yang dihasilkan oleh proses air terjun, misalnya untuk militer, ruang, dll. Saya kira itu benar bahwa mereka tidak umum dalam versi Agile setengah-setengah dan / atau air terjun yang dipraktikkan di kebanyakan organisasi untuk proyek sehari-hari.
Aaronaught

@Aaronaught Katakan itu kepada tim Mars Climate Orbiter . :-)
Eric King

Saya memiliki pengalaman dengan proses air terjun pada proyek-proyek militer non-senjata di tahun 90-an, dan juga banyak diskusi tentang pendingin air dengan para veteran aplikasi militer lainnya. Konsensus umum adalah bahwa metodologi air terjun dan penagihan biaya-plus menghasilkan sistem kereta yang sangat sulit untuk dipelihara.
kevin cline
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.