Kent Beck - Pemrograman Ekstrim. Pengembangan Berbasis Uji

Aliran: ,

Seri:
Batasan usia: +
Bahasa:
Bahasa asli:
Penerjemah:
Penerbit:
kota penerbitan: St. Petersburg
Tahun terbit:
ISBN: 978-5-496-02570-6 Ukuran: 382 Kb

Pemegang hak cipta!

Fragmen karya yang disajikan diposting dengan kesepakatan dengan distributor konten legal LLC "Liter" (tidak lebih dari 20% dari teks asli). Jika Anda yakin bahwa posting materi melanggar hak seseorang, maka.

Pembaca!

Sudah bayar, tapi tidak tahu apa yang harus dilakukan selanjutnya?

Perhatian! Anda mengunduh kutipan yang diizinkan oleh undang-undang dan pemegang hak cipta (tidak lebih dari 20% dari teks).
Setelah meninjau, Anda akan diminta untuk mengunjungi situs web pemegang hak cipta dan membeli versi lengkap dari karya tersebut.

Deskripsi buku

Kembalinya buku terlaris yang terkenal. Kode yang elegan, fleksibel, dan mudah dipahami yang mudah dimodifikasi, yang berfungsi dengan benar, dan yang tidak memberikan kejutan yang tidak menyenangkan bagi pembuatnya. Apakah ini benar-benar mungkin? Untuk mencapai tujuan Anda, cobalah menguji program Anda sebelum Anda menulisnya. Ide paradoks inilah yang menjadi dasar metodologi TDD (Test-Driven-Development). Omong kosong? Jangan terburu-buru menarik kesimpulan secara tergesa-gesa. Mempertimbangkan penggunaan TDD pada contoh pengembangan kode perangkat lunak nyata, penulis menunjukkan kesederhanaan dan kekuatan teknik ini. Buku ini berisi dua proyek perangkat lunak yang sepenuhnya dan sepenuhnya diimplementasikan menggunakan TDD. Contoh diikuti oleh katalog ekstensif teknik gaya TDD dan pola dan refactoring terkait TDD. Buku ini akan berguna bagi setiap programmer yang ingin meningkatkan produktivitas pekerjaannya dan menikmati pemrograman.

Kesan terakhir buku

Bagikan Dipertajam:
16-12-2018, 02:17

Sebelum membaca buku ini, saya mencoba menulis tes untuk artikel yang saya baca, tetapi hanya dengan itu saya mulai mahir.

Saya membacanya dua kali. Baru pertama kali baca.

Tidak mengerti apa-apa. Kedua kalinya saya menulis kode sambil membaca buku, dan akhirnya saya sadar apa itu dan yang paling penting - saya merasakan ukuran langkah saya di mana saya dapat mengubah kode tanpa kehilangan kendali atasnya. Saya senang dengan bab kedua di mana, bersama dengan penulis, ia menulis sistem pengujian unitnya dengan Python, perasaan itu seolah-olah Anda sedang melakukan operasi di otak Anda sendiri (sebenarnya, ini persis perbandingan yang penulis sendiri dibuat) - satu gerakan ceroboh dan tidak ada yang berhasil, Anda harus bergerak dalam langkah yang sangat kecil. Saya membaca bab ketiga secara selektif, mungkin suatu hari nanti saya akan melakukannya.

Runtuh

⬇ Komentar lain

Buku ini tentang pemrograman ekstrim. Extreme Programming, sering disebut sebagai "XP", adalah metodologi produksi yang disederhanakan untuk tim pengembangan kecil hingga menengah. produk perangkat lunak dalam menghadapi persyaratan yang tidak jelas atau berubah dengan cepat. Buku ini dimaksudkan untuk membantu Anda menentukan apakah XP sesuai untuk situasi Anda ...

Tentang seri XP

Pemrograman Ekstrim, sering disebut sebagai XP, adalah disiplin pengembangan perangkat lunak dan melakukan bisnis di bidang pembuatan produk perangkat lunak, yang memfokuskan upaya kedua belah pihak (programmer dan pengusaha) pada tujuan yang sama dan cukup dapat dicapai. Tim XP memproduksi perangkat lunak berkualitas dengan kecepatan tinggi. Teknik-teknik yang merupakan bagian dari disiplin XP yang dijelaskan dalam buku ini dipilih karena didasarkan pada kreativitas manusia dan penerimaan bahwa seseorang adalah makhluk yang tidak stabil dan rawan kesalahan.

XP sering disajikan sebagai kumpulan teknik, tetapi XP sendiri bukanlah garis akhir. Anda tidak perlu berlatih dan mengembangkan XP lebih baik dan lebih baik lagi untuk mendapatkan bintang emas yang ditunggu-tunggu di akhir proses ini. Sebaliknya, XP adalah garis awal. XP mengajukan pertanyaan, "Seberapa minimal upaya kami agar kami dapat terus menghasilkan perangkat lunak yang berkualitas?"

Awal dari jawaban pertanyaan tersebut terdengar seperti ini: jika kita ingin mengembangkan program berkualitas tanpa kekacauan dan kebingungan, kita harus siap untuk sepenuhnya dan sepenuhnya menerapkan beberapa teknik dalam tim kita, yang akan kita gunakan secara maksimal. Jika kita menggunakan teknik ini setengahnya, masalahnya tetap ada, dan untuk menyelesaikannya, kita perlu beralih ke penggunaan teknik sepenuhnya. Jika kita membatasi diri kita pada setengah ukuran, lama kelamaan kita akan menjadi sangat bingung di dalamnya sehingga kita tidak akan dapat memahami bahwa hal-hal utama yang diciptakan oleh tenaga programmer lahir berkat pemrograman.

Saya berkata "mulai jawaban untuk" karena kelanjutannya tidak benar-benar ada. Orang-orang yang membuat dan mengimplementasikan XP juga berpikir untuk memecahkan masalah ini. Setelah mencoba menggunakan XP, mereka melangkahi ambang dan pergi ke tempat yang tidak diketahui. Ketika mereka kembali, mereka menceritakan kisah mereka. Pikiran mereka adalah tanda yang ditempatkan di sepanjang jalan: “Naga tinggal di sini”, “Setelah 15 km pemandangan yang bagus"," Daerah ini berbahaya saat hujan. "

Maaf, tapi sudah waktunya bagi saya untuk pergi program.

Kata pengantar

Pemrograman ekstrim (

Pemrograman Ekstrem

XP) mendefinisikan pengkodean sebagai aktivitas utama dan mendasar saat mengerjakan proyek perangkat lunak. Mungkin salah!

Saya pikir perlu mengingat pengalaman saya sendiri dalam pengembangan perangkat lunak. Saya bekerja di lingkungan di mana produk yang dikembangkan terus-menerus masuk situasi kerja, dan pada saat yang sama, perubahan terus dilakukan padanya. Garis waktu rilis untuk versi yang bisa diterapkan berikutnya sangat ketat, dan pada saat yang sama, risiko teknis yang besar tergantung pada semua ini. Dalam lingkungan seperti itu, kemampuan untuk memperbaiki sesamanya adalah seni yang tanpanya seseorang tidak dapat bertahan hidup. Pertukaran informasi baik dalam satu tim maupun antara beberapa tim, yang seringkali terpisah secara geografis, dilakukan dengan menggunakan kode. Kami membaca kode untuk memahami struktur antarmuka pemrograman sistem baru atau yang dimodifikasi. Lingkaran kehidupan dan perilaku objek kompleks didefinisikan menggunakan kasus uji, yaitu, sekali lagi menggunakan kode. Laporan masalah disertai dengan kasus uji yang menunjukkan masalah, sekali lagi menggunakan kode untuk ini. Terakhir, kami terus-menerus sibuk meningkatkan kode yang ada, membuatnya lebih produktif, lebih fleksibel, dan lebih mudah dipahami. Jelas, dalam kondisi seperti itu, pengembangan perangkat lunak hampir seluruhnya didasarkan pada pengkodean, tetapi pada saat yang sama kami berhasil menyelesaikan proyek tepat waktu, dengan demikian, pendekatan ini cukup layak.

Jangan berasumsi bahwa semua yang Anda butuhkan untuk berhasil mengimplementasikan proyek perangkat lunak adalah pemrograman brutal yang sembrono. Mengembangkan perangkat lunak sangat sulit, dan mengembangkan perangkat lunak berkualitas tinggi dan menyelesaikan pekerjaan tepat waktu bahkan lebih sulit. Agar pendekatan yang saya jelaskan berhasil, Anda harus secara konsisten menerapkan aturan dan teknik tambahan yang penting. Di sinilah Kent Beck memulai buku pemikirannya tentang XP.

Saya bermitra dengan Kent dan menggunakan episode XP pada proyek kecil tapi terkenal bernama JUnit.

pengantar

Buku ini tentang pemrograman ekstrim (

Pemrograman Ekstrem

XP). Extreme Programming adalah metodologi produksi yang disederhanakan untuk tim profesional berukuran kecil hingga menengah yang terlibat dalam pengembangan perangkat lunak di lingkungan dengan persyaratan yang tidak jelas atau berubah dengan cepat. Buku ini dimaksudkan untuk membantu Anda menentukan apakah XP sesuai untuk situasi Anda.

Bagi banyak orang, XP terlihat seperti seperangkat metode organisasi kerja yang cukup dapat diterima dan dibenarkan dari sudut pandang akal sehat. Lalu mengapa pemrograman XP disebut ekstrim? Intinya adalah bahwa XP membawa banyak prinsip pemrograman yang diterima dan digunakan secara luas ke tingkat yang ekstrim.

Jika revisi kode bagus, maka kami akan merevisi kode secara terus-menerus (pemrograman berpasangan);

Jika pengujian baik, setiap peserta proyek akan terus menguji kode program (pengujian unit), bahkan pelanggan ( pengujian fungsional);

Jika desainnya bagus, maka desain harus dijadikan bagian integral dari pekerjaan sehari-hari setiap peserta proyek (revisi kode);

Pemrograman ekstrim

Didedikasikan untuk ayah saya dan juga terima kasih kepada Cindee Andres, istri dan pasangan saya, karena telah menuntut saya untuk mengabaikannya dan menulis. Terima kasih kepada Bethany, Lincoln, Forrest dan karena tidak mengganggu saya dan membiarkan saya menulis.

Tentang seri XP

Extreme Programming, sering disebut sebagai XP, adalah rekayasa perangkat lunak dan disiplin bisnis perangkat lunak yang memfokuskan upaya pemrogram dan pebisnis pada tujuan bersama yang dapat dicapai. Tim XP memproduksi perangkat lunak berkualitas dengan kecepatan tinggi. Teknik-teknik yang merupakan bagian dari disiplin XP yang dijelaskan dalam buku ini dipilih karena didasarkan pada kreativitas manusia dan penerimaan bahwa seseorang adalah makhluk yang tidak stabil dan rawan kesalahan.

Saya bilang "mulai jawabannya" karena kelanjutannya tidak benar-benar ada. Orang-orang yang membuat dan mengimplementasikan XP juga berpikir untuk memecahkan masalah ini. Setelah mencoba menggunakan XP, mereka melangkahi ambang dan pergi ke tempat yang tidak diketahui. Ketika mereka kembali, mereka menceritakan kisah mereka. Pikiran mereka adalah tanda-tanda yang ditempatkan di sepanjang jalan: "Naga tinggal di sini", "Setelah 15 km, pemandangan yang bagus terbuka", "Daerah ini berbahaya saat hujan."

Maaf, tapi sudah waktunya bagi saya untuk pergi program.

Kent Beck, Konsultan Seri

Kata pengantar

Pemrograman ekstrim ( Pemrograman Ekstrem, XP) mendefinisikan pengkodean sebagai aktivitas utama dan mendasar saat mengerjakan proyek perangkat lunak. Mungkin salah!

Saya pikir perlu mengingat pengalaman saya sendiri dalam pengembangan perangkat lunak. Saya bekerja di lingkungan di mana produk yang sedang dikembangkan terus-menerus dalam keadaan bekerja, dan pada saat yang sama, perubahan terus dilakukan padanya. Garis waktu rilis untuk versi yang bisa diterapkan berikutnya sangat ketat, dan pada saat yang sama, risiko teknis yang besar tergantung pada semua ini. Dalam lingkungan seperti itu, kemampuan untuk memperbaiki sesamanya adalah seni yang tanpanya seseorang tidak dapat bertahan hidup. Pertukaran informasi baik dalam satu tim maupun antara beberapa tim, yang seringkali terpisah secara geografis, dilakukan dengan menggunakan kode. Kami membaca kode untuk memahami struktur antarmuka pemrograman sistem yang baru atau yang dimodifikasi. Siklus hidup dan perilaku objek kompleks didefinisikan menggunakan kasus uji, yaitu, sekali lagi menggunakan kode. Laporan masalah disertai dengan kasus uji yang menunjukkan masalah, sekali lagi menggunakan kode untuk ini. Terakhir, kami terus-menerus sibuk meningkatkan kode yang ada, membuatnya lebih produktif, lebih fleksibel, dan lebih mudah dipahami. Jelas, dalam kondisi seperti itu, pengembangan perangkat lunak hampir seluruhnya didasarkan pada pengkodean, tetapi pada saat yang sama kami berhasil menyelesaikan proyek tepat waktu, sehingga pendekatan ini cukup layak.

Kent adalah salah satu eksekutif Tektronix yang mengakui potensi besar dari pemrograman pasangan berpasangan untuk mengembangkan aplikasi teknik yang kompleks di Smalltalk. Bersama Bard Cunningham (Ward Cunningham), Kent menjadi inspirasi pengembangan teknik pemrograman dari pola (disebut juga pemrograman menggunakan pola - pemrograman pola yang sangat mempengaruhi karir saya sendiri. XP menjelaskan pendekatan pengembangan perangkat lunak yang menggabungkan teknik yang digunakan oleh banyak pengembang sukses yang telah mempelajari banyak literatur tentang pengorganisasian pekerjaan programmer dan mencoba banyak metode dan prosedur untuk mengembangkan produk perangkat lunak. Seperti pemrograman dengan contoh, XP menyediakan serangkaian praktik terbaik, seperti pengujian unit, pemrograman berpasangan, dan penulisan ulang kode. Di XP, teknik-teknik ini digabungkan sedemikian rupa untuk melengkapi dan seringkali saling mengontrol. Tujuan utama dari buku ini adalah untuk berbicara tentang interaksi dan penggunaan bersama dari berbagai teknik. Semua teknik pemrograman memiliki satu tujuan - pembuatan produk perangkat lunak dengan fungsionalitas tertentu dengan tenggat waktu tertentu. Proses Just In Time Software OTI yang sangat sukses bukanlah XP di XP bentuk murni namun, ada banyak kesamaan antara kedua pendekatan tersebut.

Saya bermitra dengan Kent dan menggunakan episode XP pada proyek kecil tapi terkenal bernama JUnit. Pandangan dan pendekatannya terhadap pengembangan perangkat lunak selalu membuat saya berpikir tentang bagaimana saya secara pribadi terbiasa mengerjakan proyek perangkat lunak. Tanpa ragu, XP menantang banyak pendekatan tradisional yang digunakan dalam industri pemrograman. Setelah membaca buku ini, Anda dapat memutuskan sendiri apakah Anda perlu menggunakan XP dalam pekerjaan Anda atau tidak.

Pemrograman ekstrim

Tentang seri XP

Maaf, tapi sudah waktunya bagi saya untuk pergi program.

Kent Beck, Konsultan Seri

Kata pengantar

Pemrograman ekstrim ( Pemrograman Ekstrem, XP) mendefinisikan pengkodean sebagai aktivitas utama dan mendasar saat mengerjakan proyek perangkat lunak. Mungkin salah!

Kent adalah salah satu eksekutif Tektronix yang mengakui potensi besar dari pemrograman pasangan berpasangan untuk mengembangkan aplikasi teknik yang kompleks di Smalltalk. Bersama Bard Cunningham (Ward Cunningham), Kent menjadi inspirasi pengembangan teknik pemrograman dari pola (disebut juga pemrograman menggunakan pola - pemrograman pola yang sangat mempengaruhi karir saya sendiri. XP menjelaskan pendekatan pengembangan perangkat lunak yang menggabungkan teknik yang digunakan oleh banyak pengembang sukses yang telah mempelajari banyak literatur tentang pengorganisasian pekerjaan programmer dan mencoba banyak metode dan prosedur untuk mengembangkan produk perangkat lunak. Seperti pemrograman dengan contoh, XP menyediakan serangkaian praktik terbaik, seperti pengujian unit, pemrograman berpasangan, dan penulisan ulang kode. Di XP, teknik-teknik ini digabungkan sedemikian rupa untuk melengkapi dan seringkali saling mengontrol. Tujuan utama dari buku ini adalah untuk berbicara tentang interaksi dan penggunaan bersama dari berbagai teknik. Semua teknik pemrograman memiliki satu tujuan - untuk membuat produk perangkat lunak dengan fungsionalitas tertentu dengan tenggat waktu tertentu. Proses Just In Time Software OTI yang sangat sukses bukanlah XP murni, tetapi ada banyak kesamaan di antara kedua pendekatan tersebut.

Erich Gamma

pengantar

Buku ini tentang pemrograman ekstrim ( Pemrograman Ekstrem, XP). Extreme Programming adalah metodologi produksi yang disederhanakan untuk tim profesional berukuran kecil hingga menengah yang terlibat dalam pengembangan perangkat lunak di lingkungan dengan persyaratan yang tidak jelas atau berubah dengan cepat. Buku ini dimaksudkan untuk membantu Anda menentukan apakah XP sesuai untuk situasi Anda.

Jika revisi kode bagus, maka kami akan merevisi kode secara terus-menerus (pemrograman berpasangan);

Jika pengujian baik, setiap peserta proyek akan terus menguji kode program (pengujian unit), bahkan pelanggan (pengujian fungsional);

Jika desainnya bagus, maka desain harus dijadikan bagian integral dari pekerjaan sehari-hari setiap peserta proyek (revisi kode);

Jika kesederhanaan itu baik, maka kita harus menjaga sistem sesederhana mungkin untuk menyediakan tingkat fungsionalitas yang dibutuhkan saat ini (hal paling sederhana yang mungkin berhasil); jika arsitektur itu penting, maka masing-masing peserta proyek akan terus bekerja untuk mendefinisikan dan merevisi arsitektur (metafora);

Jika pengujian integrasi penting, maka perlu untuk mengumpulkan dan menguji sistem yang dikembangkan beberapa kali sehari (integrasi berkelanjutan);

Jika iterasi kecil bagus, Anda perlu membuat iterasi sangat, sangat kecil - detik, menit, mungkin jam, tetapi bukan minggu dan bulan, dan tidak berarti tahun (permainan perencanaan).

Ketika saya pertama kali memutuskan untuk mengartikulasikan esensi XP untuk diri saya sendiri, saya membayangkan satu set pegangan pada panel kontrol. Setiap pegangan berhubungan dengan teknik tertentu, yang darinya pengalaman pribadi Saya tahu itu cukup efektif. Setiap pegangan memungkinkan satu atau lain teknik untuk digunakan sampai batas tertentu, dari 1 hingga 10. Saya mencoba mengatur semua lengan ke posisi maksimumnya (10) dan terkejut menemukan bahwa berbagai teknik yang saya pertimbangkan tetap stabil, diprediksi, dan fleksibel.

XP menghasilkan dua set janji:

XP menjanjikan programmer bahwa masing-masing dari mereka akan bekerja untuk memecahkan masalah yang sangat penting setiap hari kerja. Masing-masing dari mereka tidak akan pernah menemukan diri mereka terdampar sendirian. Masing-masing dari mereka akan dapat melakukan segala daya mereka untuk membuat sistem yang dikembangkan berhasil. Masing-masing dari mereka akan dapat membuat keputusan tepat di bidang yang dia kuasai, dan jika di beberapa area dia tidak cukup kompeten, dia tidak akan berpartisipasi dalam pengambilan keputusan.

XP menjanjikan pelanggan dan manajer bahwa mereka akan mendapatkan hasil maksimal dari setiap minggu pengembangan proyek. Setiap beberapa minggu, mereka akan dapat melihat kemajuan menuju tujuan mereka. Mereka akan dapat mengubah arah proyek di tengah pembangunan, tanpa takut tambahan biaya yang luar biasa.

Singkatnya, XP berjanji untuk mengurangi risiko proyek, meningkatkan respons terhadap perubahan bisnis, meningkatkan produktivitas proyek, dan membuat pengembangan perangkat lunak lebih menyenangkan - semuanya pada saat yang bersamaan. Aku tidak bercanda, berhenti tertawa. Baca saja buku ini dan Anda dapat memeriksa sendiri apakah saya gila.

Buku ini

Buku ini berbicara tentang hal-hal yang berhubungan dengan metode XP - akarnya, filosofi, segala macam cerita dan mitos. Buku ini dimaksudkan untuk membantu Anda membuat keputusan tentang apakah akan menggunakan XP dalam proyek Anda sendiri. Jika, setelah membaca buku ini, Anda memutuskan untuk tidak menggunakan XP saat mengerjakan proyek Anda, saya akan mempertimbangkan tujuan utama yang dicapai dengan cara yang sama seolah-olah, setelah membaca buku ini, Anda akan memutuskan bahwa XP adalah apa yang Anda butuhkan. . Tujuan kedua dari buku ini adalah untuk membantu Anda yang sudah menggunakan XP. Setelah membaca buku, pembaca tersebut akan dapat lebih memahami teknik ini.

Buku ini tidak memberikan instruksi yang tepat tentang bagaimana proses pemrograman ekstrim harus dilakukan. Anda tidak akan melihat banyak contoh, algoritme, atau cerita pemrograman di dalamnya. Untuk mendapatkan semua ini, Anda dapat mencari di Internet, berbicara dengan beberapa kontributor proyek, menunggu buku tentang ini muncul, atau mulai membuat materi tersebut sendiri.

Nasib selanjutnya dari disiplin pengembangan software XP yang saya uraikan ada di tangan sekelompok orang (mungkin Anda salah satunya) yang tidak puas dengan apa yang ada di saat ini metode tradisional untuk mengatur pekerjaan programmer. Apakah kamu membutuhkan? jalan terbaik pengembangan perangkat lunak, Anda ingin membangun hubungan yang lebih produktif dan ramah dengan pelanggan Anda, Anda ingin membuat programmer yang bekerja di bawah arahan Anda lebih bahagia, lebih setia, dan lebih produktif. Singkatnya, Anda menginginkan keuntungan yang signifikan dan Anda tidak takut untuk memanfaatkan ide-ide baru untuk mendapatkan keuntungan itu. Namun, sebelum Anda mengambil risiko, Anda ingin memastikan bahwa Anda setidaknya tidak benar-benar bodoh.

XP memberitahu Anda untuk melakukan pekerjaan Anda dengan cara yang sangat berbeda dari biasanya. Dalam beberapa kasus, rekomendasi XP benar-benar bertentangan dengan norma yang berlaku umum. pada saat ini Saya percaya bahwa XP hanya dapat digunakan oleh mereka yang memiliki alasan kuat untuk mengubah urutan yang ada. Namun, jika ada alasan seperti itu, Anda dapat mulai menggunakan XP sekarang juga. Saya menulis buku ini agar Anda dapat mempelajari lebih lanjut tentang alasan-alasan ini.

Apa itu XP?

Apa itu XP? XP adalah cara yang disederhanakan, efisien, fleksibel, dapat diprediksi, ilmiah, dan sangat menyenangkan untuk mengembangkan perangkat lunak yang mencakup: level rendah mempertaruhkan. XP berbeda dari teknik lain dengan cara berikut.

Dengan menggunakan siklus pengembangan yang sangat singkat, XP menawarkan umpan balik yang cepat, nyata, dan permanen.

XP menggunakan perencanaan inkremental, menghasilkan rencana proyek keseluruhan yang muncul agak cepat, tetapi ini menyiratkan bahwa rencana ini berkembang sepanjang umur proyek.

XP menggunakan garis waktu yang fleksibel untuk memberikan fungsionalitas guna meningkatkan daya tanggap terhadap perubahan bisnis dan perubahan kebutuhan pelanggan.

XP didasarkan pada tes otomatis yang dikembangkan oleh programmer dan pelanggan. Berkat tes ini, dimungkinkan untuk memantau proses pengembangan, memastikan evolusi sistem yang benar dan segera mendeteksi cacat yang ada dalam sistem.

XP didasarkan pada komunikasi lisan, tes dan kode sumber. Ketiga alat ini digunakan untuk bertukar informasi tentang struktur sistem dan perilakunya.

XP didasarkan pada proses desain yang berkembang yang berlangsung selama sistem itu sendiri.

XP didasarkan pada interaksi dekat programmer dengan keterampilan dan kemampuan yang paling umum.

XP didasarkan pada teknik yang memuaskan naluri jangka pendek dari masing-masing programmer dan kepentingan jangka panjang dari proyek secara keseluruhan.

XP adalah disiplin pengembangan perangkat lunak. Ini adalah disiplin karena ada hal-hal tertentu dalam XP yang harus Anda lakukan jika Anda ingin menggunakan XP. Anda tidak harus memilih untuk menulis tes atau tidak, karena jika tidak, pemrograman yang Anda lakukan tidak ekstrem: akhir diskusi.

Metodologi XP dirancang untuk mengerjakan proyek yang dapat dikerjakan oleh dua hingga sepuluh programmer yang tidak dibatasi oleh kerangka kerja kaku dari lingkungan komputer yang ada dan di mana semua pekerjaan yang diperlukan terkait dengan pengujian dapat diselesaikan dalam satu hari.

XP menakut-nakuti atau mengganggu beberapa orang yang menggunakan teknik ini untuk pertama kalinya. Namun, tidak ada ide di balik XP yang baru. Dalam arti tertentu, metodologi XP bersifat konservatif - semua teknik yang digunakan dalam kerangka kerjanya telah diuji selama beberapa dekade (berkenaan dengan strategi implementasi) dan bahkan berabad-abad (berkenaan dengan strategi manajemen) praktik.

Baru di XP adalah fitur-fitur berikut:

Semua teknik terkenal ini dikumpulkan di bawah satu atap;

Intensitas penerapan teknik-teknik ini ke dalam pekerjaan sehari-hari telah didorong hingga ekstrem;

Teknik yang digunakan saling mendukung semaksimal mungkin.

Kecukupan

Dalam karya-karyanya Orang Hutan dan Gunung antropolog Colin Turnbull menggambarkan dua masyarakat yang sangat berbeda. Di pegunungan, sumber daya yang diperlukan untuk kehidupan tidak cukup, dan orang-orang selalu di ambang kelaparan. Budaya yang muncul dalam kondisi ini terlihat menakutkan. Para ibu meninggalkan anak-anak mereka untuk bertahan hidup sendiri. Makanan bisa berakibat fatal. Kekejaman, kebrutalan, dan pengkhianatan adalah hal biasa dan setiap hari.

Tidak seperti gunung, hutan kaya akan sumber daya. Untuk menyediakan makanan sepanjang hari, seseorang hanya perlu menghabiskan sekitar setengah jam. Budaya hutan adalah kebalikan dari budaya gunung. Orang dewasa mengambil bagian dalam membesarkan dan membesarkan anak-anak biasa, yang tumbuh dalam cinta dan perhatian sampai mereka cukup mampu untuk mengurus diri mereka sendiri. Jika satu orang secara tidak sengaja membunuh orang lain (pembunuhan yang disengaja tidak dikenal oleh orang-orang ini), dia dikeluarkan dari masyarakat. Namun, dalam kasus ini, orang buangan hanya harus pensiun ke hutan dan menghabiskan beberapa bulan di sana, dan bahkan beberapa anggota suku membawakannya makanan dan hadiah.

XP adalah upaya untuk menjawab pertanyaan: Bagaimana Anda secara pribadi memprogram jika Anda punya cukup waktu? Sebenarnya, Anda tidak punya waktu ekstra, karena pemrograman adalah bisnis. Dalam bisnis apa pun, pemenangnya adalah orang yang menyelesaikan pekerjaan lebih cepat. Namun, jika Anda punya waktu, Anda mungkin akan memperhatikan desain pengujian; Anda kemungkinan besar akan merancang ulang sistem jika Anda sampai pada kesimpulan bahwa itu perlu; Anda mungkin akan lebih banyak berkomunikasi dengan sesama programmer, serta dengan pelanggan.

Perasaan berkecukupan ini terlihat lebih manusiawi, berbeda dengan situasi di mana pemrogram berjuang untuk tetap berada dalam kerangka waktu yang diberikan, di luar jadwal, tidak punya waktu untuk menyelesaikan sejumlah besar pekerjaan yang sangat penting hanya untuk memiliki waktu untuk menyelesaikannya. sebuah proyek tepat waktu. Tergesa-gesa mencegah programmer dari sepenuhnya menunjukkan bakat mereka dan menikmati pekerjaan mereka. Namun, ketika Anda mulai belajar XP, Anda harus memahami bahwa perasaan berkecukupan juga merupakan bisnis yang baik. Rasa cukup menjadi sumber efisiensi dengan cara yang sama seperti rasa kekurangan menimbulkan kegagalan dalam pekerjaan, menyebabkan munculnya cacat dan penurunan kualitas, dan, pada akhirnya, penurunan produktivitas tenaga kerja.

Rencana buku

Buku ini ditulis seolah-olah Anda dan saya bersama-sama menciptakan disiplin baru dalam pengembangan perangkat lunak. Kami mulai dengan mengeksplorasi pemahaman dasar kami tentang pengembangan perangkat lunak. Setelah itu, kami benar-benar membuat disiplin baru. Kemudian kami memeriksa implikasi dari apa yang telah kami buat - bagaimana itu dapat diterapkan dan digunakan dalam praktik, kapan tidak boleh digunakan, dan peluang apa yang terbuka untuk bisnis.

Buku ini dibagi menjadi tiga bagian.

Masalah: dalam bab yang dimulai dengan Risiko: masalah utama dan berakhir Kembali ke dasar, masalah yang coba dipecahkan oleh pemrograman ekstrem ditentukan, dan kriteria ditetapkan untuk menilai kualitas solusi. Pada bagian ini, Anda akan mendapatkan gambaran tentang teknik pemrograman ekstrim.

Larutan: dalam bab yang dimulai dengan Ulasan singkat dan berakhir Strategi pengujian, ide-ide abstrak yang disajikan di bagian pertama buku ini berubah menjadi seperangkat metode disiplin ilmu tertentu. Bab ini tidak berisi informasi apa pun tentang bagaimana tepatnya Anda dapat menerapkan teknik-teknik yang dijelaskan dalam praktik. Sebaliknya, ini tentang bentuk umum dari masing-masing teknik. Saat saya membahas setiap teknik, saya menghubungkannya dengan masalah dan prinsip yang dibahas di bagian pertama buku ini.

implementasi XP: dalam bab yang dimulai dengan implementasi XP dan berakhir XP beraksi, membahas banyak masalah yang terkait dengan implementasi XP - bagaimana menerapkan XP, apa yang diharapkan dari berbagai orang yang terlibat dalam proyek XP, jenis XP apa yang dimiliki orang di dunia bisnis.

Ucapan Terima Kasih

Saya berbicara kepada pembaca sebagai orang pertama bukan karena buku ini menyajikan ide-ide saya sendiri, tetapi karena saya memberi tahu Anda tentang persepsi saya sendiri tentang ide-ide ini. Sebagian besar teknik yang digunakan di XP setua semua pemrograman.

Ward Cunningham adalah sumber bahan utama saya untuk buku ini. Bagaimanapun, saya telah menghabiskan lima belas tahun terakhir hanya mencoba menjelaskan kepada orang lain apa yang telah dilakukan Ward dalam praktik untuk waktu yang lama. Terima kasih juga kepada Ron Jeffries karena telah mencoba ini juga dan kemudian membuat peningkatan besar. Terima kasih kepada Martin Fowler karena telah menjelaskan semua ini dengan bahasa yang sederhana, lembut, dan tanpa gangguan saraf. Terima kasih kepada Erich Gamma untuk percakapan panjang yang dikombinasikan dengan perenungan angsa di Limm, dan juga untuk fakta bahwa dia tidak membiarkan saya meninggalkannya dengan pikiran buruk di kepala saya. Dan tentu saja, semua ini tidak akan terjadi dalam hidup saya jika saya tidak memiliki panutan seperti ayah saya, Doug Beck, yang telah mengasah keterampilan pemrogramannya selama bertahun-tahun.

Terima kasih kepada tim C3 di Chrysler yang telah menemani saya dalam penelitian saya. Dan juga terima kasih khusus kepada manajer kami Sue Unger dan Ron Savage karena memiliki keberanian untuk mencoba kami.

Terima kasih kepada Daedalos Consulting yang telah membantu saya menulis buku ini.

Juara Menonton pergi ke Paul Chisholm untuk komentarnya yang berlimpah, ringkas, cermat, dan sering kali benar-benar menjengkelkan. Tanpa bantuannya buku ini tidak akan setengah populer.

Saya sangat menikmati berkomunikasi dengan semua orang yang melakukannya pratinjau dari apa yang saya tulis.

Pekerjaan mereka sangat membantu saya. Saya tidak dapat menemukan kata-kata terima kasih atas fakta bahwa mereka memiliki kesabaran untuk membaca sampai akhir semua prosa ini, karena banyak dari mereka ditulis dalam bahasa asing.

Terima kasih kepada (secara acak terdaftar di mana saya menerima komentar dari mereka) Greg Hutchinson, Massimo Arnoldi, Dave Cleal, Sames Schuster, Don Wells, Joshua Kerievsky, Thorsten Dittmar, Moritz Becker, Daniel Gubler, Christoph Henrici, Thomas Zang, Dirk Koenig, Dierk Koenig Miroslav Novak, Rodney Rayan, Frank Westphal, Paul Trunz, Steve Hayes, Kevin Bradtke, Jeanine De Guzman, Tom Kubit, Falk Bruegmann, Hasko Heinecke, Peter Merel, Rob Mee, Pete McBreen, Thomas Ernst, Guido Guido Haechler, Dieter Holz , Martin Knecht, Dirk Crump ( Dierk Krampe, Patrick Lisser, Elisabeth Maier, Thomas Mancini, Alexio Moreno, Rolf Pfenninger dan Matthias Ressel.

Dari penerbit

Kirim komentar, saran, pertanyaan Anda ke alamat Surel [dilindungi email](rumah penerbitan Peter, edisi komputer).

Kami akan senang mendengar dari Anda!

Semua teks sumber yang diberikan dalam buku ini dapat ditemukan di http://www.piter.com/download.

Di situs web penerbit http://www.piter.com Anda akan menemukan informasi rinci tentang buku-buku kami.

Masalah

Bagian buku ini mempersiapkan adegan di mana pemrograman ekstrem akan muncul di masa depan. Ini menggambarkan berbagai aspek masalah yang harus dipecahkan dengan membentuk disiplin baru pengembangan perangkat lunak.

Bagian ini membahas asumsi dasar yang perlu kita ingat ketika memilih praktik pengembangan perangkat lunak - metafora penggerak, empat makna, prinsip yang terbentuk dari makna tersebut, dan aktivitas yang perlu terstruktur dalam disiplin baru pengembangan perangkat lunak.

Risiko: masalah utama

Disiplin pengembangan perangkat lunak yang ada tidak berfungsi dan tidak memberikan efek ekonomi yang diinginkan. Masalah ini memiliki makna ekonomi dan kemanusiaan yang sangat besar. Kami membutuhkan cara baru dalam pengembangan perangkat lunak.

Masalah utama dalam pengembangan perangkat lunak adalah mempertaruhkan.

Berikut adalah beberapa contoh risiko.

Grafik offset- hari pengiriman pekerjaan tiba, dan Anda dipaksa untuk memberi tahu pelanggan bahwa sistem yang sedang dikembangkan tidak akan siap selama enam bulan lagi.

Menutup proyek- setelah beberapa shift jadwal dan penundaan tanggal pengiriman, proyek ditutup, bahkan tanpa dibawa ke tahap pengujian dalam kondisi kerja.

Sistem kehilangan kegunaannya- perangkat lunak yang dikembangkan berhasil diinstal di lingkungan kerja produksi nyata, tetapi setelah beberapa tahun digunakan, biaya untuk mengubahnya dan / atau jumlah cacat meningkat sedemikian rupa sehingga menjadi lebih murah untuk mengganti sistem dengan pengembangan baru.

- sistem perangkat lunak dipasang di lingkungan kerja produksi nyata, tetapi jumlah cacat dan kekurangan sangat besar sehingga sistem tidak digunakan.

- sistem perangkat lunak dipasang di lingkungan produksi nyata, tetapi ternyata itu tidak benar-benar menyelesaikan masalah bisnis yang awalnya ingin dipecahkan.

Mengubah sifat bisnis- sistem perangkat lunak sedang dipasang di lingkungan produksi nyata, namun, selama enam bulan terakhir, masalah yang ingin dipecahkan oleh sistem telah kehilangan relevansinya, dan sebaliknya, bisnis dihadapkan pada masalah baru yang bahkan lebih serius .

Kurangnya kesempatan- sistem perangkat lunak memiliki banyak fitur yang berpotensi menarik, yang masing-masing sangat menyenangkan untuk diprogram, tetapi ternyata tidak satu pun dari fitur ini yang tidak memberikan banyak manfaat bagi pelanggan.

Pergantian staf- dalam dua tahun kerja, semua programmer yang baik yang mengerjakan proyek itu, satu per satu, membenci sistem perangkat lunak yang dikembangkan dan pergi ke pekerjaan lain.

Pada halaman buku ini, Anda akan membaca tentang pemrograman ekstrim ( Pemrograman Ekstrem, XP) adalah disiplin pengembangan perangkat lunak yang berfokus pada pengurangan risiko di semua tingkat proses pengembangan. XP berkontribusi pada peningkatan yang signifikan dalam produktivitas dan peningkatan kualitas program yang dikembangkan, selain itu, ini adalah praktik yang sangat menghibur, memberikan banyak kesenangan kepada semua pesertanya.

Bagaimana XP mengurangi risiko di atas?

Grafik offset- XP mengusulkan untuk menggunakan waktu rilis yang sangat singkat untuk setiap versi berikutnya. Diasumsikan bahwa setiap versi sistem siap pakai berikutnya dikembangkan dalam waktu maksimum beberapa bulan. Dengan demikian, jumlah pekerjaan dalam setiap versi terbatas, yang berarti jika ada pergeseran, itu kurang signifikan. Setiap versi akan menyertakan beberapa iterasi dari fitur yang diminta pelanggan, yang masing-masing membutuhkan waktu satu hingga empat minggu untuk dikembangkan. Ini memberikan umpan balik yang fleksibel dan responsif kepada pelanggan, sehingga ia mendapatkan gambaran tentang kemajuan pekerjaan saat ini. Dalam setiap iterasi, perencanaan sesuai dengan XP dilakukan dalam hal beberapa tugas yang perlu diselesaikan untuk mendapatkan iterasi berikutnya. Satu hingga tiga hari dialokasikan untuk penyelesaian setiap tugas. Hasilnya, tim dapat mendeteksi dan memperbaiki masalah bahkan selama iterasi. Terakhir, XP mengasumsikan bahwa fitur dengan prioritas tertinggi akan diimplementasikan terlebih dahulu. Dengan demikian, fitur apa pun yang tidak dapat diimplementasikan dalam kerangka produk perangkat lunak versi berikutnya ini memiliki prioritas yang lebih rendah.

Menutup proyek- di dalam XP, pelanggan harus menentukan kumpulan kemampuan terkecil yang diizinkan yang harus dimiliki oleh versi minimum program yang dapat diterapkan yang masuk akal dari sudut pandang pemecahan masalah bisnis. Dengan demikian, pemrogram perlu melakukan upaya minimum agar pelanggan memahami apakah dia membutuhkan proyek ini atau tidak.

Sistem kehilangan kegunaannya- dalam XP, sejumlah besar tes dibuat dan dipelihara, yang diluncurkan dan dimulai kembali setelah perubahan apa pun dilakukan pada sistem (beberapa kali sehari), berkat ini dimungkinkan untuk memantau dengan cermat kualitas program yang sedang dikembangkan . XP menjaga sistem dalam kondisi sangat baik setiap saat. Cacat tidak diperbolehkan menumpuk.

Jumlah cacat dan kekurangan- dalam XP, sistem yang sedang dikembangkan diuji baik oleh pemrogram yang membuat pengujian untuk setiap fungsi yang dikembangkan secara individu, dan oleh pelanggan yang membuat pengujian untuk setiap fitur sistem yang diterapkan secara individu.

Inkonsistensi dengan masalah yang sedang dipecahkan- di dalam XP, pelanggan merupakan bagian integral dari tim yang mengerjakan proyek. Spesifikasi proyek terus-menerus direvisi selama seluruh periode pengerjaan proyek, berkat klarifikasi dan penemuan apa pun yang diberitahukan oleh pelanggan kepada tim pengembangan segera tercermin dalam program yang dikembangkan.

Pemrograman Ekstrim: Pengembangan Berbasis Uji

Didedikasikan untuk Cindy: sayap jiwaku

Hak penerbitan diperoleh berdasarkan kesepakatan dengan Addison-Wesley Longman. Seluruh hak cipta. Dilarang memperbanyak sebagian atau seluruh isi buku ini dalam bentuk apapun tanpa izin tertulis dari pemegang hak cipta.

Informasi yang terkandung dalam buku ini telah diperoleh dari sumber yang dianggap dapat dipercaya oleh penerbit. Namun, mengingat kemungkinan kesalahan manusia atau teknis, penerbit tidak dapat menjamin keakuratan dan kelengkapan mutlak dari informasi yang diberikan dan tidak bertanggung jawab atas kemungkinan kesalahan yang terkait dengan penggunaan buku.

ISBN 978-0321146533 Bahasa Inggris.

ISBN 978-5-496-02570-6

Kata pengantar

Bersihkan kode yang berfungsi(kode bersih yang berfungsi) - Garis pendek tapi bernas ini, diciptakan oleh Ron Jeffries, adalah inti dari Test-Driven Development (TDD). Kode bersih yang berfungsi adalah tujuan yang layak diperjuangkan karena

Ini adalah cara yang dapat diprediksi untuk mengembangkan program. Anda tahu kapan pekerjaan dapat dianggap selesai dan tidak khawatir tentang serangkaian kesalahan yang panjang;

Memberi Anda kesempatan untuk mempelajari pelajaran yang diajarkan kode tersebut. Jika Anda menggunakan ide pertama yang muncul dalam pikiran, Anda tidak akan memiliki kesempatan untuk mengimplementasikan ide kedua yang lebih baik;

Meningkatkan kehidupan pengguna program Anda;

Memungkinkan kolega Anda mengandalkan Anda dan Anda mengandalkan mereka;

Lebih menyenangkan menulis kode seperti ini.

Tetapi bagaimana Anda mendapatkan kode bersih yang berfungsi? Banyak kekuatan mencegah kita mendapatkan kode bersih, dan terkadang kita bahkan tidak bisa mendapatkan kode yang berfungsi. Untuk menghilangkan banyak masalah, kami akan mengembangkan kode dengan mengandalkan pengujian otomatis. Gaya pemrograman ini disebut pengembangan yang digerakkan oleh tes. Menurut teknik ini

Kode baru ditulis hanya setelah tes otomatis ditulis dan gagal;

Setiap duplikasi dihilangkan.

Dua aturan sederhana, Bukankah itu? Namun, mereka menghasilkan perilaku individu dan kelompok yang kompleks dengan banyak implikasi teknis:

Selama proses desain, kami terus-menerus menjalankan kode dan mendapatkan ide tentang pekerjaannya, ini membantu untuk membuat keputusan yang tepat;

Kami menulis tes sendiri, karena kami tidak sabar menunggu orang lain menulis tes untuk kami;

Lingkungan pengembangan kita harus merespon dengan cepat terhadap modifikasi kode kecil;

Desain program harus didasarkan pada penggunaan banyak komponen mandiri yang digabungkan secara longgar untuk memudahkan pengujian kode.

Dua aturan TDD yang disebutkan menentukan urutan langkah-langkah pemrograman.

1. Merah - tulis tes kecil yang tidak berhasil, dan bahkan mungkin tidak dapat dikompilasi.

2. Hijau - lakukan pengujian secepat mungkin, tanpa memikirkan desain yang benar dan kode yang bersih. Tulis kode yang cukup untuk membuat tes berfungsi.

3. Refactoring - menghilangkan duplikasi dari kode tertulis.

Merah - hijau - refactoring adalah mantra TDD.

Jika kita berasumsi bahwa gaya pemrograman seperti itu mungkin, kita dapat mengasumsikan bahwa berkat penggunaannya, kode akan mengandung lebih sedikit cacat, selain itu, tujuan pekerjaan akan jelas bagi semua orang yang mengambil bagian di dalamnya. Jika demikian, maka hanya mengembangkan kode yang diperlukan untuk lulus tes juga memiliki implikasi sosial:

Dengan kepadatan cacat yang cukup rendah, tim Quality Assurance (QA) akan dapat beralih dari menanggapi kesalahan menjadi mencegahnya;

Dengan mengurangi jumlah kejutan yang tidak menyenangkan, manajer proyek akan dapat memperkirakan biaya tenaga kerja secara lebih akurat dan melibatkan pelanggan dalam proses pengembangan;

Jika topik diskusi teknis didefinisikan dengan jelas, pemrogram dapat berinteraksi satu sama lain secara teratur, bukan sekali sehari atau seminggu sekali;

Sekali lagi, dengan kepadatan cacat yang cukup rendah, kami akan dapat memiliki produk kerja yang terintegrasi setiap hari dengan fungsionalitas baru yang ditambahkan ke dalamnya sehingga kami dapat memasuki jenis hubungan bisnis yang sama sekali baru dengan pelanggan kami.

Jadi idenya sederhana, tapi apa minat kita? Mengapa seorang programmer harus mengambil tanggung jawab ekstra untuk menulis tes otomatis? Mengapa seorang programmer mengambil langkah kecil ke depan ketika otaknya mampu memikirkan struktur desain yang jauh lebih kompleks? Keberanian.

Keberanian

TDD adalah cara untuk mengelola rasa takut dalam proses pemrograman. Maksud saya bukan takut jatuh dari kursi atau takut bos. Maksud saya ketakutan akan suatu masalah "begitu sulit sehingga saya masih tidak tahu bagaimana menyelesaikannya." Rasa sakit adalah ketika alam memberi tahu kita: "Berhenti!" Dan ketakutan adalah ketika alam memberi tahu kita: "Hati-hati!" Berhati-hati bukanlah hal yang buruk, tetapi selain bermanfaat, rasa takut memiliki beberapa efek negatif pada kita:

Ketakutan memaksa kita untuk berpikir terlebih dahulu dan hati-hati tentang apa yang dapat menyebabkan tindakan ini atau itu;

Ketakutan membuat kita kurang berkomunikasi;

Ketakutan membuat kita terintimidasi oleh ulasan tentang pekerjaan kita;

Ketakutan membuat kita mudah tersinggung.

Semua ini tidak berguna untuk proses pemrograman, terutama jika Anda sedang mengerjakan masalah yang kompleks. Jadi, kita dihadapkan pada pertanyaan bagaimana keluar dari situasi yang sulit dan

Jangan mencoba memprediksi masa depan, tetapi segera mulai studi praktis tentang masalah tersebut;

Tidak berpagar dari seluruh dunia, tetapi meningkatkan tingkat komunikasi;

Jangan menghindari umpan balik, tetapi, sebaliknya, buat umpan balik yang andal dan, dengan bantuannya, pantau dengan cermat hasil tindakan Anda;

(Anda harus mengatasi gangguan itu sendiri).

Bandingkan pemrograman dengan mengangkat ember dari sumur. Ember diisi dengan air, Anda memutar tuas, melilitkan rantai di sekitar gerbang dan mengangkat ember ke atas. Jika embernya kecil, kerah yang berputar bebas dan teratur baik-baik saja. Tetapi jika embernya besar dan berat, Anda akan lelah sebelum mengambilnya. Untuk dapat beristirahat di antara putaran tuas, diperlukan ratchet untuk menahan tuas di tempatnya. Semakin berat ember, semakin sering gigi pada roda gigi ratchet harus mengikuti.

Tes di TDD adalah gigi pada gigi ratchet. Dengan membuat tes bekerja, kita tahu bahwa tes sekarang bekerja, sekarang dan selamanya. Kami selangkah lebih dekat untuk menyelesaikan pekerjaan daripada sebelum tes mulai bekerja. Setelah itu, kami memaksa tes kedua untuk bekerja, lalu yang ketiga, keempat, dan seterusnya.Semakin kompleks masalah yang dihadapi programmer, semakin sedikit fungsionalitas yang harus dicakup oleh setiap tes.

Pembaca buku Penjelasan Pemrograman Ekstrim pasti telah memperhatikan perbedaan nada antara Extreme Programming (XP) dan Test-Driven Development (TDD). Tidak seperti XP, TDD tidak mutlak. XP mengatakan "Anda harus menguasai ini dan itu untuk maju." TDD adalah teknik yang kurang spesifik. TDD mengasumsikan ada interval antara pengambilan keputusan dan hasil, dan menawarkan alat untuk mengontrol panjang interval ini. “Bagaimana jika, selama seminggu, saya merancang algoritma di atas kertas dan kemudian menulis kode menggunakan pendekatan tes pertama? Apakah ini akan sesuai dengan TDD?" Tentu saja. Anda mengetahui panjang interval antara membuat keputusan dan mengevaluasi hasil dan secara sadar mengontrol interval ini.

Kebanyakan orang yang telah menguasai TDD mengklaim bahwa praktik pemrograman mereka telah berubah menjadi lebih baik. Terinfeksi oleh tes(tes terinfeksi) adalah definisi yang diciptakan Erich Gamma untuk menggambarkan perubahan ini. Setelah Anda menguasai TDD, Anda mendapati diri Anda menulis lebih banyak tes secara signifikan daripada sebelumnya, dan bergerak maju dalam langkah-langkah kecil yang tampaknya tidak ada gunanya bagi Anda sebelumnya. Di sisi lain, beberapa programmer, setelah menjadi akrab dengan TDD, memutuskan untuk kembali ke praktik lama, memesan TDD untuk kasus-kasus khusus ketika pemrograman konvensional tidak mengarah pada kemajuan yang diinginkan.

Tentu saja, ada masalah yang tidak dapat (setidaknya untuk saat ini) diselesaikan dengan tes saja. Secara khusus, TDD tidak memungkinkan untuk secara mekanis menunjukkan kecukupan kode yang dikembangkan dalam hal keamanan data dan keandalan operasi paralel. Tentu saja, keamanan didasarkan pada kode yang harus bebas dari cacat, tetapi juga didasarkan pada partisipasi manusia dalam prosedur perlindungan data. Masalah konkurensi yang halus tidak dapat direproduksi dengan pasti hanya dengan menjalankan beberapa kode.