Menerapkan pengujian unit pada perusahaan yang tidak melakukannya

Kepala pengembangan perangkat lunak perusahaan saya baru saja "mengundurkan diri" (yaitu dipecat) dan kami sekarang sedang mencari cara untuk meningkatkan praktik pengembangan di perusahaan kami. Kami ingin menerapkan pengujian unit di semua perangkat lunak yang dibuat mulai sekarang.

Umpan balik dari para pengembang adalah ini:

• Kami tahu pengujian itu berharga
• Tapi, Anda selalu mengubah spesifikasi sehingga akan membuang-buang waktu
• Dan, tenggat waktu Anda sangat ketat sehingga kami tidak punya cukup waktu untuk mengujinya

Umpan balik dari CEO adalah ini:

• Saya ingin perusahaan kami memiliki pengujian otomatis, tetapi saya tidak tahu bagaimana cara mewujudkannya
• Kami tidak punya waktu untuk menulis dokumen spesifikasi besar

Bagaimana pengembang mendapatkan spesifikasi sekarang? Dari mulut ke mulut atau slide PowerPoint. Jelas, itu masalah besar. Saran saya adalah ini:

• Mari kita juga memberikan pengembang satu set data uji dan tes unit
• Itu speknya. Terserah manajemen untuk menjadi jelas dan kuantitatif tentang apa yang diinginkannya.
• Pengembang dapat menempatkannya apa pun fungsionalitas lain yang menurut mereka diperlukan dan tidak perlu dicakup oleh tes

Nah, jika Anda pernah berada di perusahaan yang berada dalam situasi ini, bagaimana Anda memecahkan masalah? Apakah pendekatan ini masuk akal?

Tampaknya Anda menggabungkan dua jenis tes: tes unit dan tes sistem / penerimaan . Yang pertama beroperasi pada tingkat yang lebih rendah, menguji potongan-potongan kecil kode (biasanya metode individual), yang biasanya berada jauh di dalam program, tidak langsung terlihat oleh pengguna. Yang terakhir menguji seluruh program seperti yang terlihat oleh penggunanya, pada tingkat granularitas yang jauh lebih tinggi. Dengan demikian, hanya yang terakhir yang dapat didasarkan pada segala bentuk spesifikasi sistem.

Memisahkan kedua masalah memudahkan untuk mulai bergerak menuju proses pembangunan yang lebih baik. Mulailah menulis unit test sesegera mungkin , terlepas dari bagaimana perangkat lunak (tidak) ditentukan pada level tinggi. Setiap kali pengembang membuat atau mengubah metode, itu melakukan sesuatu yang konkret, yang dapat (dan harus) diuji unit. Dalam pengalaman saya, bahkan mengubah persyaratan tingkat tinggi biasanya tidak mempengaruhi blok kode tingkat rendah ini secara dramatis: kode sebagian besar perlu disusun ulang, daripada dibuang atau ditulis ulang sepenuhnya. Akibatnya, sebagian besar unit test yang ada akan tetap berjalan dengan baik.

Satu syarat penting untuk memungkinkan pengujian unit adalah: tenggat waktu tidak boleh diputuskan oleh manajemen di muka, tetapi sebaliknya harus didasarkan pada perkiraan kerja oleh pengembang (yang pada gilirannya harus memasukkan dalam estimasi mereka waktu yang diperlukan untuk menulis pengujian unit yang tepat). Atau, jika tenggat waktu ditetapkan, ruang lingkup pengiriman harus dinegosiasikan. Tidak ada jumlah manajemen (mis) yang dapat mengubah kebenaran mendasar bahwa sejumlah pengembang tertentu hanya dapat memberikan sejumlah pekerjaan berkualitas dalam jumlah waktu tertentu.

Bersamaan dengan ini, mulailah membahas cara terbaik untuk mengklarifikasi dan mendokumentasikan persyaratan dan mengubahnya menjadi tes penerimaan tingkat tinggi. Ini adalah proses penyempurnaan berturut-turut yang lebih lama, yang dapat dengan mudah memakan waktu bertahun-tahun untuk mencapai kondisi yang lebih baik dan stabil di seluruh organisasi. Satu hal yang tampaknya cukup pasti dari deskripsi Anda: mencoba memperbaiki persyaratan yang terus berubah dengan menulis dokumen spesifikasi besar di muka tidak akan berhasil . Sebagai gantinya, disarankan untuk bergerak menuju pendekatan yang lebih gesit, dengan rilis perangkat lunak yang sering dan demonstrasi kepada pengguna, dan banyak diskusi tentang apa yang sebenarnya mereka inginkan. Pengguna memiliki hak untuk mengubah pikirannya tentang persyaratan kapan saja - namun, setiap perubahan memiliki biayanya (dalam waktu dan uang). Pengembang dapat memperkirakan biaya untuk setiap permintaan perubahan, yang pada gilirannya memungkinkan pengguna / pemilik produk untuk membuat keputusan yang tepat. "Tentunya, perubahan fitur ini akan menyenangkan ... tetapi jika menunda rilis fitur penting lainnya ini, dan menghabiskan biaya sebanyak ini, mari kita masukkan ke dalam simpanan untuk sekarang".

Membuat pengguna mendefinisikan kasus uji penerimaan dan membuat data uji adalah cara yang bagus untuk melibatkan mereka lebih banyak, dan untuk membangun rasa saling percaya antara pengguna dan pengembang. Hal ini memaksa kedua belah pihak untuk fokus pada kriteria penerimaan yang konkret, terukur, dapat diuji, dan berpikir menggunakan kasus secara lebih rinci daripada tipikal. Akibatnya, pengguna dapat memeriksa status pengembangan saat ini secara langsung dengan setiap rilis, dan pengembang mendapatkan umpan balik pengukuran yang lebih nyata dan nyata tentang status proyek. Namun perlu dicatat bahwa ini membutuhkan komitmen yang lebih besar dari pengguna, dan cara operasi baru, yang mungkin merupakan hal yang sulit untuk diterima dan dipelajari.

Pengalaman saya dengan melakukan transisi

Selama bertahun-tahun saya berada di bawah kesalahpahaman bahwa saya tidak punya cukup waktu untuk menulis unit test untuk kode saya. Ketika saya menulis tes, itu adalah hal yang menggembung, hal-hal berat yang hanya mendorong saya untuk berpikir bahwa saya seharusnya hanya menulis unit test ketika saya tahu mereka diperlukan.

Baru-baru ini saya didorong untuk menggunakan Test Driven Development dan saya menemukan itu sebagai wahyu yang lengkap. Saya sekarang sangat yakin bahwa saya tidak punya waktu untuk tidak menulis tes unit .

Dalam pengalaman saya, dengan mengembangkan dengan pengujian dalam pikiran Anda berakhir dengan antarmuka yang lebih bersih, kelas & modul yang lebih fokus dan umumnya lebih SOLID , kode diuji.

Setiap kali saya bekerja dengan kode lama yang tidak memiliki tes unit dan harus menguji sesuatu secara manual, saya terus berpikir "ini akan jauh lebih cepat jika kode ini sudah memiliki unit test". Setiap kali saya harus mencoba dan menambahkan fungsionalitas unit test ke kode dengan kopling tinggi, saya terus berpikir "ini akan jauh lebih mudah jika telah ditulis dengan cara de-coupled".

Membandingkan dan membedakan dua stasiun percobaan yang saya dukung. Satu telah ada untuk sementara waktu dan memiliki banyak kode warisan, sedangkan yang lainnya relatif baru.

Saat menambahkan fungsionalitas ke lab lama, sering kali turun ke lab dan menghabiskan waktu berjam-jam bekerja melalui implikasi fungsionalitas yang mereka butuhkan dan bagaimana saya dapat menambahkan fungsionalitas itu tanpa mempengaruhi fungsi lainnya. Kode sama sekali tidak diatur untuk memungkinkan pengujian off-line, jadi hampir semuanya harus dikembangkan on-line. Jika saya mencoba mengembangkan secara off-line maka saya akan berakhir dengan lebih banyak objek tiruan daripada yang masuk akal.

Di lab yang lebih baru, saya biasanya dapat menambahkan fungsionalitas dengan mengembangkannya secara off-line di meja saya, mengejek hanya hal-hal yang segera diperlukan, dan kemudian hanya menghabiskan waktu singkat di lab, menambal masalah yang tersisa tidak diambil. -baris.

Saranku

Sepertinya Anda telah memulai dengan baik, setiap kali Anda akan membuat perubahan besar pada alur kerja pengembangan Anda, Anda harus memastikan bahwa semua orang terlibat dalam membuat keputusan itu, dan idealnya sebagian besar orang telah setuju. Dari pertanyaan Anda, sepertinya Anda sudah benar. Jika orang tidak memiliki antusiasme terhadap ide itu, itu pasti gagal atau menghasilkan niat buruk.

Kecuali Anda dapat menyajikan kasus bisnis yang menarik, saya tidak akan merekomendasikan implementasi pengujian unit dan spesifikasi untuk seluruh sistem Anda. Seperti yang saya sebutkan di atas, jika suatu sistem tidak dirancang dengan pengujian dalam pikiran, bisa sangat sulit untuk menulis tes otomatis untuk itu.

Alih-alih, saya akan merekomendasikan mulai dari yang kecil dan menggunakan Aturan Pramuka :

Selalu tinggalkan perkemahan lebih bersih daripada yang Anda temukan.

Jika saat Anda menerapkan sesuatu pada basis kode ini, Anda dapat mengidentifikasi tes khusus yang diperlukan untuk menguji perilaku yang ada dan transisi dari perilaku lama ke yang baru, maka Anda telah mendokumentasikan perubahan dalam spesifikasi dan memulai penerapan unit pengujian untuk sistem anda.

Modul yang tidak Anda sentuh tidak mendapatkan tes unit, tetapi jika Anda tidak menyentuhnya maka itu mungkin karena mereka telah diuji secara menyeluruh dalam penggunaan dan tidak memerlukan perubahan, atau mereka tidak pernah digunakan.

Yang ingin Anda hindari adalah menyia-nyiakan seluruh tes menulis upaya pengembang yang tidak akan pernah diperlukan ( YAGNI bekerja dengan baik untuk kode uji seperti untuk kode produksi * 8 '), tidak akan pernah digunakan lagi dan menurunkan moral orang menjadi berpikir bahwa tes tidak berguna sama sekali.

Ringkasan

Mulailah dari yang kecil, bangun kepercayaan pada tes secara bertahap dan dapatkan nilai bisnis dari mengembangkan tes kapan dan di mana mereka paling menguntungkan tim Anda.

Hal pertama yang harus dilakukan adalah berkonsentrasi bukan pada pengujian, tetapi pada proses keseluruhan yang benar. Tidak ada gunanya menguji apa pun jika Anda tidak sepenuhnya memahami apa yang seharusnya dilakukan!

Jadi .. spesifikasi pertama, dan spesifikasi terdokumentasi yang tidak berubah (well, tidak langsung). Anda harus melihat menyelesaikannya. Saya akan merekomendasikan situs web tempat pengguna dapat mengunggah spesifikasi, atau mengetiknya secara langsung. Anda juga dapat menautkan itu ke pelacak bug dan panduan tentang kemajuan proyek.

Kemungkinannya, itulah yang benar-benar Anda butuhkan. Anda dapat menambahkan pengujian unit ke internal dan manajemen tidak perlu tahu bahwa pengembang melakukan pengujian unit. Di satu sisi, begitulah seharusnya.

Anda masih perlu melakukan pengujian sistem, tetapi itu juga dapat ditautkan ke situs web manajemen proyek, begitu dirilis, tim pengujian (bahkan jika itu adalah pengembang beruntung lain pada rotasi) dapat memperbaruinya dengan tes yang telah mereka gunakan untuk melihat apakah semuanya tergantung bersama.

Sejujurnya saya tidak berpikir ini akan berubah dalam semalam, jika Anda terbiasa mendapatkan spesifikasi 'dari mulut ke mulut', maka pertempuran hampir seluruhnya akan mengubah perilaku ini - dan Anda akan mendapatkan perlawanan terhadap ini. Seorang pengguna (atau BA atau PM atau siapa pun) yang terbiasa mengatakan "lakukan saja x" dan sekarang perlu menuliskan semuanya tidak akan merespon dengan baik, kemungkinan mereka akan menulis dokumen spesifikasi yang tidak jelas dan kemudian mengklarifikasi mereka dengan pembaruan dari mulut ke mulut. Jadi, lupakan pengujian unit, dan mulailah pada masalah besar yang Anda miliki dengan siklus pengembangan.

Masalah pertama: untuk "memberi pengembang satu set data uji dan pengujian unit", Anda harus terlebih dahulu menulis tes unit tersebut, yang merupakan pekerjaan pengembang. Tes unit juga tidak menggantikan spesifikasi: spesifikasi ini dimaksudkan untuk memiliki tingkat abstraksi yang lebih tinggi daripada tes unit.

Masalah kedua: sepertinya Anda menginginkan cakupan unit test maksimum. Dalam hal ini, ya, akan menghabiskan banyak waktu dan biaya untuk menulis tes dan kode dalam konteks di mana persyaratannya terus berubah. Sebagai gantinya, tentukan bagian mana dari kode yang kritis, dan unit hanya menguji bagian-bagian itu. Dalam banyak kasus, persyaratan yang berubah tidak mempengaruhi bagian-bagian penting dari produk. Pelanggan (atau CEO, atau apa pun) biasanya meminta untuk memindahkan panel ini ke kanan, atau mengubah warna judul ini dari merah menjadi hijau: hal-hal yang tidak dipedulikan siapa pun dan yang tidak memerlukan pengujian intensif. Di sisi lain, seorang pelanggan tidak akan pernah meminta untuk mengubah algoritma hash dari SHA512 ke SHA256 atau untuk mengubah cara Anda menyimpan sesi, sementara itu bagian-bagian yang paling membutuhkan pengujian.