Agile tanpa tes unit


27

Apakah masuk akal untuk berbicara tentang "pengembangan tangkas" atau mengklaim bahwa Anda menerapkan "metodologi tangkas" jika basis kode yang Anda kerjakan memiliki cakupan uji unit 0%? (Dan Anda, sebagai tim, tidak melakukan apa-apa tentang itu).

Untuk memperjelas: bagi saya, itu tidak masuk akal. Dalam pengalaman pribadi saya, saya menemukan bahwa tes unit adalah satu-satunya alat yang memungkinkan Anda untuk benar-benar "gesit" (yaitu menanggapi perubahan, meningkatkan desain Anda, berbagi pengetahuan, dll ...) dan TDD adalah satu-satunya latihan yang membawa Anda ke sana .

Mungkin ada beberapa cara lain, tetapi saya masih tidak bisa melihat bagaimana mereka bisa bekerja.


14
Agile memiliki peluang lebih besar untuk berhasil dengan pengujian otomatis untuk mendukungnya. Saya terpaksa menerapkan Agile tanpa tes sebelumnya dan ini jebakan. Ini hanya cara mudah untuk mengakumulasi hutang teknis lebih cepat dari sebelumnya.
MetaFight

5
TDD belum tentu satu - satunya latihan yang membawa Anda ke sana. Itu adalah hal yang biasa. Secara pribadi, saya menemukan BDD menjadi pendekatan yang lebih pragmatis.
MetaFight

6
"Agile memiliki peluang lebih besar untuk berhasil dengan pengujian otomatis untuk mendukungnya": begitu juga proyek-proyek non-gesit, dalam hal ini. Saya pikir pengujian otomatis agak ortogonal dengan metodologi yang digunakan: itu membuat Anda lebih percaya diri bahwa kode Anda benar dan membantu Anda menjaganya tetap bersih.
Giorgio

By the way pertanyaan ini tes unit campuran dan TDD Anda dapat memiliki tes unit tanpa TDD.
Walfrat

Membaca jawaban di sini, saya terkejut betapa banyak hal telah berubah sejak saya belajar gesit pada pertengahan tahun 00-an. TDD dan pemrograman pasangan dianggap praktik tangkas PENTING untuk mempertahankan kode kualitas tinggi pada kecepatan tinggi.
nomen

Jawaban:


37

Untuk menjadi bertele-tele, tidak ada dalam Agile Manifesto atau Panduan Scrum yang membuat referensi untuk praktik teknis, seperti pengujian unit atau TDD, sama sekali. Jadi, ya, secara teori Anda bisa memberikan awal dan sering dengan fokus pada kolaborasi dan nilai tanpa mereka dan menyebut diri Anda Agile, Anda bahkan mungkin sebenarnya memiliki kelincahan .

Namun dalam praktiknya, hampir tidak mungkin untuk secara konsisten memberikan nilai ( ke dalam produksi ) setiap beberapa minggu tanpa test suite yang baik. Ini termasuk tes integrasi serta tes unit. Tes unit hanya berjalan sejauh ini. Ada alasan mengapa itu piramida dan bukan persegi panjang.

Tanpa tes sebagai jaring pengaman, Anda akan memperkenalkan banyak bug regresi di setiap rilis, atau takut akan refactoring. Keduanya akan sangat memengaruhi kemampuan Anda untuk melanjutkan dengan kecepatan yang berkelanjutan . Jika Anda tidak dapat mempertahankan langkah Anda atau mengubah kursus (mendesain ulang) saat diperlukan, maka Anda tidak memiliki kelincahan. Bagaimanapun, kelincahan adalah tujuan yang kita perjuangkan.


Apakah Anda harus mengikuti Manifesto Agile untuk menjadi gesit?
JeffO

Tidak ada @JeffO. Anda tidak, tetapi tentu saja membantu. Saya mengedit untuk menjelaskan maksud saya.
RubberDuck

1
IMO programmer yang paling gesit adalah mereka yang sangat pragmatis walaupun mereka belum pernah mendengar manifesto lincah.
Giorgio

1
Saya tidak bisa tidak setuju dengan Anda di sana @iorgio. Saya berada di tim lincah bertahun-tahun sebelum salah satu dari kami pernah mendengar tentang Agile.
RubberDuck

2
@CortAmmon - Jika Anda ingin mendefinisikan Agile (agile besar "A" seperti dalam metodologi Anda), saya akan setuju dengan Anda, tetapi jika Anda ingin gesit ("sedikit" seperti dalam benar-benar gesit sehingga Anda dapat menangani perubahan lebih baik ), maka Anda tidak harus mengikuti metodologi tertentu sama sekali. Jika Anda bisa melakukan air terjun dan masih menangani perubahan (sulit, tetapi bukan tidak mungkin), siapa yang peduli?
JeffO

30

Manifesto tangkas hanya menyatakan:

Individu dan interaksi atas proses dan alat

Bekerja perangkat lunak melalui dokumentasi komprehensif

Kolaborasi pelanggan atas negosiasi kontrak

Menanggapi perubahan setelah mengikuti rencana

Tidak disebutkan unit test di sana. Bahkan 12 prinsip tidak menyebutkan pengujian.

Jadi, secara teknis, mungkin untuk menjadi tim yang gesit tanpa menulis unit test. Namun dalam praktiknya, sangat sulit untuk melihat bagaimana sebuah tim dapat mempertahankan perangkat lunak yang berfungsi di lingkungan yang gesit tanpa tes untuk membantu mereka dalam membuat perubahan konstan.


4
Sulit untuk melihat bagaimana tim dapat mempertahankan perangkat lunak yang berfungsi di lingkungan apa pun tanpa tes.
Bryan Oakley

6
Hanya karena sesuatu yang sulit dilihat tidak membuatnya mustahil
Ampt

8

Meskipun tidak ada kata langsung yang menyatakan tentang pengujian unit atau TDD atau jenis tes apa pun dalam manifesto tangkas seperti yang dijawab orang lain di sini, saya percaya bahwa Scrum Master atau Pengembang yang baik akan dapat melihat salah satu pernyataan dalam manifesto.

Bekerja dengan perangkat lunak Ā melalui dokumentasi yang komprehensif.

Bagaimana orang tahu jika perangkat lunak ini berfungsi? Manifes tidak perlu secara eksplisit menyatakan istilah pengujian. Ini singkat.

Pengujian unit (dalam konteks topik) akan membuat fase pengkodean Anda lambat pada tahap sebelumnya tetapi akan sia-sia saat Anda maju, membuat pengembangan menjadi jauh lebih cepat dan maju. Ini memberi Anda kontrol butiran halus pada pengujian level kode serta membuat skalabilitas desain Anda, memberi Anda kepercayaan diri bahwa perangkat lunak Anda berfungsi dan dapat dengan mudah menangani regresi; yang akan membuat pengembangan Anda gesit.


3
Anda dapat mengujinya secara manual. Anda tidak perlu tes unit untuk itu. Mereka membantu. BANYAK. Mereka seperti hal utama yang dapat meningkatkan proses. Tetapi mereka sama sekali tidak penting untuk memberikan perangkat lunak.
T. Sar - Pasang kembali Monica

Ya tentu saja. Saya tidak mengatakan Anda tidak dapat melakukannya secara manual. Saya memang mengatakan tes apa pun. Saya tidak menyatakan segala bentuk perselisihan dalam pengujian. Dan untuk pengujian manual Anda, ada pada perspektif yang berbeda pada akhirnya tentang bagaimana Anda bisa tetap gesit saat menghadapi regresi.
Axel

Saya mengerti sudut pandang Anda. Namun, pertanyaannya adalah tentang unit test khusus, bukan tes umum. Membaca jawaban Anda pada konteks pertanyaan membuat orang menganggap pengujian Anda sebagai "pengujian unit"!
T. Sar - Pasang kembali Monica

Di sana, maaf untuk itu.
Axel

2
@ThalesPereira, unit test yang memberi tahu Anda apakah perubahan yang Anda buat empat puluh detik yang lalu memecahkan sesuatu jauh lebih lincah daripada laporan yang Anda dapatkan kembali dari departemen QA yang memberi tahu Anda bahwa ada sesuatu yang diubah seseorang tiga hari yang lalu yang memecahkannya.
Solomon Slow

2

Ini sangat masuk akal. Agile bukan tentang pengujian, seperti yang telah disebutkan orang lain, tetapi untuk secara khusus menjawab pertanyaan Anda:

Tidak, Anda tidak perlu pengujian unit sama sekali.

Anda dapat menjalankan proses yang gesit dengan pengujian integrasi saja. Anda dapat menjalankan tes integrasi otomatis setiap malam misalnya dan memperbaiki bug yang ditemukan pada hari berikutnya. Anda bisa meminta tester manual yang menjalankan tes integrasi secara terus menerus jika Anda mau. Terlepas dari sistem, pengujian unit sepenuhnya opsional.

Anda mungkin menemukan pengujian unit membantu Anda berkembang, dan cukup adil untuk itu, tetapi ada banyak hal yang dapat membantu pengembangan yang mungkin tidak Anda miliki.

Anda memang membutuhkan beberapa bentuk pengujian, bahkan jika itu adalah 'penguji beta pelanggan' yang lama. Jika pelanggan Anda sangat terlibat dalam proses dan tidak keberatan menemukan bug, maka ini bisa berhasil - karena mereka cenderung menemukan bug yang bahkan orang lain pun tidak menganggapnya bug!


Anda dapat menjalankan proses yang gesit dengan pengujian integrasi saja. Apakah ini teoretis atau diucapkan dari pengalaman?
R Sahu

1

Itu tidak wajib. Pengujian sangat bagus ketika Anda memiliki orang yang benar-benar tahu cara menggunakannya. Ketika Anda tidak, tidak hanya itu tidak perlu, itu menjadi kewajiban. Saya akan mengatakan ada banyak programmer yang tidak terlalu ahli dalam hal itu.

Saya senang Anda mengakui dalam pertanyaan Anda bahwa menjadi gesit adalah tentang bagaimana Anda benar-benar merilis perangkat lunak alih-alih mengikuti beberapa metodologi. Agile Manifesto adalah referensi yang bagus, tapi itu bukan panduan yang pasti. Tangkas ada sebelum itu. Ada beberapa cara untuk mengembangkan perangkat lunak agar "lebih gesit" tetapi kombinasi yang berbeda dapat digunakan pada berbagai proyek.

Jika Anda merilis perangkat lunak baru dengan kecepatan yang dapat diterima oleh klien, Anda mungkin gesit. Saya juga akan memasukkan tidak memiliki terlalu banyak push-back dan mengeluh tentang perubahan fitur oleh pengembang. Memperbaiki satu hal hanya untuk merusak yang lain juga tidak ideal. Ketika Anda pengguna adalah beberapa versi di belakang dalam peningkatan, Anda mungkin tidak sangat gesit apakah Anda menguji atau tidak.


1

Saya ingin membantah argumen (jawaban lain) bahwa manifesto Agile jelas menyatakan sesuatu tentang ini, yaitu:

Perhatian terus menerus terhadap keunggulan teknis dan desain yang baik meningkatkan kelincahan.

Saya sangat suka definisi LeSS tentang keunggulan teknis dan itu termasuk pengujian unit dan TDD. Sekarang Anda dapat berdebat bahwa Anda mungkin tidak memerlukan unit-tes dan atau TDD untuk mencapai ini, tetapi ini adalah cara yang paling umum dan mungkin disarankan.

Agility Organisasi dibatasi oleh Agility Teknis

Dengan kata lain, ketika Anda lambat dalam membuat perubahan pada produk Anda, maka tidak masalah bagaimana Anda menyusun tim Anda, organisasi Anda atau kerangka kerja apa yang Anda adopsi, Anda akan lambat menanggapi perubahan.

Jika Anda dapat mencegah produk Anda dari menolak perubahan dengan cara lain Anda mungkin berada di jalur yang benar, tetapi:

Saya menemukan Extreme Programming untuk membuat dunia aman bagi programmer. - Kent Beck

Scrum tidak memiliki praktik teknis, tetapi Jeff mengatakan yang berikut tentang hal itu:

Saya belum pernah melihat tim Scrum yang sangat produktif yang tidak menggunakan praktik pengembangan Extreme Programming. - Jeff Sutherland

Dikutip dari artikel ini: http://ronjeffries.com/articles/017-02ff/gathering2017/

Saya berharap tim Scrum tanpa praktik teknis pada akhirnya dengan menggunakan retrospektif datang dengan praktik serupa. Anda ingin menjadi terlalu produktif, bukan?

Model Agile fluence , menyebutkannya di tingkat dua bintang:

Teknik yang berguna meliputi integrasi berkelanjutan, pengembangan yang digerakkan oleh tes , pemrograman pasangan, dan kepemilikan kolektif.

Jika Anda hanya menargetkan tingkat kefasihan Agile pertama Anda dapat melewati praktik tersebut, tetapi produk yang lebih besar dan lebih lama berjalan setidaknya harus mencoba mencapai level dua bintang.

Jadi konsensus umum adalah ya tanpa pengujian unit yang baik, kode bersih dan praktik refactor, saat ini tidak mungkin untuk benar-benar Agile. Ini mungkin berubah di masa mendatang saat praktik teknis baru muncul.

Menurut Anda apa jawabannya jika kita bertanya kepada beberapa orang yang menandatangani manifesto seperti Robert C. Martin, Martin Fowler atau Kent Beck? Mungkin mereka akan mengatakan itu tergantung, tetapi umumnya itu adalah sesuatu yang harus Anda lakukan.


1
kenyataannya, itu tidak harus menjadi "unit-test" Anda hanya bisa menjalankan tes integrasi dan menganggap itu sudah cukup. Namun, jika Anda tidak memiliki apa-apa dan menguji semuanya secara manual, kemungkinan besar Anda akan lambat merespons perubahan dengan cepat, atau memberikan banyak regresi secara teratur.
Walfrat

2
Setuju secara teknis tidak, tetapi tes pada tingkat yang lebih tinggi seringkali lebih rapuh, lebih sulit untuk dipertahankan dan mungkin memperlambat Anda pada akhirnya jika Anda harus melakukannya. Saya suka bagaimana Martin Fowler mengatakannya: "Jika Anda mendapatkan kegagalan dalam tes tingkat tinggi, Anda tidak hanya memiliki bug dalam kode fungsional Anda, Anda juga memiliki tes unit yang hilang atau salah." from martinfowler.com/bliki/TestPyramid.html
Niels van Reijmersdal

Tes pada level yang lebih tinggi tidak menguji hal-hal yang sama, sehingga Anda membiarkan lubang tetapi pertimbangkan bahwa saat ini risikonya cukup layak. Untuk beberapa situs web yang mungkin cukup, untuk sistem keuangan kritis -> tidak mungkin.
Walfrat
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.