pengalaman saya selama bertahun-tahun dalam pengembangan perangkat lunak menunjukkan bahwa dalam praktiknya itu tidak bisa bekerja.
Sudahkah Anda mencobanya? Dave dan saya menulis buku berdasarkan pengalaman bertahun-tahun bersama, baik diri kita sendiri maupun orang-orang senior lainnya di ThoughtWorks, benar-benar melakukan hal-hal yang kita diskusikan. Tidak ada dalam buku ini yang spekulatif. Segala sesuatu yang kita diskusikan telah dicoba dan diuji bahkan pada proyek-proyek besar yang didistribusikan. Tetapi kami tidak menyarankan Anda mengambilnya dengan iman. Tentu saja Anda harus mencobanya sendiri, dan tolong tulis apa yang Anda temukan berhasil dan yang tidak, termasuk konteks yang relevan, sehingga orang lain dapat belajar dari pengalaman Anda.
Pengiriman Berkelanjutan memiliki fokus besar pada pengujian otomatis. Kami menghabiskan sekitar 1/3 buku untuk membicarakannya. Kami melakukan ini karena alternatifnya - pengujian manual - mahal dan rawan kesalahan, dan sebenarnya bukan cara yang bagus untuk membangun perangkat lunak berkualitas tinggi (seperti yang dikatakan Deming, "Hentikan ketergantungan pada inspeksi massal untuk mencapai kualitas. Tingkatkan proses dan bangun kualitas menjadi produk di tempat pertama ")
Cakupan tes penuh tidak mungkin. Anda harus meluangkan banyak waktu - dan waktu adalah uang - untuk setiap hal kecil. Ini berharga, tetapi waktu dapat dihabiskan untuk berkontribusi pada kualitas dengan cara lain.
Tentu saja cakupan tes penuh tidak mungkin, tetapi apa alternatifnya: cakupan tes nol? Ada trade-off. Di suatu tempat di antara keduanya adalah jawaban yang benar untuk proyek Anda. Kami menemukan bahwa secara umum Anda harus menghabiskan sekitar 50% dari waktu Anda membuat atau mempertahankan tes otomatis. Itu mungkin terdengar mahal sampai Anda mempertimbangkan biaya pengujian manual yang komprehensif, dan memperbaiki bug yang keluar untuk pengguna.
Beberapa hal sulit untuk diuji secara otomatis. Misalnya GUI. Bahkan Selenium tidak akan memberi tahu Anda jika GUI Anda miring.
Tentu saja. Periksa kuadran tes Brian Marick. Anda masih perlu melakukan pengujian eksplorasi dan pengujian kegunaan secara manual. Tetapi untuk itulah Anda harus menggunakan manusia Anda yang mahal dan berharga - bukan pengujian regresi. Kuncinya adalah Anda harus memasang pipa penempatan agar Anda hanya perlu repot menjalankan validasi manual yang mahal terhadap bangunan yang telah lulus serangkaian pengujian otomatis yang komprehensif. Dengan demikian Anda berdua mengurangi jumlah uang yang Anda habiskan untuk pengujian manual, dan jumlah bug yang pernah sampai ke uji manual atau produksi (pada saat itu mereka sangat mahal untuk memperbaikinya). Pengujian otomatis yang dilakukan dengan benar jauh lebih murah daripada siklus hidup produk, tetapi tentu saja ini merupakan pengeluaran modal yang diamortisasi dengan sendirinya seiring waktu.
Akses database sulit untuk diuji tanpa alat berat, dan bahkan itu tidak akan mencakup kasus sudut aneh dalam penyimpanan data Anda. Demikian juga keamanan dan banyak hal lainnya. Hanya kode lapisan bisnis yang secara efektif dapat diuji unit.
Akses basis data diuji secara implisit oleh tes penerimaan fungsional berbasis skenario end-to-end Anda. Keamanan akan memerlukan kombinasi pengujian otomatis dan manual - pengujian penetrasi otomatis dan analisis statis untuk menemukan (mis.) Buffer overruns.
Bahkan di lapisan bisnis, sebagian besar kode di luar tidak ada fungsi sederhana yang argumen dan nilai pengembaliannya dapat dengan mudah diisolasi untuk keperluan pengujian. Anda dapat menghabiskan banyak waktu membangun objek tiruan, yang mungkin tidak sesuai dengan implementasi nyata.
Tentu saja tes otomatis mahal jika Anda membangun perangkat lunak Anda dan tes Anda buruk. Saya sangat merekomendasikan membaca buku "mengembangkan perangkat lunak berorientasi objek, dipandu oleh tes" untuk memahami bagaimana melakukannya dengan benar sehingga tes dan kode Anda dapat dipertahankan dari waktu ke waktu.
Tes integrasi / fungsional melengkapi tes unit, tetapi ini membutuhkan banyak waktu untuk dijalankan karena biasanya melibatkan menginisialisasi ulang seluruh sistem pada setiap pengujian. (Jika Anda tidak menginisialisasi ulang, lingkungan pengujian tidak konsisten.)
Salah satu produk yang saya kerjakan memiliki serangkaian 3.500 tes penerimaan ujung ke ujung yang membutuhkan waktu 18 jam untuk berjalan. Kami menjalankannya secara paralel pada kotak 70 kotak dan mendapatkan umpan balik dalam 45 m. Masih lebih lama dari ideal sebenarnya, itulah sebabnya kami menjalankannya sebagai tahap kedua dalam pipa setelah unit test berjalan dalam beberapa menit sehingga kami tidak membuang-buang sumber daya kami pada build yang kami tidak memiliki tingkat dasar kepercayaan pada.
Refactoring atau perubahan lainnya mematahkan banyak tes. Anda menghabiskan banyak waktu untuk memperbaikinya. Jika itu masalah memvalidasi perubahan spec yang berarti, itu bagus, tetapi sering kali tes berhenti karena detail implementasi tingkat rendah yang tidak berarti, bukan hal-hal yang benar-benar memberikan informasi penting. Seringkali tweaker difokuskan pada pengerjaan ulang internal tes, bukan pada benar-benar memeriksa fungsi yang sedang diuji.
Jika kode dan tes Anda dienkapsulasi dengan baik dan longgar, refactoring tidak akan merusak banyak tes. Kami menjelaskan dalam buku kami bagaimana melakukan hal yang sama untuk tes fungsional juga. Jika tes penerimaan Anda pecah, itu pertanda bahwa Anda kehilangan satu atau lebih tes unit, jadi bagian dari CD melibatkan terus meningkatkan cakupan tes Anda untuk mencoba dan menemukan bug sebelumnya dalam proses pengiriman di mana tes lebih halus dan bug lebih murah untuk diperbaiki.
Laporan lapangan tentang bug tidak dapat dengan mudah dicocokkan dengan versi mikro kode yang tepat.
Jika Anda pengujian sedang dan melepaskan lebih sering (bagian dari titik CD) maka adalah relatif mudah untuk mengidentifikasi perubahan yang menyebabkan bug. Inti dari CD adalah untuk mengoptimalkan siklus umpan balik sehingga Anda dapat mengidentifikasi bug sesegera mungkin setelah mereka diperiksa untuk kontrol versi - dan memang, lebih baik sebelum mereka diperiksa (itulah sebabnya kami menjalankan uji coba membangun dan unit sebelum check-in).