Metodologi: Tes unit penulisan untuk pengembang lain

28

Saya berpikir tentang pengembangan perangkat lunak dan tes unit penulisan. Saya mendapat ide berikut:

Mari kita asumsikan kita memiliki pasangan pengembang. Setiap pasangan bertanggung jawab atas bagian dari kode. Satu dari pasangan mengimplementasikan fitur (menulis kode) dan yang kedua menulis tes unit untuk itu. Tes ditulis setelah kode. Menurut saya mereka saling membantu, tetapi bekerja agak terpisah. Idealnya mereka akan bekerja pada dua fitur berukuran serupa dan kemudian ditukar dengan persiapan tes.

Saya pikir ide ini memiliki beberapa kelebihan:

  • tes ditulis oleh seseorang, yang dapat melihat lebih banyak tentang implementasinya,
  • pekerjaan harus dibuat sedikit lebih cepat daripada pemrograman pasangan (dua fitur pada saat yang sama),
  • baik tes dan kode memiliki orang yang bertanggung jawab untuk itu,
  • kode diuji oleh setidaknya dua orang, dan
  • mungkin mencari kesalahan dalam kode yang ditulis oleh orang yang menguji kode Anda akan memberikan motivasi khusus untuk menulis kode yang lebih baik dan menghindari memotong sudut.

Mungkin juga merupakan ide bagus untuk menambahkan pengembang lain untuk ulasan kode antara pengembangan kode dan tes.

Apa kelemahan ide ini? Apakah sudah digambarkan sebagai metodologi yang tidak diketahui dan digunakan dalam pengembangan perangkat lunak?

PS. Saya bukan manajer proyek profesional, tetapi saya tahu sesuatu tentang proses pengembangan proyek dan tahu beberapa metodologi paling populer - tetapi ide ini tidak terdengar asing bagi saya.

unit-testing methodology franiis
sumber
17
Anda baru saja menjelaskan QA hilir di tingkat unit. Jika Anda memiliki pasangan orang yang mengerjakan sesuatu, apakah Anda sudah mencoba pemrograman pasangan sebenarnya dengan TDD?
jonrsharpe
9
Ini akan bekerja lebih baik jika penulis tes akan melakukan tes pertama (tulis kode kerangka) dan yang lainnya menerapkan fungsi. Yang pertama akan mengendalikan desain dan yang lainnya akan melakukan pengangkatan berat. Itu bisa bekerja dengan baik jika yang pertama tahu apa yang dia lakukan dan yang kedua tidak keberatan mengikuti petunjuknya sepanjang waktu. Saya tidak tahu tentang nama untuk cara kerja sama seperti ini. Saya akan mengatakan .. mengklaimnya! Mulai panggil perkembangan Franiis ini.
Martin Maat
14
Kritik itu tidak masuk akal, dan saran Anda tidak menyelesaikan masalah itu.
jonrsharpe
5
@franiis Saya pernah melihat rekan menulis assert truesebagai tes dan menyebutnya sehari karena setiap tes lulus. Satu langkah penting hilang: tes harus gagal dulu, dan harus dilakukan untuk lulus dengan mengubah kode, bukan tes.
Eric Duminil
6
@franiis TDD dibangun di sekitar iterasi. Tes gagal menulis. Tulis kode yang membuat tes menjadi hijau. Refactor. Tulis tes yang gagal. Tulis kode yang membuat tes menjadi hijau. Refactor. Tampaknya Anda melewatkan bagian "ulangi hingga Anda memiliki tes yang mencakup semua kebutuhan Anda". Tetapi masalah terbesar yang tampaknya Anda miliki adalah bahwa "tes" dipandang sebagai sesuatu yang harus Anda miliki karena seseorang mengatakan demikian, daripada tes menjadi alat yang berguna bagi para pengembang . Jika Anda tidak dapat membuat orang peduli dengan kualitas (dan kebenaran) kode mereka, itulah masalah Anda, dan di situlah Anda harus mulai.
Luaan

Jawaban:

30

Pendekatan umum menggunakan pasangan untuk membagi upaya menulis kode produksi dan menulis tes unit terkait tidak biasa. Saya bahkan secara pribadi berpasangan dengan cara ini sebelumnya dengan kesuksesan yang layak. Namun, garis ketat antara orang yang menulis kode produksi dan orang yang menulis kode tes mungkin tidak selalu menghasilkan hasil.

Ketika saya menggunakan pendekatan yang serupa, pasangan mulai dengan berbicara dan mendapatkan pemahaman bersama tentang masalahnya. Jika Anda menggunakan TDD, maka Anda dapat mulai dengan beberapa tes dasar terlebih dahulu. Jika Anda tidak menggunakan TDD, mungkin Anda akan mulai dengan definisi metode. Dari sini, kedua anggota pasangan bekerja pada kode produksi dan kode pengujian, dengan satu orang fokus pada setiap aspek, tetapi berbicara tentang cara untuk meningkatkan kode produksi serta kode pengujian di belakangnya.

Saya tidak melihat keuntungan dari memberikan masing-masing pasangan dua fitur. Yang akhirnya Anda dapatkan adalah sesuatu yang menyerupai TDD untuk beberapa fitur dan sesuatu yang tidak untuk fitur lainnya. Anda kehilangan fokus. Anda tidak mendapatkan manfaat dari peer review real-time. Anda tidak mendapatkan manfaat utama dari pasangan.

Praktik pemrograman pasangan bukan tentang kecepatan, tetapi kualitas. Jadi mencoba menggunakan teknik yang dimodifikasi didorong oleh lebih cepat bertentangan dengan alam. Dengan membangun perangkat lunak berkualitas lebih tinggi melalui peninjauan kode paralel dan pengembangan pengujian, Anda akhirnya menghemat waktu di hilir karena setidaknya ada dua orang dengan pengetahuan tentang setiap perubahan dan Anda menghilangkan (atau mengurangi) siklus menunggu untuk tinjauan dan pengujian rekan.

Thomas Owens
sumber
Terima kasih, ide saya berasumsi bahwa kedua fitur dikembangkan dengan cara yang sama (tetapi pengembang bertukar peran) - hanya untuk memperjelas, bukan untuk mempertahankan rasa konsep itu. Saya suka jawaban Anda dan fokus Anda pada kecepatan vs kualitas.
franiis
Dalam pengalaman saya, biaya pengerjaan ulang lebih besar daripada manfaat dari pendekatan ini. Saya lebih suka memiliki pasangan menukar tugas ini menggunakan 'ping-pong' atau metode lain.
neontapir
3
Praktik pemrograman pasangan bukan tentang kecepatan, tetapi kualitas. Pair TDD adalah tentang kualitas, yang membawa kecepatan penyelesaian, yang membawa biaya pengembangan yang lebih rendah. Hanya industri kami yang mempelajari apa yang telah diketahui para tukang batu selama ribuan tahun: tembok Anda akan dibangun lebih baik dalam waktu lebih sedikit, dengan lebih sedikit usaha dan biaya lebih sedikit jika Anda membuang-buang waktu membuat garis tali terlebih dahulu dan aturan tukang, kemudian letakkan batu bata Anda, daripada jika Anda meletakkan batu bata Anda dan mencoba menyesuaikan setelah itu dengan tingkat roh dan palu. Dan dapatkan bantuan dengan berbagai hal.
Laurent LA RIZZA
@LaurentLARIZZA Sepertinya itu benar. Saya kira cara yang lebih baik untuk mengatakannya adalah "Praktek pemrograman pasangan bukan tentang kecepatan di saat ini, tetapi kualitas dan kecepatan di masa depan." Ini jelas merupakan praktik berwawasan ke depan untuk menemukan masalah sebelumnya, meningkatkan ketahanan kerja, dan berbagi pengetahuan untuk menghancurkan silo. Semua ini memiliki biaya sekarang yang sering akan membayar imbalan di masa depan.
Thomas Owens
@ThomasOwens: Ya, biaya kualitas hanya dirasakan, tidak nyata. Setelah tes Anda berlalu (dan Anda merapikan kode Anda), skenario yang dijelaskan oleh tes Anda selesai dan aman, dan Anda mendapatkan kepercayaan bahwa itu berfungsi seperti yang diharapkan. Sudah selesai, dan Anda bisa melanjutkan. Jika Anda melanjutkan tanpa kepastian bahwa kode itu berfungsi, Anda baru saja menerima hutang yang Anda harus lakukan cek nanti. Biaya hutang, bukan tidak adanya hutang. Maksud saya, "masa depan" yang Anda bicarakan adalah segera setelah tes pertama Anda berlalu.
Laurent LA RIZZA
37

Masalah utama dengan ide Anda adalah Anda tidak bisa hanya menulis tes untuk kode apa pun. Kode harus dapat diuji.

Yaitu Anda harus dapat menyuntikkan mengejek, pisahkan sedikit yang ingin Anda uji, status akses yang diubah dan perlu konfirmasi dll.

Kecuali jika Anda beruntung atau menulis tes terlebih dahulu, kemungkinan menulis tes berarti menulis ulang kode sedikit. Yang, jika Anda bukan orang yang menulis kode di tempat pertama, akan berarti penundaan, rapat, refactoring dll

Ewan
sumber
Terima kasih. tetapi kritik umum dari TDD adalah bahwa kode kadang-kadang / sering ditulis untuk membuat tes "hijau" - tidak menjadi baik. Jika tes tidak menguji beberapa aspek kode, maka itu bisa dihilangkan dalam kode. Tes menulis nanti dapat membantu ini (saya menerima bahwa beberapa perubahan dapat diminta setelah menulis kode, tetapi pengembang harus belajar menulis kode yang lebih dapat diuji di masa mendatang).
franiis
1
@franiis yakin, masalah utama bukanlah Anda menulis tes setelahnya, ini kombinasi melakukan itu dan tidak menjadi orang yang sama yang menulis kode.
Ewan
tetapi jika menggunakan mis pemrograman pasangan akan lebih sedikit memakan waktu. Jika dua pengembang bekerja pada satu terminal maka mereka tidak dapat dengan cara apa pun bekerja pada dua fitur, dan ide saya harus memungkinkan ini (bahkan dalam lingkup terbatas). Rapat untuk tim mikro 2-orang seharusnya tidak menjadi beban nyata.
franiis
25
@franiis: "Jika pengujian tidak menguji beberapa aspek kode, maka itu bisa dihilangkan dalam kode." - Itulah intinya. Pengujian adalah pengkodean persyaratan dalam bentuk contoh yang dapat dieksekusi. Jika tidak ada tes untuk itu, maka tidak ada persyaratan untuk itu, dan seharusnya tidak ada kode untuk itu .
Jörg W Mittag
3
Sisi lain dari apa yang dikatakan @ JörgWMittag adalah: jika tes Anda "tidak menguji beberapa kode penting", maka Anda harus memperbaiki tes Anda. Ini akan sama benarnya di sistem Anda seperti di TDD tradisional.
bta
15

Masalah utama yang saya lihat di sini, di tingkat unit, ketika saya menulis kode, saya ingin mengkompilasinya, menjalankannya , dan segera menghapus bug yang paling jelas - bahkan ketika kode tidak lengkap dan saya tahu unit, fitur atau fungsi adalah hanya sebagian yang dilaksanakan. Dan untuk menjalankan kode unit, saya perlu beberapa program memanggil implementasi, biasanya tes unit atau setidaknya tes unit parsial. Ini belum tentu "gaya TDD oleh buku", tes seperti itu dapat ditulis setelah atau sebelum kode yang diuji.

Ketika satu versi unit saya adalah "fitur lengkap" dan bebas dari semua bug saya dapat menemukan cara ini sendiri, maka masuk akal untuk menyerahkannya kepada orang kedua dan membiarkan dia menulis tes unit tambahan , atau meninjau kode saya . Tetapi bagi saya tidak masuk akal untuk menyerahkannya segera setelah kompiler tidak menunjukkan peringatan, itu pasti terlalu dini jika saya tahu saya harus menjelaskan tester secara terperinci hal-hal yang tidak berfungsi "dulu", atau akan berfungsi berbeda dalam dua jam karena saya masih bekerja di potongan kode itu. Overhead komunikasi yang diperlukan untuk ini pada tingkat perincian itu tidak akan seimbang dengan manfaatnya.

Jadi ya, memiliki dev kedua menulis tes unit tambahan masuk akal, tetapi tidak untuk menulis tes unit secara eksklusif .

Doc Brown
sumber
7

Tampaknya akan ada kemungkinan untuk terjadi situasi berikut - yang semuanya tidak diinginkan:

Kebingungan

Seperti yang diuraikan Ewan, CUT mungkin perlu diubah untuk membuatnya dapat diuji. Alasan untuk perubahan tidak selalu jelas bagi pengembang (dan dapat menyebabkan ketidaksepakatan) yang menjadi alasan mengapa tes ditulis terlebih dahulu.

Pendapat

Pengembang A mungkin telah menyelesaikan kode mereka dan ingin mengujinya. Pengembang B juga mungkin sedang berkembang dan mungkin enggan memarkir kode mereka untuk menghadiri tes unit.

Pergantian konteks

Bahkan jika pengembang B bersedia untuk menunda pengembangannya untuk menguji kode yang ditulis oleh pengembang A - perubahan dalam kegiatan akan dikenakan biaya.

Telah diterima selama beberapa dekade bahwa menggandakan kekuatan manusia tidak mengurangi separuh waktu pengembangan. Mempertimbangkan faktor-faktor yang telah saya uraikan di atas, sulit untuk melihat bagaimana pengaturan ini akan memperbaiki keadaan.

Robbie Dee
sumber
4

Ketika digunakan bersamaan dengan pemrograman pasangan dan TDD ini disebut Pola Ping Pong :

  • A menulis tes baru dan melihat itu gagal.
  • B mengimplementasikan kode yang diperlukan untuk lulus tes.
  • B menulis tes berikutnya dan melihat bahwa itu gagal.
  • A mengimplementasikan kode yang diperlukan untuk lulus tes.

Dan seterusnya. Refactoring dilakukan setiap kali diperlukan oleh siapa pun yang mengemudi.

Tetapi Anda tampaknya mengusulkan bahwa kedua kode programmer dengan komputer yang berbeda. Melakukannya secara terpisah akan memerlukan memiliki spesifikasi tingkat yang sangat rendah. Ini bertentangan dengan metodologi lincah. Setiap perubahan perlu dikoordinasikan. Dalam TDD Anda melakukan desing rendah dengan cepat dan itu bukan masalah. Saya berasumsi bahwa pendekatan Anda harus memiliki semacam kerangka yang sudah dikodekan.

Bagaimanapun: Anda dapat belajar banyak dengan menguji cara-cara baru dalam melakukan sesuatu bahkan jika tidak ada 100% efisien. Anda dapat mengujinya dan membagikan pengalaman kehidupan nyata Anda

Borjab
sumber
3

Saya datang terlambat ke pesta ini, tapi saya rasa saya punya sesuatu untuk ditambahkan.

Apakah sudah digambarkan sebagai metodologi yang tidak diketahui dan digunakan dalam pengembangan perangkat lunak?

Anda mendeskripsikan Pengujian Sebaya .

Mari kita asumsikan kita memiliki pasangan pengembang.

Ah, Program Pasangan yang baik .

Setiap pasangan bertanggung jawab atas bagian dari kode. Satu dari pasangan mengimplementasikan fitur (menulis kode) dan yang kedua menulis tes unit untuk itu. Tes ditulis setelah kode. Menurut saya mereka saling membantu, tetapi bekerja agak terpisah.

Itu bukan pemrograman pasangan.

Idealnya mereka akan bekerja pada dua fitur berukuran serupa dan kemudian ditukar dengan persiapan tes.

Itu pasti Pengujian Sebaya. Inilah makalah ACM tentang hal itu . Saya sudah melakukan ini. Saya telah bekerja di tempat yang merupakan bagian formal dari proses Peer Review . Ini membantu, tetapi tentu saja ini tidak dimaksudkan untuk menjadi garis pengujian pertama, dan tentu saja ini bukan Pemrograman Pair klasik.

Nama lain untuk ini adalah Pengujian Whitebox . Meskipun definisi itu tidak berkaitan dengan siapa yang melakukan pengujian sebanyak dengan fakta bahwa tester dapat melihat cara kerja dari hal yang mereka uji, yang bertentangan dengan pengujian Black Box di mana mereka hanya melihat apa yang masuk dan apa yang keluar. Kotak hitam biasanya adalah apa yang dilakukan QA.

Baris pertama pengujian terletak dengan kuat di tangan pembuat kode. Jika tidak, Anda meminta saya untuk tidak menguji kode saya sendiri yang saya tolak menolaknya. Saya telah menguji kode saya sejak saya berusia 10 tahun. Saya mungkin tidak diuji dengan tes unit mewah saat itu tetapi kode saya diuji. Itu diuji setiap kali saya menjalankannya.

Apa yang saya harapkan dari penguji sebaya adalah tes yang menambah pengujian saya. Tes yang membuat sangat jelas masalah yang ditemukan rekan dengan kode ketika mereka meninjaunya. Dengan mengungkapkan masalah-masalah ini dengan tes otomatis, membuat memahami apa artinya jauh lebih mudah. Infact, saya sudah melakukan percakapan teknis dengan rekan-rekan yang tidak bisa melihat poin yang saya buat dan kemudian menyadari cara terbaik untuk menunjukkan kepada mereka masalahnya adalah dengan menulis unit test. Itu adalah Pengujian Sebaya.

Sekarang jika Anda ingin memberi saya tes tertulis sebelum saya menulis kode saya baik-baik saja. Tidak seperti dokumen persyaratan yang begitu formal sehingga dapat dikompilasi.

candied_orange
sumber
Terima kasih atas tanggapan dan mengarahkan saya ke Peer Testing (saya akan membacanya).
franiis
1

Saya telah melakukan DDT (development driven testing, alias. Tes setelah kode), pair programming dan red-green-refactor TDD untuk masing-masing beberapa tahun. Untuk menanggapi pernyataan Anda poin demi poin:

tes ditulis oleh seseorang, yang dapat melihat lebih banyak tentang implementasi

Orang yang menulis tes perlu mengetahui implementasi sedekat mungkin, untuk menulis tes dengan cakupan yang baik tanpa pengujian berlebihan. Contoh klasik dari ini adalah pengujian dengan tiga input ketika dua akan membuktikan apa yang Anda coba uji. Meskipun mereka dapat mencapai keakraban permukaan dengan kode dari membacanya, mereka tidak akan dapat memahami dengan tepat apa yang pengembang asli lalui untuk sampai ke keadaan saat ini. Jadi mereka akan memiliki pemahaman kode yang kurang optimal.

pekerjaan harus dibuat sedikit lebih cepat daripada pemrograman berpasangan (dua fitur sekaligus)

Saya tidak mengerti mengapa Anda mengatakan itu. Ketika seseorang menulis tes, mereka tidak mengerjakan fitur baru. Anda tidak dapat secara ajaib menggandakan kapasitas seseorang untuk bekerja dengan memberi mereka dua jenis pekerjaan yang berbeda. Dalam pengalaman saya, menulis tes umumnya lebih sulit daripada menulis kode produksi, jadi Anda pasti tidak dapat mengerjakan tes untuk beberapa kode secara produktif dan bertanggung jawab saat menulis fitur lain.

baik tes dan kode memiliki orang yang bertanggung jawab untuk itu

Pertama, tes adalah kode. Untuk kode tes bisnis hampir sama pentingnya dengan kode produksi, karena memungkinkan bisnis untuk mengubah perangkat lunak tanpa rasa takut. Kedua, ini tidak berbeda dari satu orang yang menulis tes dan kode produksi, atau bahkan pasangan yang menulis keduanya.

kode diuji oleh setidaknya dua orang

Tidak, ini hanya diuji oleh orang yang menulis tes. Kecuali jika Anda ingin menggunakan lebih banyak waktu pada pengujian, dalam hal ini mengapa berhenti pada jam dua?

mungkin mencari kesalahan dalam kode yang ditulis oleh orang yang menguji kode Anda akan memberikan motivasi khusus untuk menulis kode yang lebih baik dan menghindari memotong sudut.

Pengembang (bahkan yang senior) memiliki gagasan yang sangat berbeda tentang apa yang merupakan kode "baik". Pemotongan sudut seseorang adalah cara lain yang sangat valid untuk mendapatkan kode kerja ASAP. Ini adalah resep untuk menyalahkan dan untuk game sistem.

Merah-hijau-refactor TDD ( benar-benar menulis satu tes sebelum menulis kode produksi, menjalankannya, melihatnya gagal, memodifikasi kode produksi saja, menjalankan tes lagi, melihatnya berhasil, dan kemudian refactoring, dan tidak melewatkan atau menukar salah satu dari langkah-langkah ini) dan ulasan kode berfungsi.

l0b0
sumber
Akan lebih cepat (mungkin) karena Anda tidak memiliki dua orang melakukan "pekerjaan yang sama" - mereka masing-masing melakukan hal mereka sendiri dan kemudian bertukar sebagian.
Jacob Raihle
@JacobRaihle Pairing bukanlah dua orang yang berkembang berdampingan tanpa komunikasi. Itu adalah dua orang yang melakukan pekerjaan yang sama. Berpasangan benar-benar efisien karena dua orang berkolaborasi dalam suatu pekerjaan. Dalam pengalaman saya pengembangan adalah tentang secepat untuk programmer individu (yaitu, pasangan menyelesaikan pekerjaan dua kali lebih cepat), perangkat lunak yang dihasilkan adalah kualitas yang jauh lebih tinggi dan pengetahuan telah dibagikan.
l0b0
Saya mencoba menjelaskan alasan di balik "pekerjaan harus dibuat sedikit lebih cepat", yang tampaknya membingungkan Anda. Berpasangan biasanya lebih lambat dalam pengalaman saya, meskipun saya masih berpikir itu sepadan (lebih disukai untuk pekerjaan individu dan penyerahan pengujian OPs). Jika Anda lebih cepat, itu lebih baik.
Jacob Raihle
1

Saya pikir ide ini memiliki beberapa kelebihan:

Tidak menjalankannya satu per satu.

tes ditulis oleh seseorang, yang dapat melihat lebih banyak tentang implementasinya,

Jadi, maksud Anda pengembang pertama telah menghabiskan waktu menulis beberapa implementasi, yang dia tidak yakin berfungsi. Kemudian, pengembang lain datang dan menulis tes, mendasarkan alasannya pada kode tidak ada yang tahu apakah itu benar, dan berharap itu membawa keuntungan taktis dibandingkan dengan menulis tes hanya berkaitan dengan apa yang seharusnya dilakukan kode. Jika implementasinya tidak benar, menurut saya itu tidak akan membantu dalam penulisan tes.

pekerjaan harus dibuat sedikit lebih cepat daripada pemrograman berpasangan (dua fitur sekaligus)

Setelah kedua pengembang menyelesaikan pengembangan awal mereka, tidak ada yang tahu apakah salah satu dari kode mereka benar. Ini masih harus diperiksa, tidak ada yang bisa menandai apa pun yang dilakukan, dan tidak ada yang bisa memprediksi kapan mereka akan selesai. Bandingkan ini dengan TDD: Anda menulis tes terlebih dahulu, kemudian membuat tes gagal, lalu lulus dengan kode. Itu kode yang mendukung semakin banyak skenario. Itu gerak maju.

Jika Anda membuatnya maju secara paralel, kode yang dapat digunakan kembali di kedua fitur akan ditulis dua kali, dan biaya dua kali lebih banyak.

baik tes dan kode memiliki orang yang bertanggung jawab untuk itu,

Lihatlah kepemilikan kode kolektif, seperti yang diusulkan oleh XP. Anda akan memiliki lebih banyak orang yang bertanggung jawab atas kode tersebut. Jika tujuan Anda adalah berbagi pengetahuan antar pengembang, mengapa Anda mencoba memisahkan mereka?

kode diuji oleh setidaknya dua orang

Dengan pasangan TDD juga. Saat berpasangan, kedua orang harus setuju bahwa kode tertulis memadai atau tidak menuliskannya. Jika itu menghasilkan perkelahian, beberapa orang di tim memiliki masalah ego yang salah tempat.

mungkin mencari kesalahan dalam kode yang ditulis oleh orang yang menguji kode Anda akan memberikan motivasi khusus untuk menulis kode yang lebih baik dan menghindari memotong sudut.

Mencari kesalahan menyiratkan bahwa pada titik tertentu, Anda menoleransi mereka masuk. Jika mereka masuk, mereka tidak diperhatikan. Menolak untuk menulis tes terlebih dahulu berarti memberi izin untuk kesalahan.

Sudut pemotongan mungkin tidak disengaja. Untuk itulah pemrograman berpasangan. Setiap anggota pasangan harus diinstruksikan dengan tugas untuk tidak membiarkan yang lain memotong jalan pintas, karena, kita semua melakukan itu. Itu mengharuskan Anda meninggalkan harga diri di lemari dan mengambilnya kembali saat Anda meninggalkan kantor. Jika Anda berharap orang-orang Anda menjadi sangat tegar, Anda tidak mempertimbangkan situasi umum dan mengatur diri sendiri untuk gagal.

XP mengatakan secara eksplisit bahwa semua praktik XP dibuat untuk saling memperkuat dengan menutupi kekurangan masing-masing. Anda seharusnya tidak mendengarkan kritik terhadap praktik XP yang terpisah dari yang lain. Tidak ada satu latihan yang sempurna, TDD tidak sempurna, pemrograman pasangan tidak sempurna, kepemilikan kode kolektif tidak sempurna, tetapi semuanya mencakup satu sama lain.

Laurent LA RIZZA
sumber