jika Anda membaca semua jawaban, mereka semua setuju. Anda dapat mengklaim menjadi gesit tanpa melakukan TDD, karena 'gesit' adalah manifesto kabur bukan metodologi tertentu. Tapi saya tidak melihat jawaban di bawah ini yang mengatakan "oh ya, tes-pertama tidak diperlukan" ;-)
Steven A. Lowe
Orang bisa melakukannya tanpa TDD, tetapi mengapa melumpuhkan diri sendiri dan berjalan 7 mil di salju?
Pekerjaan
3
@ Pekerjaan - Inilah yang saya maksud. Meskipun "gesit" tidak secara eksplisit menentukan melakukan TDD, apakah itu diterima secara umum, di dunia nyata , bahwa "gesit" termasuk "melakukan TDD" (atau setidaknya pengujian unit)?
CraigTP
2
Mengapa Anda begitu peduli tentang "gesit" ??? Tidakkah Anda memiliki sesuatu yang lebih penting untuk dikhawatirkan, seperti menulis perangkat lunak yang menyenangkan pelanggan Anda?
xpmatteo
1
@ShadowChaser Saya mengerti apa yang Anda katakan, tetapi untuk berperan sebagai penasihat iblis sejenak tentang Agile Point # 1, jika saya berada di tim yang melakukan pengembangan gaya air terjun, tetapi kami memiliki komunikasi dan kolaborasi yang hebat antara anggota itu tim, apakah itu membuat kita gesit?
CraigTP
Jawaban:
50
Ya, ya, ya, jutaan kali ya.
Agile adalah filosofi, TDD adalah metodologi khusus.
Jika saya ingin benar - benar pilih - pilih, saya hanya bisa menunjukkan bahwa ada beberapa variasi xDD - yang akan dijelaskan oleh advokat mereka secara mendalam 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 Tes Pertama tanpa menjadi Agile dan argumen yang kuat untuk melakukan tes pertama terlepas dari keseluruhan filosofi dev Anda.
Tampaknya orang lain (dengan rep yang lebih SOLID) memiliki pendapat yang sama ...
+1 untuk ini Anda lincah dengan cara umum Anda bertindak, bukan karena Anda menggunakan metodologi itu atau itu.
10
Tes unit harus gesit. Hanya saja Anda tidak perlu menulisnya terlebih dahulu.
Macneil
6
@ Mcneil: Anda tidak perlu menulis unit test untuk "gesit". TDD dan UT adalah praktik yang hebat sendiri, tetapi tidak diperlukan atau bahkan disebutkan dalam manifesto tangkas.
Martin Wickman
4
@Marin: tidak ada pengembangan metode sama sekali disebutkan dalam manifesto
Steven A. Lowe
4
Saya baru saja mulai bekerja di perusahaan besar menggunakan SCRUM untuk menjalankan proyek. Proyek yang saya kerjakan adalah SCRUM (benar!) Tetapi kode tidak memiliki unit test. Tidak memiliki unit test tidak mempengaruhi kemampuan untuk menggunakan SCRUM atau menjadi Agile, tetapi itu mempengaruhi kemampuan saya untuk percaya diri pada kualitas kode serta untuk dengan cepat melakukan perubahan (dengan percaya diri). Mengingat kurangnya dokumentasi yang dihasilkan di Agile, saya pikir tes menulis pertama, terakhir, atau di tengah adalah manfaat besar untuk tetap Agile (untuk berubah).
Rob Gray
19
"Menjadi gesit" hanya berarti mengikuti nilai-nilai dan prinsip-prinsip manifesto 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.
@ Martin: kata baik - tidak ada praktik pengembangan yang ditentukan dalam manifesto. Itu pernyataan misi, bukan metodologi.
Steven A. Lowe
4
@ Martin: Ada perbedaan antara proses lincah dan prinsip lincah. Jika Anda dapat menyebutkan proses lincah yang tidak memiliki tes, maka silakan lakukan.
Macneil
@ Macneil: Scrum tidak memiliki tes.
Martin Wickman
2
@ Martin: sekali lagi, Scrum adalah metode manajemen proyek , bukan metodologi pengembangan perangkat lunak. Scrum biasanya digunakan dengan metodologi pengembangan Agile seperti XP, tetapi bukan pengganti
Steven A. Lowe
@ Sebelas: Terima kasih telah menjelaskan jawaban saya bahwa Scrum tidak mengandung praktik pengembangan seperti pengujian. Saya pikir intinya sudah siap sekarang :-)
Martin Wickman
11
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 standar de facto untuk menjadi gesit
Jika Anda kembali ke sumber aslinya http://en.wikipedia.org/wiki/Extreme_Programming TDD adalah hal mendasar dalam prosesnya; 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 tentang pertanyaan tampaknya menjadi yang disukai. Heck, saya bahkan mengangkatnya, itu jawaban yang bagus. Namun , saya mempertahankan posisi saya bahwa Agile Manifesto adalah seperangkat 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. 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 lebih gesit dengannya. Test-first / test-driven adalah pendekatan yang jauh lebih efisien daripada test-later / test-afterthought. Deskripsi tes adalah persyaratannya . 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 "gesit" tanpa benar - benar melakukannya . Dan "melakukannya" (seperti yang ditunjukkan di atas) cukup banyak membutuhkan TDD.
Tidak ada tempat di halaman itu yang disebut TDD atau Test First kecuali sebagai tautan ke halaman terkait.
Murph
2
Saya bekerja sebagai programmer ekstrim pada 2000-2001. Ya kami menulis unit test, tetapi hampir selalu menulis kode terlebih dahulu, dan kemudian menguji kode itu setelahnya.
Michael Shaw
1
Pilihan kata yang salah. Mari kita perbaiki: Agile bukan hanya Extreme Programming; Scrum dan Kanban juga dapat dilihat sebagai metodologi yang gesit dan tak satu pun dari mereka memaksakan penggunaan TDD seperti XP
t3mujin
2
@ Murph: kalimat pertama yang penting. @Ptolemy: lalu kamu salah ;-) @ t3mujin kamu pasti bercanda!
Steven A. Lowe
4
+1: Saya terlambat ke pesta, tapi ini satu-satunya jawaban yang berguna . Mengatakan bahwa kita dapat melakukan TDD tanpa tes sama seperti mengatakan kita dapat lulus ujian driver tanpa tahu cara mengemudi. Ya, itu mungkin, tetapi sulit. Seperti yang dikatakan Michael Feathers , "Legacy Code adalah kode tanpa tes". Dan kode yang, menurut definisi, sulit untuk dipelihara, juga sulit untuk dikerjakan ketika Anda menggunakan proses berulang yang gesit.
rsenna
2
Ketat, Anda gesit dengan mengikuti manifesto 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.
Anda bisa gesit, tetapi mungkin ada ruang untuk perbaikan.
Salah satu prinsip gesit adalah bahwa 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 agile menentukan bahwa Anda tidak tahu apa produk akhirnya, Anda tidak pernah tahu untuk apa kode Anda akan digunakan, dan yang lebih penting, kapan akan diubah.
Oleh karena itu Anda memerlukan rangkaian uji menyeluruh untuk memastikan bahwa fitur yang sudah Anda buat 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.
Dalam tim tangkas saya sendiri, saya telah berjuang dengan pengembang menulis kode yang mereka percaya akan berguna nantinya 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 kelebihan produksi, memungkinkan tim menjadi seefektif mungkin, yang juga merupakan prinsip lincah inti.
Perangkat lunak yang berfungsi adalah ukuran utama dari kemajuan
Bisakah Anda gesit 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 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 itu, mungkin, mengambil produk-produk itu 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 ia akan mendapat bonus tahunan $ 1 juta untuk setiap tahun bahwa ia 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 optimisasi lokal diizinkan tanpa pertimbangan keseluruhan.
Kembali ke TDD dan UT. TDD adalah mekanisme ekspresi persyaratan. Sistem HARUS melakukan kendala tersebut. Cukup adil. TDD dapat mengganti 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 kita perbaiki kualitas).
Jadi, Anda bertanya: Bisakah Anda Agile tanpa melakukan TDD (test driven development)?
Tentu kamu bisa. Sebuah pertanyaan yang berbeda, dan mungkin lebih baik, adalah: - Jika saya menerapkan TDD pada proyek ini, apakah ini akan menghasilkan pengiriman perangkat lunak yang lebih efisien secara keseluruhan atau kurang efisien?
Mengutip penulis favorit ... JRR 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. :-)
Jika Anda seorang insinyur kastil menggunakan Agile. Anda akan menulis bagian-bagian yang memiliki fungsi spesifik dan mendorong pengguna untuk menggunakan bagian-bagian fungsional, menyesuaikan desain masa depan dengan reaksi-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.
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 penemuan 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 peninjauan 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-orang dari proses.
Secara definisi TDD dan Agile. Unit-tes Anda akan mengatur unit yang tidak dapat dikirim, dan TDD akan berputar lebih cepat daripada 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 dapat bermakna bahkan jika itu 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.
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 selanjutnya karena terus mengurangi risiko kualitas. yaitu TDD direkomendasikan.
Jawaban:
Ya, ya, ya, jutaan kali ya.
Agile adalah filosofi, TDD adalah metodologi khusus.
Jika saya ingin benar - benar pilih - pilih, saya hanya bisa menunjukkan bahwa ada beberapa variasi xDD - yang akan dijelaskan oleh advokat mereka secara mendalam 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 Tes Pertama tanpa menjadi Agile dan argumen yang kuat untuk melakukan tes pertama terlepas dari keseluruhan filosofi dev Anda.
Tampaknya orang lain (dengan rep yang lebih SOLID) memiliki pendapat yang sama ...
http://www.twitter.com/unclebobmartin/status/208621409663070208
(Tautan dalam tweet ini adalah jawaban lengkap di LinkedIn)
sumber
"Menjadi gesit" hanya berarti mengikuti nilai-nilai dan prinsip-prinsip manifesto 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 ...
sumber
Ya ,
Lihatlah salah satu nilai lincah:
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 standar de facto untuk menjadi gesit
Mungkin ada cara menjadi gesit tanpa TDD
sumber
Saya katakan
Tidak ada [semacam]
Jika Anda kembali ke sumber aslinya http://en.wikipedia.org/wiki/Extreme_Programming TDD adalah hal mendasar dalam prosesnya; 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 tentang pertanyaan tampaknya menjadi yang disukai. Heck, saya bahkan mengangkatnya, itu jawaban yang bagus. Namun , saya mempertahankan posisi saya bahwa Agile Manifesto adalah seperangkat prinsip, bukan metodologi pengembangan. Saya melihat tidak ada gunanya mengatakan "oh ya saya gesit" tanpa benar-benar menerapkan praktik yang membawa manfaat. Khususnya:
dan
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 lebih gesit dengannya. Test-first / test-driven adalah pendekatan yang jauh lebih efisien daripada test-later / test-afterthought. Deskripsi tes adalah persyaratannya . 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 "gesit" tanpa benar - benar melakukannya . Dan "melakukannya" (seperti yang ditunjukkan di atas) cukup banyak membutuhkan TDD.
sumber
Ketat, Anda gesit dengan mengikuti manifesto 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.
sumber
Anda bisa gesit, tetapi mungkin ada ruang untuk perbaikan.
Salah satu prinsip gesit adalah bahwa 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 agile menentukan bahwa Anda tidak tahu apa produk akhirnya, Anda tidak pernah tahu untuk apa kode Anda akan digunakan, dan yang lebih penting, kapan akan diubah.
Oleh karena itu Anda memerlukan rangkaian uji menyeluruh untuk memastikan bahwa fitur yang sudah Anda buat 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.
Dalam tim tangkas saya sendiri, saya telah berjuang dengan pengembang menulis kode yang mereka percaya akan berguna nantinya 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 kelebihan produksi, memungkinkan tim menjadi seefektif mungkin, yang juga merupakan prinsip lincah inti.
sumber
Bisakah Anda gesit 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 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 itu, mungkin, mengambil produk-produk itu 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 ia akan mendapat bonus tahunan $ 1 juta untuk setiap tahun bahwa ia 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 optimisasi lokal diizinkan tanpa pertimbangan keseluruhan.
Kembali ke TDD dan UT. TDD adalah mekanisme ekspresi persyaratan. Sistem HARUS melakukan kendala tersebut. Cukup adil. TDD dapat mengganti 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 kita perbaiki kualitas).
Jadi, Anda bertanya: Bisakah Anda Agile tanpa melakukan TDD (test driven development)?
Tentu kamu bisa. Sebuah pertanyaan yang berbeda, dan mungkin lebih baik, adalah: - Jika saya menerapkan TDD pada proyek ini, apakah ini akan menghasilkan pengiriman perangkat lunak yang lebih efisien secara keseluruhan atau kurang efisien?
Mengutip penulis favorit ... JRR Tolkien
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
sumber
Dibandingkan dengan rekayasa kastil.
Kastil Agile
Jika Anda seorang insinyur kastil menggunakan Agile. Anda akan menulis bagian-bagian yang memiliki fungsi spesifik dan mendorong pengguna untuk menggunakan bagian-bagian fungsional, menyesuaikan desain masa depan dengan reaksi-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.
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 penemuan 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 peninjauan 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
sumber
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 selanjutnya karena terus mengurangi risiko kualitas. yaitu TDD direkomendasikan.
sumber