it-swarm-id.com

Bisakah Anda Agile tanpa melakukan TDD (test driven development)?

Apakah mungkin menyebut diri Anda (atau tim Anda) dengan benar "Agile" jika Anda tidak melakukan TDD (Test-Driven Development)?

44
CraigTP

Ya, ya, ya, jutaan kali ya.

Agile adalah filosofi, TDD adalah metodologi khusus.

Jika saya ingin menjadi benar-benar pilih-pilih, saya cukup menunjukkan bahwa ada beberapa variasi xDD - yang akan dijelaskan oleh pendukung mereka secara mendalam adalah bukan TDD - tetapi mereka masih terikat dengan tes terlebih dahulu sehingga akan curang.

Jadi mari kita katakan ini - Anda bisa gesit tanpa melakukan pengembangan "test first" (lihat cara scrum bekerja - tidak ada tempat di mana ada spesifik tentang bagaimana Anda menulis kode). Lihatlah papan kanban, lihat segala macam metodologi tangkas.

Apakah Anda ingin tes unit? Tentu saja Anda lakukan, untuk semua jenis alasan - dan Anda mungkin membuat argumen bahwa Anda tidak bisa gesit tanpa unit test (walaupun saya curiga Anda bisa) - tetapi Anda tidak harus menuliskannya terlebih dahulu untuk menjadi tangkas.

Dan akhirnya, sama-sama benar bahwa Anda bisa melakukan Uji Pertama tanpa menjadi gesit dan argumen kuat untuk melakukan tes pertama terlepas dari keseluruhan filosofi dev Anda.


Tampaknya orang lain (dengan lebih banyak SOLID rep) memiliki pendapat yang sama ...

http://www.Twitter.com/unclebobmartin/status/208621409663070208

@unclebobmartin: http://t.co/huxAP5cS Meskipun bukan tidak mungkin untuk melakukan Agile tanpa TDD dan OOD, itu sulit. Tanpa TDD, tingkat iterasi ...

(Tautan di Tweet adalah jawaban lengkap di LinkedIn)

50
Murph

"Menjadi gesit" berarti mengikuti nilai-nilai dan prinsip-prinsip manifestasi tangkas . Tidak ada dalam dokumen yang menyebutkan TDD, atau bahkan pengujian unit untuk masalah ini.

Jadi ya, Anda bisa gesit tanpa melakukan TDD atau pengujian unit.

Saya tidak akan merekomendasikan ...

19
Martin Wickman

Ya,

Lihatlah salah satu nilai lincah:

Individu dan interaksi atas proses dan alat

Itu seharusnya sudah menjawabnya. TDD adalah metodologi tertentu, suatu proses. Memang suatu proses yang mungkin bisa digunakan dalam proses pembangunan lincah, tetapi tidak lebih. Saya pikir mungkin TDD canggih sekarang ketika menjadi gesit. Tapi saya pikir konsep lincah masih akan bisa bertahan, bahkan jika mungkin TDD telah digantikan oleh praktik lain.

Saya akan menyimpulkannya seperti:

  • Hari ini TDD adalah defacto-standar untuk gesit

  • Mungkin ada cara gesit tanpa TDD

11
FabianB

Saya katakan

Tidak ada [semacam]

Jika Anda kembali ke sumber asli http://en.wikipedia.org/wiki/Extreme_Programming TDD sangat penting untuk proses ini; tes menggantikan spesifikasi persyaratan dan kasus penggunaan air terjun, berfungsi sebagai dokumentasi hidup dan contoh berfungsi, dll. Mereka sangat diperlukan.

Namun, ada begitu banyak rasa 'lincah' yang beredar sekarang sehingga sangat mungkin bahwa salah satu dari mereka menghindari TDD

EDIT: @ interpretasi Murph dari pertanyaan tampaknya menjadi yang disukai. Heck, saya bahkan mengangkatnya, itu jawaban yang bagus. Namun, saya mempertahankan posisi saya bahwa Agile Manifesto adalah serangkaian prinsip, bukan metodologi pengembangan. Saya melihat tidak ada gunanya mengatakan "oh ya saya gesit" tanpa benar-benar menerapkan praktik yang membawa manfaat. Khususnya:

Perangkat lunak yang berfungsi adalah ukuran utama dari kemajuan.

dan

Proses lincah mempromosikan pembangunan berkelanjutan. Para sponsor, pengembang, dan pengguna harus dapat mempertahankan kecepatan konstan tanpa batas.

Bagi saya, kedua prinsip ini menyiratkan jika tidak memerlukan TDD - setidaknya saya tahu tidak ada cara lain untuk mencapainya tanpa itu!

EDIT 2: ya, secara teknis Anda dapat menulis tes sesudahnya; tapi saya masih menganggap test-first/TDD sebagai hal mendasar. Bukan karena Anda tidak bisa "gesit" tanpanya, tetapi karena Anda akan lagi gesit dengannya. Test-first/test-driven adalah pendekatan yang jauh lebih efisien daripada test-later/test-afterthought. Deskripsi tes adalah persyaratan. Jangan menunda sampai nanti ;-)

EDIT 3: Saya akhirnya menemukan apa yang mengganggu saya tentang jawaban Murph yang ditulis dengan sangat baik. Gagasan bahwa seseorang bisa "menjadi gesit" tanpa benar-benar melakukannya. Dan "melakukannya" (seperti yang ditunjukkan di atas) cukup banyak membutuhkan TDD.

5
Steven A. Lowe

Anda bisa gesit, tetapi mungkin ada ruang untuk perbaikan.

Salah satu prinsip gesit adalah Anda harus mampu merespons perubahan. Ini berarti tidak tahu sebelumnya apa yang harus Anda bangun. Jika Anda mengikuti proses air terjun, Anda akan tahu x bulan sebelumnya apa yang Anda butuhkan untuk membangun, dan Anda dapat merancang komponen perangkat lunak individual sehingga mereka masing-masing mengambil bagian dalam skema yang lebih besar, mencapai produk akhir (setidaknya Anda akan berpikir bahwa begitu). Tetapi karena lincah menentukan bahwa Anda tidak tahu apa produk akhirnya, Anda tidak pernah tahu kode apa yang akan Anda gunakan, dan yang lebih penting, kapan akan diubah.

Oleh karena itu Anda memerlukan rangkaian uji menyeluruh untuk memastikan bahwa fitur yang sudah Anda bangun terus berfungsi ketika basis kode dimodifikasi.

Tapi itu sendiri bukan TDD. Jika Anda menulis tes setelah Anda menulis kode, itu bukan TDD. Tapi TDD membantu dengan aspek lain, itu mencegah kelebihan produksi.

Di tim tangkas saya sendiri, saya telah berjuang dengan pengembang menulis kode yang mereka percaya akan berguna nanti dalam proyek. Seandainya itu pengembangan air terjun yang mungkin akan baik-baik saja, karena mereka menambahkan dukungan untuk sesuatu dalam rencana proyek untuk x bulan berikutnya.

Tetapi jika Anda mengikuti prinsip-prinsip lincah Anda tidak boleh menulis kode ini, karena Anda tidak tahu apakah itu akan diperlukan. Fitur yang direncanakan untuk minggu depan tiba-tiba dapat ditunda tanpa batas waktu.

Jika Anda mengikuti prinsip TDD dengan benar, maka satu baris kode tidak dapat ada sebelum tes menentukan baris kode ini (secara pribadi saya dapat menulis beberapa kode sepele tanpa pengujian), dan jika Anda mulai dengan menulis tes penerimaan, maka Anda hanya menerapkan persis apa yang dibutuhkan untuk menghadirkan fitur yang diperlukan.

Jadi TDD membantu menghindari produksi berlebih, memungkinkan tim menjadi seefektif mungkin, yang juga merupakan prinsip lincah inti.

Perangkat lunak yang berfungsi adalah ukuran utama dari kemajuan

2
Pete

Secara ketat, Anda gesit dengan mematuhi manifestasi tangkas . Dalam praktiknya, basis kode tidak gesit kecuali memiliki cakupan pengujian yang baik. Anda dapat melakukan TDD dan menulis tes sebelum/selama pengembangan fungsionalitas atau menulis tes untuk fungsionalitas setelah dikembangkan. Biasanya lebih mudah dan lebih efektif untuk melakukannya dengan cara TDD.

2
Alb

Bisakah Anda Agile tanpa melakukan TDD (test driven development)?

Jawaban singkat: Ya.

Jawaban yang lebih panjang: Sudah ada banyak jawaban yang sangat bagus untuk pertanyaan ini dan referensi yang sangat bagus. Saya tidak akan mencoba memperdebatkan poin-poin itu.

Dalam pengalaman saya, Agile adalah tentang memilih tingkat Lean-ness yang tepat untuk proyek yang sedang dikerjakan. Apa yang saya maksud dengan Lean-ness? Dan, mengapa saya membawanya ke jawaban ini?

Lean tidak berarti memotong segala sesuatu yang mungkin dari metode Anda. Seperti yang dicatat oleh salah satu rekan kami, Anda tidak harus memasukkan TDD atau Tes Unit ke dalam perilaku Anda. Namun, dalam konteks proyek Anda menemukan diri Anda, itu mungkin bermanfaat atau tidak.

Mari kita pikirkan tentang rantai pasokan untuk pengecer besar tanpa nama yang berlokasi di AK. Ada konsumennya. Mereka pergi ke toko. Toko menerima berbagai produk melalui truk. Truk-truk, mungkin, mendapatkan produk-produk dari gudang. Gudang diisi oleh pengiriman dari berbagai produsen. Pabrikan pada gilirannya memiliki seluruh rantai pasokan sendiri.

Apa yang terjadi ketika manajer umum untuk pengiriman dalam rantai pasokan di atas diberitahu bahwa dia akan mendapatkan bonus tahunan $ 1 juta untuk setiap tahun bahwa dia memiliki kurang dari 10 truk dalam armada? Dia akan segera memotong armada menjadi 9 truk. Dalam skenario "mengerikan" ini, ini akan menaikkan jumlah barang yang disimpan di gudang (menaikkan biaya di simpul itu). Dan, itu akan "kelaparan" bagian depan toko.

Jadi, keseluruhan rantai pasokan menderita jika optimalisasi lokal diizinkan tanpa pertimbangan keseluruhan.

Kembali ke TDD dan UT. TDD adalah mekanisme ekspresi persyaratan. Sistem HARUS melakukan kendala tersebut. Cukup adil. TDD dapat menggantikan perilaku persyaratan Use Case Drive Development atau perilaku persyaratan User Story Driven Development. Ini memiliki "condong" manfaat menggabungkan Uji Unit dan Persyaratan beban kerja. Merupakan keuntungan jika beban kerja keseluruhan dikurangi. Tidak, jika beban kerja keseluruhan rantai pasokan meningkat (mari memperbaiki kualitas).

Jadi, Anda bertanya: Bisakah Anda Agile tanpa melakukan TDD (test driven development)?

Tentu kamu bisa. Pertanyaan yang berbeda, dan mungkin lebih baik, adalah: - Jika saya menerapkan TDD untuk proyek ini, apakah ini akan menghasilkan pengiriman perangkat lunak yang lebih efisien secara keseluruhan atau kurang efisien?

Mengutip penulis favorit ... J.R.R. Tolkien

Lord of the Rings. Persekutuan Cincin. Hal 94 'Dan juga dikatakan', jawab Frodo, 'Jangan pergi ke peri untuk meminta nasihat, karena mereka berdua tidak akan dan ya.'

Jadi, pada akhirnya, ... itu tergantung. Anda harus menjawab pertanyaan itu. Jalur mana yang paling efisien akan mengarahkan Anda ke tujuan yang Anda inginkan.

Ke TDD atau tidak ke TDD. Itu tetap menjadi pertanyaan. :-)

PS - Saya memposting ulang jawaban ini di situs lain juga. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en

1
M Kevin McHugh

Dibandingkan dengan rekayasa kastil.

Kastil Agile

Jika Anda seorang insinyur kastil menggunakan Agile. Anda akan menulis bagian yang memiliki fungsi spesifik dan mendorong pengguna untuk menggunakan bagian fungsional, menyesuaikan desain masa depan dengan reaksi pengguna. Jadi, Anda membangun penjara bawah tanah, dan berkomunikasi dengan penjaga penjara bawah tanah, Anda akan menguji fondasi yang disediakan oleh tanah dan penjara bawah tanah. Anda akan membangun tembok pembatas dan bertanya kepada penjaga malam apakah itu bagus. Anda akan membangun tembok dan meminta tentara menguji nilai pertahanan. Anda akan membangun dapur dan meminta koki memeriksanya. Dan selama proses ini, setiap bagian hingga saat ini akan berfungsi di samping struktur saat ini. Jadi, ketika Anda selesai di ruang bawah tanah, Anda bisa memindahkan para tahanan. Dan seterusnya. Tetapi ketika Anda akhirnya menyelesaikan kastil, Anda menemukan para tahanan melarikan diri. Sekarang Anda harus kembali ke ruang bawah tanah dan mencari tahu bahwa Anda membutuhkan palang yang lebih tebal, tetapi pintunya tidak cukup dalam untuk menahan palang, dan engselnya tidak mendukung pintu yang lebih besar.

Kastil TDD

Dengan TDD, Anda muncul bersama para tahanan, dan melihat apakah mereka melarikan diri. Kemudian Anda menulis sel penjara sampai mereka tidak bisa melarikan diri. Kemudian Anda akan melakukan refactor kode dengan bersih menghapus sel yang tidak dibutuhkan, dan menghapus bar yang berada di lokasi yang salah, dan menguji lagi. Tahanan tidak melarikan diri. Anda tidak harus berkomunikasi dengan kepala penjara. Dan Anda bisa mengirimkan seluruh kastil setelah Anda menyelesaikan semuanya. Pada saat itu kepala penjara mengatakan bahwa penjara bawah tanah membutuhkan lebih banyak sel, dan sekarang Anda harus menggali lebih banyak fondasinya.

Kastil TDD Agile

Jika Anda menggabungkan Agile dan TDD. Anda akan melihat apakah para tahanan melarikan diri, lalu bertanya kepada kepala penjara apa yang dibutuhkan. Dia mengatakan kamu membutuhkan lebih banyak sel. Anda akan mengambil beberapa orang acak untuk berpura-pura menjadi tahanan dan melihat apakah mereka melarikan diri. Jika tidak, maka Anda menunjukkannya ke kepala penjara, dan dia senang dengan itu. Kemudian Anda mulai membangun tembok pembatas.

Kesimpulan

Jadi keduanya memecahkan masalah yang berbeda. Agile membantu dengan mengubah persyaratan berdasarkan pada menemukan kebutuhan pengguna karena mereka melihat produk berkembang pada titik dalam proses yang paling mudah untuk beradaptasi. Ini melibatkan melepaskan penambahan stabil yang dipecah dari desain keseluruhan.

TDD memecahkan masalah mengantisipasi kegagalan. Menemukan dan memperbaiki kegagalan saat terjadi pada suatu titik dalam proses yang paling mudah untuk diperbaiki. Ini melibatkan pengujian unit de-coupled yang stabil dari kode yang dipecah dari desain keseluruhan.

Sangat mudah untuk melihat TDD sebagai ekstensi untuk Agile, karena keduanya mengikuti pola yang sama, kemajuan unit didorong dan ulasan. Perbedaannya adalah bahwa unit-unit dalam Agile berfungsi secara eksternal hingga saat ini secara keseluruhan, sedangkan unit-unit dalam TDD berfungsi sebagai bagian, dan mungkin tidak menghasilkan produk yang berfungsi untuk tinjauan eksternal. Dan kedua proses mengatur kebutuhan yang berbeda (kegunaan vs kebenaran). Karena keduanya berfungsi atas proses pengembangan dalam unit, kedua proses peninjauan dapat terjadi pada titik yang sama, dengan TDD yang lebih halus dibagi.

Catatan

  • Memiliki unit test saja tidak berarti Anda menggunakan TDD. TDD berarti melakukan tes sebelum unit yang diproduksi, dan menggunakan tes saat Anda mengembangkan untuk mengkonfirmasi unit. Pengujian unit tanpa TDD dapat digunakan untuk memastikan Anda tidak membatalkan fungsi yang dibangun sebelumnya.
  • Memiliki sprint dan rapat lainnya tidak membuat Anda gesit. Tujuan dari manifes membuat Anda lincah. Anda dapat memecah tujuan air terjun menjadi sprint dengan unit-of-work, tanpa memenuhi komitmen untuk mendukung orang daripada proses.
  • Secara definisi TDD dan Agile. Unit-tes Anda akan mengatur unit yang tidak dapat dikirim, dan TDD akan berputar lebih cepat dari Agile. Dan jika Anda menggunakan keduanya, siklus Agile Anda akan mengandung satu atau lebih siklus TDD (jika setiap unit diuji).
  • Dari apa yang saya mengerti: Anda gagal Agile dengan gagal mengembangkan unit yang dapat disampaikan/bermakna bagi pengguna. Unit ini bisa bermakna bahkan jika mempercepat produk. Tetapi bagaimana Agile menjelaskan refactoring untuk perawatan yang lebih mudah? Saya belum cukup membahasnya untuk menjawab itu.
  • Anda gagal TDD dengan gagal tes unit. Memproduksi kode yang tidak menghasilkan fitur dengan benar.
1
Lee Louviere

Agile memaksa Anda untuk mengatasi dan mengurangi jadwal dan risiko kualitas di setiap iterasi. yaitu --- TDD tidak perlu dianggap Agile.

Namun, TDD adalah teknik luar biasa untuk mengurangi risiko kualitas, terutama untuk proyek dengan sejumlah besar pengulangan atau orang. Dalam proyek semacam itu, TDD akan menambahkan beberapa risiko jadwal dalam iterasi awal, karena Anda juga harus menulis kasus uji. Namun, TDD menghasilkan penghematan biaya besar dalam iterasi kemudian karena terus mengurangi risiko kualitas. yaitu --- TDD disarankan.

0
Jay Godse