TDD vs. Produktivitas

131

Dalam proyek saya saat ini (sebuah game, dalam C ++), saya memutuskan untuk menggunakan Test Driven Development 100% selama pengembangan.

Dalam hal kualitas kode, ini sangat bagus. Kode saya tidak pernah dirancang dengan begitu baik atau tanpa bug. Saya tidak merasa ngeri ketika melihat kode yang saya tulis setahun yang lalu pada awal proyek, dan saya telah mendapatkan pengertian yang jauh lebih baik tentang bagaimana menyusun berbagai hal, tidak hanya agar lebih mudah diuji, tetapi lebih mudah untuk diterapkan dan digunakan .

Namun ... sudah setahun sejak saya memulai proyek. Memang, saya hanya bisa mengerjakannya di waktu luang saya, tetapi TDD masih memperlambat saya jauh dibandingkan dengan apa yang saya terbiasa. Saya membaca bahwa kecepatan pengembangan yang lebih lambat menjadi lebih baik dari waktu ke waktu, dan saya benar-benar memikirkan tes jauh lebih mudah daripada sebelumnya, tapi saya sudah melakukannya selama satu tahun sekarang dan saya masih bekerja dengan kecepatan siput.

Setiap kali saya memikirkan langkah selanjutnya yang perlu dikerjakan, saya harus berhenti setiap waktu dan berpikir tentang bagaimana saya akan menulis tes untuk itu, untuk memungkinkan saya menulis kode yang sebenarnya. Terkadang saya macet selama berjam-jam, tahu persis kode apa yang ingin saya tulis, tetapi tidak tahu cara memecahnya cukup halus untuk sepenuhnya menutupinya dengan tes. Di lain waktu, saya akan dengan cepat memikirkan selusin tes, dan menghabiskan satu jam menulis tes untuk menutupi sepotong kecil kode nyata yang seharusnya memerlukan waktu beberapa menit untuk menulis.

Atau, setelah menyelesaikan tes ke-50 untuk mencakup entitas tertentu dalam permainan dan semua aspek pembuatan dan penggunaannya, saya melihat daftar tugas yang harus saya lakukan dan melihat entitas berikutnya yang akan dikodekan, dan ngeri ngeri membayangkan menulis 50 tes serupa lainnya untuk mengimplementasikannya.

Sudah sampai pada titik itu, melihat kemajuan tahun lalu, saya sedang mempertimbangkan meninggalkan TDD demi "menyelesaikan proyek sialan". Namun, menyerahkan kualitas kode yang menyertainya bukanlah sesuatu yang saya harapkan. Saya takut jika saya berhenti menulis tes, maka saya akan keluar dari kebiasaan membuat kode jadi modular dan dapat diuji.

Apakah saya mungkin melakukan sesuatu yang salah untuk tetap lambat dalam hal ini? Adakah alternatif yang mempercepat produktivitas tanpa sepenuhnya kehilangan manfaat? TAD? Kurang cakupan tes? Bagaimana orang lain dapat bertahan hidup tanpa TDD tanpa membunuh semua produktivitas dan motivasi?

unit-testing tdd

— Nairou
sumber

@Nairou: Anda selalu bisa mencoba "menyelesaikan proyek"! Buat cabang sekarang. Cukup tulis kode di sana. Tetapi batasi apa yang Anda lakukan, baik berdasarkan waktu atau jumlah entitas game dan lihat apakah Anda melangkah lebih cepat. Anda kemudian dapat mengabaikan cabang itu, kembali ke trunk dan TDD dari sana dan melihat apa bedanya.

— quamrana

9

Bagi saya, menulis tes terlalu dini seperti mengoptimalkan terlalu dini. Anda mungkin akan bekerja keras untuk menguji kode yang akan Anda hapus di masa depan.

— LennyProgrammers

Saya sedikit khawatir Anda menghabiskan berjam-jam memikirkan cara untuk merancang kode Anda sehingga lebih mudah diuji. Testability mungkin merupakan atribut dari desain yang difaktorkan dengan baik, tetapi seharusnya tidak menjadi tujuan utama dari desain .

— Jeremy

2

Kembali ketika saya belajar, kami punya trik ketika kami harus menyediakan dokumen desain. Kami menulis kode terlebih dahulu, lalu menulis dokumen untuk menggambarkan kode. Mungkin Anda perlu mempelajari pragmatisme dalam jumlah sedang untuk TDD Anda. Jika Anda sudah memiliki rencana dalam pikiran, mungkin lebih baik memasukkan sebagian besar ke dalam kode sebelum menulis tes. Apa pun yang disarankan oleh idealisme, kadang-kadang lebih baik melakukan apa yang sudah siap Anda lakukan, daripada mengalihkan perhatian Anda dengan sesuatu yang lain kemudian kembali ketika Anda tidak segar lagi.

— Steve314

4

Saya akan menentang opini populer dan mengatakan bahwa TDD mungkin tidak selalu menjadi pilihan yang tepat jika Anda membuat game. Karena seseorang di gamedev.stackexchange sudah menjawab pertanyaan ini dengan spektakuler, saya hanya akan menautkan ini di sini .

— l46kok

77

Mari saya mulai dengan berterima kasih kepada Anda untuk berbagi pengalaman Anda dan menyuarakan keprihatinan Anda ... yang harus saya katakan tidak biasa.

Waktu / Produktivitas: Tes menulis lebih lambat daripada tidak menulis tes. Jika Anda ruang lingkup itu, saya setuju. Namun, jika Anda menjalankan upaya paralel di mana Anda menerapkan pendekatan non-TDD, kemungkinan bahwa waktu yang Anda habiskan untuk memecahkan-deteksi-debug-dan-perbaiki kode yang ada akan menempatkan Anda di net negative. Bagi saya, TDD adalah yang tercepat yang bisa saya lakukan tanpa mengorbankan kepercayaan kode saya. Jika Anda menemukan hal-hal dalam metode Anda, yang tidak menambah nilai, hilangkan mereka.
Jumlah tes: Jika Anda membuat N hal, Anda perlu menguji N hal. untuk memparafrasekan salah satu kalimat Kent Beck " Uji hanya jika Anda ingin itu berhasil. "
Terjebak selama berjam-jam: Saya juga melakukannya (kadang-kadang dan tidak> 20 menit sebelum saya menghentikannya). Ini hanya kode Anda yang memberi tahu Anda bahwa desain memerlukan beberapa pekerjaan. Tes hanyalah klien lain untuk kelas SUT Anda. Jika suatu tes menemukan kesulitan untuk menggunakan tipe Anda, kemungkinan demikian juga klien produksi Anda.
Tes serupa kebosanan: Ini membutuhkan lebih banyak konteks bagi saya untuk menulis argumen balasan. Yang mengatakan, Berhenti dan pikirkan kesamaannya. Bisakah Anda data-drive tes itu entah bagaimana? Apakah mungkin untuk menulis tes terhadap tipe dasar? Maka Anda hanya perlu menjalankan set tes yang sama terhadap setiap derivasi. Dengarkan tes Anda. Jadilah jenis malas yang tepat dan lihat apakah Anda dapat menemukan cara untuk menghindari kebosanan.
Berhenti memikirkan apa yang perlu Anda lakukan selanjutnya (tes / spek) bukan hal yang buruk. Sebaliknya, disarankan agar Anda membangun "hal yang benar". Biasanya jika saya tidak bisa memikirkan cara mengujinya, saya biasanya tidak bisa memikirkan implementasinya juga. Adalah ide yang bagus untuk menghapus ide implementasi sampai Anda tiba di sana .. mungkin solusi yang lebih sederhana dibayangi oleh desain pre-emptive YAGNI-ish.

Dan itu membawa saya ke pertanyaan terakhir: Bagaimana saya menjadi lebih baik? Jawaban saya (atau An) adalah Baca, Renungkan, dan Berlatih.

misalnya Akhir-akhir ini, saya tetap mengawasi

apakah ritme saya mencerminkan RG [Ref] RG [Ref] RG [Ref] atau RRRRGRRef.
% waktu yang dihabiskan dalam kondisi Kesalahan Merah / Kompilasi.
Apakah saya terjebak dalam kondisi build Red / Broken?

— Gishu
sumber

1

Saya sangat ingin tahu tentang komentar Anda tentang data-mengemudi tes. Apakah Anda hanya bermaksud satu set tes yang memproses data eksternal (seperti dari file) daripada menguji ulang kode yang sama? Dalam permainan saya, saya memiliki beberapa entitas, dan masing-masing sangat berbeda, tetapi ada beberapa hal umum yang dilakukan dengan mereka (membuat serial mereka melalui jaringan, memastikan mereka tidak dikirim ke pemain yang tidak ada, dll.) Sejauh ini saya belum menemukan cara untuk mengkonsolidasikan ini, dan begitu juga serangkaian tes untuk masing-masing yang hampir identik, hanya berbeda dalam entitas apa yang mereka gunakan dan data apa yang dikandungnya.

@Nairoi - Tidak yakin test runner apa yang Anda gunakan. Saya baru belajar nama untuk apa yang ingin saya sampaikan. Pola fixture abstrak [ goo.gl/dWp3k] . Ini masih mengharuskan Anda untuk menulis Fixture sebanyak mungkin karena ada jenis SUT konkret. Jika Anda ingin menjadi lebih ringkas, lihat dokumen pelari Anda. misalnya NUnit mendukung perlengkapan uji Parameter dan Generik (sekarang saya mencarinya) goo.gl/c1eEQ Sepertinya hal yang paling Anda butuhkan.

— Gishu

Menarik, saya belum pernah mendengar perlengkapan abstrak. Saat ini saya menggunakan UnitTest ++ yang memiliki perlengkapan, tetapi tidak yang abstrak. Fixture-nya sangat harfiah, hanya cara mengkonsolidasikan kode uji yang seharusnya Anda ulangi di setiap tes, untuk kelompok tes tertentu.

@asgeo - tidak dapat mengedit komentar itu .. tautannya telah mengambil braket trailing. Ini seharusnya berfungsi - goo.gl/dWp3k

— Gishu

+1 untuk 'buntu adalah gejala desain memerlukan lebih banyak pekerjaan', meskipun .. apa yang terjadi ketika Anda buntu (seperti saya) di desain?

— lurscher

32

Anda tidak perlu cakupan tes 100% persen. Bersikap pragmatis.

— Alistair
sumber

2

Jika Anda tidak memiliki cakupan pengujian 100%, Anda tidak memiliki kepercayaan diri 100%.

— Christopher Mahan

60

Anda tidak memiliki kepercayaan diri 100% bahkan dengan cakupan tes 100%. Itu menguji 101. Pengujian tidak dapat menunjukkan bahwa kode bebas cacat; sebaliknya, mereka hanya bisa menunjukkan bahwa itu memang mengandung cacat.

— CesarGon

7

Untuk apa nilainya, salah satu pendukung TDD paling bersemangat, Bob Martin, tidak merekomendasikan cakupan 100% - blog.objectmentor.com/articles/2009/01/31/… . Dalam industri manufaktur (memang, berbeda dari perangkat lunak dalam banyak hal), tidak ada yang percaya 100% karena mereka dapat menghabiskan sebagian kecil dari upaya untuk menjadi 99% percaya diri.

— Peluang

Juga (setidaknya terakhir kali saya memeriksa alat yang kita miliki) laporan cakupan kode berhubungan dengan apakah baris dieksekusi tetapi tidak termasuk cakupan nilai - misalnya hari ini saya melaporkan bug di mana saya memiliki semua jalur melalui kode yang dieksekusi dalam pengujian, tetapi karena ada baris seperti a = x + ydan meskipun semua baris dalam kode dieksekusi dalam tes, tes hanya diuji untuk kasus di mana y = 0, sehingga bug (seharusnya a = x - y) tidak pernah ditemukan dalam tes.

— Pete Kirkham

@ Peluang - Saya telah membaca buku Robert Martin "Clean coder ..." beberapa nama panjang. Dikatakan dalam buku itu, bahwa itu harus asimptot 100% ditutupi dengan tes, yang mendekati 100%. Dan tautan blog tidak berfungsi lagi.

— Darius.V

22

TDD masih memperlambat saya jauh

Itu sebenarnya salah.

Tanpa TDD, Anda menghabiskan beberapa minggu menulis kode yang sebagian besar bekerja dan menghabiskan tahun berikutnya "pengujian" dan memperbaiki banyak (tetapi tidak semua) bug.

Dengan TDD, Anda menghabiskan satu tahun menulis kode yang benar-benar berfungsi. Kemudian Anda melakukan pengujian integrasi akhir selama beberapa minggu.

Waktu yang berlalu mungkin akan sama. Perangkat lunak TDD akan jauh lebih berkualitas.

— S.Lott
sumber

6

Jadi mengapa saya perlu TDD? "Waktu yang berlalu adalah sama"

21

@Peter Long: Kualitas kode. Tahun "pengujian" adalah bagaimana kita berakhir dengan perangkat lunak sampah yang sebagian besar berfungsi.

— S.Lott

1

@ Peter, Anda pasti bercanda. Kualitas solusi TDD akan jauh lebih unggul.

— Mark Thomas

7

Mengapa saya perlu TDD? Kent Beck mendaftar ketenangan pikiran sebagai hal yang besar, dan itu sangat menarik bagi saya. Saya hidup dalam ketakutan terus menerus akan merusak barang-barang ketika saya mengerjakan kode tanpa tes unit.

7

@Peter Panjang: "Waktu yang berlalu adalah sama" ... dan pada titik mana pun selama waktu itu Anda dapat mengirimkan kode kerja .

— Frank Shearar

20

Atau, setelah menyelesaikan tes ke-50 untuk mencakup entitas tertentu dalam permainan dan semua aspek pembuatan dan penggunaannya, saya melihat daftar tugas yang harus saya lakukan dan melihat entitas berikutnya yang akan dikodekan, dan ngeri ngeri membayangkan menulis 50 tes serupa lainnya untuk mengimplementasikannya.

Ini membuat saya bertanya-tanya berapa banyak Anda mengikuti langkah "Refactor" dari TDD.

Ketika semua tes Anda lulus, ini saatnya bagi Anda untuk memperbaiki kode dan menghapus duplikasi. Sementara orang biasanya mengingat ini, kadang-kadang mereka lupa bahwa ini juga saatnya untuk memperbaiki tes mereka juga, untuk menghapus duplikasi dan menyederhanakan hal-hal.

Jika Anda memiliki dua entitas yang bergabung menjadi satu untuk memungkinkan kode digunakan kembali, pertimbangkan juga untuk menggabungkan pengujian mereka. Anda benar-benar hanya perlu menguji perbedaan inkremental dalam kode Anda. Jika Anda tidak secara teratur melakukan perawatan pada tes Anda, mereka dapat dengan cepat menjadi berat.

Beberapa poin filosofis tentang TDD yang mungkin bermanfaat:

Ketika Anda tidak dapat menemukan cara untuk menulis tes, meskipun tes menulis pengalaman yang luas, maka itu pasti bau kode . Kode Anda entah bagaimana kurang dalam modularitas, yang membuat menulis tes kecil, sederhana menjadi sulit.
Menghabiskan sedikit kode bisa diterima saat menggunakan TDD. Tulis kode yang Anda inginkan, untuk mendapatkan gambaran seperti apa, kemudian hapus kode dan mulailah dengan tes.
Saya melihat berlatih TDD yang sangat ketat sebagai bentuk latihan. Saat pertama kali memulai, tulis tes terlebih dahulu setiap kali, dan tulis kode paling sederhana untuk lulus ujian sebelum melanjutkan. Namun, ini tidak perlu begitu Anda menjadi lebih nyaman dengan latihan. Saya tidak memiliki tes unit untuk setiap jalur kode yang mungkin saya tulis, tetapi melalui pengalaman saya dapat memilih apa yang perlu diuji dengan uji unit, dan apa yang bisa dicakup oleh pengujian fungsional atau integrasi sebagai gantinya. Jika Anda telah berlatih TDD dengan ketat selama setahun, saya akan membayangkan Anda juga mendekati titik ini.

EDIT: Pada topik filsafat unit testing, saya pikir ini mungkin menarik untuk Anda baca: The Way of Testivus

Dan poin yang lebih praktis, jika tidak selalu sangat membantu:

Anda menyebutkan C ++ sebagai bahasa pengembangan Anda. Saya sudah berlatih TDD secara luas di Jawa, menggunakan perpustakaan yang sangat baik seperti JUnit dan Mockito. Namun, saya telah menemukan TDD di C ++ menjadi sangat frustasi karena kurangnya perpustakaan (khususnya, kerangka kerja mengejek) yang tersedia. Meskipun poin ini tidak banyak membantu Anda dalam situasi Anda saat ini, saya harap Anda mempertimbangkannya sebelum membuang TDD sama sekali.

— Jaustin
sumber

4

Tes refactoring berbahaya. Sepertinya tidak ada yang membicarakan hal ini, tetapi memang demikian. Saya jelas tidak memiliki unit test untuk menguji unit test saya. Ketika Anda menolak untuk mengurangi duplikasi, Anda biasanya meningkatkan kompleksitas (karena kode Anda menjadi lebih umum). Itu berarti ada kemungkinan besar ada bug dalam tes Anda .

— Scott Whitlock

2

Saya tidak setuju bahwa tes refactoring berbahaya. Anda hanya refactoring ketika semuanya lewat, jadi jika Anda melakukan refactoring dan semuanya masih hijau, maka Anda baik-baik saja. Jika Anda berpikir Anda perlu menulis tes untuk tes Anda, saya merasa itu adalah indikator bahwa Anda perlu menulis tes yang lebih sederhana.

— jaustin

1

C ++ sulit untuk unit test (bahasa tidak mudah melakukan hal-hal yang membuat ejekan mudah). Saya perhatikan bahwa fungsi yang merupakan "fungsi" (hanya beroperasi pada argumen, hasilnya keluar sebagai nilai pengembalian / params) jauh lebih mudah untuk diuji daripada "prosedur" (return void, no args). Saya telah menemukan bahwa sebenarnya bisa lebih mudah untuk menguji unit kode C modular yang dibuat dengan baik daripada kode C ++. Anda tidak harus menulis dalam C, tetapi Anda dapat mengikuti contoh C modular. Kedengarannya benar-benar gila, tapi saya sudah melakukan tes unit pada "bad C" di mana semuanya bersifat global dan itu super mudah-semua negara selalu tersedia !.

— anon

2

Saya pikir ini sangat benar. Saya melakukan banyak RedGreenRedGreenRedGreen (atau, lebih sering, RedRedRedGreenGreenGreen), tetapi saya jarang refactor. Tes saya tentu saja tidak pernah di refactored, karena saya selalu merasa akan membuang lebih banyak waktu untuk tidak membuat kode. Tapi saya bisa melihat bagaimana itu mungkin menjadi penyebab masalah yang saya hadapi sekarang. Saatnya bagi saya untuk serius melakukan refactoring dan konsolidasi.

— Nairou

1

Google C ++ kerangka kerja mengejek (terintegrasi dengan google C ++ test fw) - perpustakaan mengejek yang sangat, sangat kuat - fleksibel, kaya fitur - cukup sebanding dengan kerangka kerja mengejek lainnya di luar sana.

— ratkok

9

Pertanyaan yang sangat menarik.

Yang penting untuk dicatat, adalah bahwa C ++ tidak mudah diuji, dan game, secara umum, juga merupakan kandidat yang sangat buruk untuk TDD. Anda tidak dapat menguji apakah OpenGL / DirectX menggambar segitiga merah dengan driver X, dan kuning dengan driver Y dengan mudah. Jika bump map, vektor normal tidak terbalik setelah shader berubah. Anda juga tidak dapat menguji kliping masalah pada versi driver dengan tindakan berbeda, dan sebagainya. Perilaku menggambar yang tidak terdefinisi karena panggilan yang salah juga dapat diuji hanya dengan peninjauan kode yang akurat dan SDK. Suara juga merupakan kandidat yang buruk. Multithreading, yang sekali lagi cukup penting untuk gim, cukup berguna untuk unit-test. Jadi itu sulit.

Pada dasarnya gaming banyak GUI, suara dan utas. GUI, bahkan dengan komponen standar yang dapat Anda kirim WM_, sulit untuk unit-test.

Jadi yang dapat Anda uji, adalah kelas pemuatan model, kelas pemuatan tekstur, pustaka matriks dan semacamnya, yang tidak banyak kode, dan, cukup sering, tidak dapat digunakan kembali, jika itu hanya proyek pertama Anda. Juga, mereka dikemas ke dalam format berpemilik, jadi kemungkinan besar input pihak ketiga tidak akan banyak berbeda, kecuali jika Anda merilis alat modding dll.

Kemudian lagi, saya bukan guru atau penginjil TDD, jadi ambil semua itu dengan sebutir garam.

Saya mungkin akan menulis beberapa tes untuk komponen inti utama (misalnya perpustakaan matriks, perpustakaan gambar). Tambahkan sekelompok abort()input yang tidak terduga di setiap fungsi. Dan yang paling penting, berkonsentrasi pada kode yang tahan / tangguh yang tidak mudah rusak.

Mengenai satu kesalahan, penggunaan pintar C ++, RAII dan desain yang bagus sangat membantu untuk mencegahnya.

Pada dasarnya Anda harus melakukan banyak hal hanya untuk menutupi dasar-dasarnya jika Anda ingin merilis game. Saya tidak yakin apakah TDD akan membantu.

— Coder
sumber

3

+1 Saya benar-benar menyukai konsep TDD dan menggunakannya di mana pun saya bisa, tetapi Anda mengangkat poin yang sangat penting bahwa para pendukung TDD dengan anehnya diam. Ada banyak jenis pemrograman seperti yang telah Anda tunjukkan yang menulis tes unit bermakna sangat sulit jika bukan tidak mungkin. Gunakan TDD yang masuk akal, tetapi beberapa jenis kode lebih baik dikembangkan dan diuji dengan cara lain.

— Mark Heath

@ Mark: ya, sepertinya tidak ada yang peduli dengan tes integrasi saat ini, berpikir bahwa karena mereka punya test suite otomatis, semuanya akan bekerja secara ajaib ketika disatukan dan dicoba dengan data nyata.

— gbjbaanb

Setuju dengan ini. Terima kasih atas jawaban pragmatis yang tidak secara dogmatis meresepkan TDD sebagai jawaban untuk segalanya, alih-alih apa itu, yang hanyalah alat lain dalam toolkit pengembang.

— jb

6

Saya setuju dengan jawaban lain, tetapi saya juga ingin menambahkan poin yang sangat penting: Biaya refactoring !!

Dengan tes unit yang ditulis dengan baik, Anda dapat dengan aman melakukan penulisan ulang kode Anda. Pertama, unit test yang ditulis dengan baik memberikan dokumentasi yang sangat baik tentang maksud kode Anda. Kedua, efek samping yang tidak menguntungkan dari refactoring Anda akan ditangkap di ruang tes yang ada. Dengan demikian, Anda telah menjamin bahwa asumsi kode lama Anda juga berlaku untuk kode baru Anda.

— Morten
sumber

4

Bagaimana orang lain dapat bertahan hidup tanpa TDD tanpa membunuh semua produktivitas dan motivasi?

Ini sama sekali berbeda dari pengalaman saya. Anda cerdas luar biasa dan menulis kode tanpa bug, (mis. Dinonaktifkan karena satu kesalahan) atau Anda tidak menyadari kode Anda memiliki bug yang mencegah program Anda bekerja, sehingga tidak benar-benar selesai.

TDD adalah tentang memiliki kerendahan hati untuk mengetahui bahwa Anda (dan saya!) Membuat kesalahan.

Bagi saya waktu menulis unittests lebih dari yang disimpan dalam mengurangi waktu debug untuk proyek yang dilakukan menggunakan TDD dari awal.

Jika Anda tidak membuat kesalahan maka mungkin TDD tidak sepenting bagi Anda seperti bagi saya!

— Tom
sumber

Nah, Anda juga memiliki bug dalam kode TDD Anda;)

— Coder

Itu benar! tetapi mereka cenderung menjadi jenis bug yang berbeda, jika TDD dilakukan dengan benar. Saya kira mengatakan kode harus 100% bebas bug untuk diselesaikan tidak benar. Meskipun jika seseorang mendefinisikan bug sebagai penyimpangan dari perilaku unit test yang didefinisikan, maka saya rasa itu adalah bug gratis :)

— Tom

3

Saya hanya punya beberapa komentar:

Sepertinya Anda mencoba menguji semuanya . Anda mungkin tidak seharusnya, hanya kasus-kasus berisiko tinggi dan tepi sepotong kode / metode tertentu. Saya cukup yakin aturan 80/20 berlaku di sini: Anda menghabiskan 80% menulis tes untuk 20% terakhir dari kode Anda atau kasus yang tidak tercakup.
Memprioritaskan. Masuk ke pengembangan perangkat lunak tangkas, dan buat daftar apa yang benar-benar benar-benar perlu Anda lakukan untuk rilis dalam waktu satu bulan. Lalu lepaskan, begitu saja. Ini akan membuat Anda berpikir tentang prioritas fitur. Ya, itu akan keren jika karakter Anda bisa melakukan backflip, tetapi apakah itu memiliki nilai bisnis ?

TDD baik, tetapi hanya jika Anda tidak bertujuan untuk cakupan uji 100%, dan itu tidak jika hal itu membuat Anda tidak menghasilkan nilai bisnis yang sebenarnya (yaitu fitur, hal-hal yang menambah sesuatu ke permainan Anda).

— Cthulhu
sumber

1

Ya, menulis tes dan kode mungkin memakan waktu lebih lama dari sekadar menulis kode - tetapi menulis kode dan pengujian unit terkait (menggunakan TDD) jauh lebih mudah diprediksi daripada menulis kode dan kemudian men-debug-nya.

Debugging hampir dihilangkan ketika menggunakan TDD - yang membuat semua proses pengembangan jauh lebih mudah diprediksi dan pada akhirnya - bisa dibilang lebih cepat.

Refactoring yang konstan - tidak mungkin untuk melakukan refactoring yang serius tanpa unit test suite yang komprehensif. Cara paling efisien untuk membangun jaring pengaman berbasis pengujian unit adalah selama TDD. Kode yang dire-refursi secara signifikan meningkatkan produktivitas keseluruhan dari desainer / tim yang mengelola kode.

— ratkok
sumber

0

Pertimbangkan untuk mempersempit ruang lingkup gim Anda dan dapatkan di mana seseorang dapat memainkannya atau Anda melepaskannya. Pertahankan standar pengujian Anda tanpa harus menunggu terlalu lama untuk merilis game Anda mungkin merupakan jalan tengah untuk membuat Anda tetap termotivasi. Umpan balik dari pengguna Anda dapat memberikan manfaat dalam jangka panjang dan pengujian Anda membuat Anda merasa nyaman dengan penambahan dan perubahan.

— JeffO
sumber