Unit dan pengujian Integrasi: Bagaimana itu bisa menjadi refleks

Semua programmer di tim saya sudah terbiasa dengan pengujian unit dan pengujian integrasi. Kita semua telah bekerja dengannya. Kami memiliki semua tes tertulis dengannya. Beberapa dari kita bahkan merasakan peningkatan rasa percaya pada kode mereka sendiri.

Namun, untuk beberapa alasan, tes unit / integrasi tes belum menjadi refleks untuk setiap anggota tim. Tidak seorang pun dari kita yang merasa sedih ketika tidak menulis unit test bersamaan dengan kode yang sebenarnya. Akibatnya, basis kode kami sebagian besar ditemukan oleh tes unit, dan proyek-proyek memasuki produksi yang belum teruji.

Masalah dengan itu, tentu saja adalah bahwa begitu proyek Anda dalam produksi dan sudah bekerja dengan baik, hampir tidak mungkin untuk mendapatkan waktu dan / atau anggaran untuk menambah pengujian unit / integrasi.

Anggota tim saya dan saya sendiri sudah akrab dengan nilai pengujian unit ( 1 , 2 ) tetapi tampaknya tidak membantu membawa pengujian unit ke dalam alur kerja alami kami. Dalam pengalaman saya membuat tes unit dan / atau cakupan target wajib hanya menghasilkan tes kualitas yang buruk dan memperlambat anggota tim hanya karena tidak ada motivasi yang dihasilkan sendiri untuk menghasilkan tes ini. Begitu tekanan mereda, unit test tidak ditulis lagi.

Pertanyaan saya adalah sebagai berikut: Apakah ada metode yang telah Anda coba yang membantu membangun dinamika / momentum di dalam tim, yang mengarah ke orang yang secara alami ingin membuat dan mempertahankan tes tersebut?

Tidak seorang pun dari kita yang merasa sedih ketika tidak menulis unit test bersamaan dengan kode yang sebenarnya.

Ini adalah poin yang perlu Anda atasi. Budaya tim Anda perlu diubah sedemikian rupa sehingga tidak menulis tes selama sprint (atau satuan waktu apa pun yang Anda gunakan) menjadi sebanyak kode berbau seperti nilai hard-coding. Banyak dari itu melibatkan tekanan teman sebaya. Tidak ada yang benar-benar ingin dipandang di bawah standar.

Lakukan tes sendiri. Terlihat mencaci diri sendiri ketika Anda tidak melakukannya. Tunjukkan di mana programmer "baik" akan menangkap bug itu jika mereka menulis unit test. Tidak ada yang ingin menjadi buruk. Jadikan bahwa perilaku yang tidak diinginkan ini buruk dan orang akan mengikuti.

Mendapatkan seluruh tim untuk semua sebenarnya menginginkan hal yang sama bisa sangat sulit. Sering kali melihat nilai dalam sesuatu tidak cukup untuk mendorong orang mengubah perilaku yang sudah mendarah daging. Bahkan mereka yang menghargai perubahan dan yang secara spesifik menginginkannya terkadang juga dapat bertanggung jawab untuk melawannya secara tidak sadar.

Masalahnya sebenarnya adalah motivasi individu dan bukan motivasi tim. Ada saatnya ketika kejelasan mencapai Anda, baik sebagai akibat dari sesuatu yang Anda akhirnya Anda pahami, atau karena beberapa alat baru atau beberapa hal subjektif lainnya yang membuat programmer rata-rata memasukkan semuanya dan sepenuhnya mengubah prosesnya. Pekerjaan Anda - jika Anda memilih untuk tidak melakukannya - adalah untuk melihat apakah ada cara bagi Anda atau tim untuk mengetahui hal - hal apa yang akan menjadi pemicu kejelasan bagi setiap anggota tim individu.

Bagi saya pribadi, itu hanya menemukan kerangka kerja StoryQ untuk BDD di DotNet, yang membuatnya terlalu mudah untuk diabaikan, dan membuat saya benar-benar mengatasi "penghalang" uji-pertama vs uji-secara bersamaan. Kemudian saya mendapat pilihan saya ketika saya menemukan NCrunch untuk Visual Studio. Setengah pertempuran kadang-kadang tidak dalam menjual ide, melainkan hanya dengan menurunkan upaya yang diperlukan untuk memperkenalkan perubahan radikal dalam kebiasaan ... dan bahkan kemudian dapat mengambil sedikit waktu dan kerja. Namun pemicu pribadi yang sama ini tidak cukup untuk mempengaruhi pendekatan kolega saya pada saat itu, yang masih menulis sebanyak mungkin kode pengujian mereka secara bersamaan atau bahkan setelah kode implementasi mereka.

Kadang-kadang juga, ada keengganan untuk mengubah cara melakukan sesuatu, karena rasa takut yang melekat, ketidakpercayaan, atau pandangan tidak menyenangkan dari upaya yang diperlukan untuk belajar melakukan sesuatu yang berbeda, bahkan ketika alasan untuk perubahan itu masuk akal. Jika seluruh platform pengujian Anda dirancang untuk bekerja dengan cara tertentu, mungkin sulit untuk membenarkan mengubah cara berbagai hal dilakukan, dan berpotensi mengubah tooling , terutama ketika tes lama dan baru perlu terus hidup berdampingan selama masa uji coba. proyek - dan Anda tentu tidak ingin menulis ulang setiap tes yang pernah Anda buat. Yang aneh adalah bahwa kadang-kadang orang merasa bahwa ini adalah satu-satunya cara untuk mengadopsi metodologi pengujian baru, dan itu sendiri membuat lebih sulit bagi orang-orang untuk menerima perubahan yang masuk akal menjadi lebih baik.

Sungguh, satu-satunya cara sesuatu menjadi refleksif adalah dengan memaksa diri Anda untuk melakukannya berulang-ulang sampai Anda tidak lagi memperhatikan diri Anda perlu terlalu banyak berkonsentrasi pada bagaimana melakukannya. Kadang-kadang, satu-satunya cara untuk melakukan ini dalam tim adalah dengan menetapkan kebijakan yang mungkin terlihat sedikit kejam, dan untuk mempraktikkan pemrograman pasangan dan ulasan kode, dan hal lain yang dapat membantu anggota tim untuk saling mendukung dan secara harfiah memaksa perubahan dalam perilaku yang terjadi. Namun, agar strategi seperti itu benar-benar berhasil, masih diperlukan komitmen yang kuat dan jujur ​​dari setiap anggota tim individu untuk menerima tindakan seperti yang diperlukan, dan untuk berpartisipasi dalam proses ... dan banyak kesabaran dari semua yang terlibat .

Tidak seorang pun dari kita yang merasa sedih ketika tidak menulis unit test bersamaan dengan kode yang sebenarnya

Tidak yakin apa yang Anda maksud dengan "pada saat yang sama", tetapi bagaimana dengan menuliskannya sebelum kode aktual?

Mudah dipahami dari sudut pandang psikologis mengapa manusia tidak mau repot menulis unit test setelah kode. Pada saat itu kode sudah berfungsi, jadi mengapa kita harus mengujinya? Beberapa jenis kemalasan secara otomatis terjadi karena membosankan, tampaknya tidak berguna dan tidak menulis tes tampaknya tidak berbahaya. Sebagai hasilnya, saya tidak tahu banyak tim yang terus menggunakan pendekatan tes-setelah jangka waktu yang lama.

Dalam pengalaman saya, test-first (gaya TDD), adalah sesuatu yang Anda dapat dengan cepat kecanduan karena setidaknya ada 2 manfaat langsung, nyata, yang melepaskan endorphin:

• Ini membantu Anda mendesain kode Anda secara langsung dengan persyaratan konkret yang dapat dieksekusi dan membuat desain lebih baik dan lebih baik saat Anda refactor, yang jauh lebih terarah dan memuaskan daripada hanya memeriksa ulang sesuatu yang sudah berfungsi.

• Siklus TDD diselingi dengan momen "bilah hijau" yang sering terjadi di mana Anda dapat menikmati cita rasa kesuksesan langsung. Itu terus membuat pikiran Anda puas dan siap untuk pergi untuk menerapkan fitur berikutnya.

Jadi saya tidak akan berusaha membuat tim Anda merasa buruk ketika mereka tidak menulis tes. Sebagai gantinya, saya mencoba membuat mereka merasa baik seperti mereka. TDD adalah salah satu cara untuk melakukan ini.

pertama Anda harus memastikan bahwa menulis tes dan menjalankannya mudah, dapatkan kerangka kerja yang diatur dalam proyek saat ini dan membuat prosedur pengaturan yang mudah untuk dimasukkan dalam proyek-proyek masa depan

dengan cara ini ketika seorang programmer ingin menyatukan fitur baru yang sedang dia coba debug, dia tidak harus melewati selusin simpai untuk mendapatkan tes yang berjalan dengan baik

semakin akward sesuatu yang dilakukan semakin kecil kemungkinannya Anda akan membuat kebiasaan darinya

Satu hal yang telah saya lakukan yang agak berhasil dalam memicu perubahan budaya adalah mengadakan seminar mingguan, "kurasi unit test". Tujuan resmi dari ini adalah untuk membantu menjaga unit test suite berjalan cepat dan terbaru, tetapi tujuan yang lebih penting, dalam pikiran saya, adalah untuk memberi orang tekanan rendah cara untuk mampir, bertanya, dan berlatih menguji . Fakta bahwa Anda bersedia menghabiskan satu jam atau apa pun per minggu secara eksklusif pada tes juga mengirimkan pesan bahwa ini penting.

Saya pikir Anda mendapatkan sedikit perubahan budaya dengan cara ini dan Anda mulai menghilangkan penghalang untuk melakukannya secara "refleks", seperti yang Anda katakan. Orang-orang akan cenderung untuk kembali ke kebiasaan lama pada tanda pertama dari kesulitan - mengadakan pertemuan seperti ini tidak akan memperbaiki itu dalam satu gerakan, tapi saya pikir itu akan memulai perubahan budaya dan menghilangkan penghalang yang dihasilkan dari tidak benar-benar mengetahui apa yang Anda lakukan.

Untuk memiliki sekelompok programmer di mana semua ingin melakukan sesuatu adalah utopia (terutama ketika berbicara tentang kelompok besar).

Pengujian unit dan integrasi adalah standar . Anda membuat standar untuk alur kerja dan setiap anggota tim harus menghargainya. Standar harus dibuat dengan bantuan para profesional QA, karena mereka tahu lebih baik. Seorang programmer harus menghormati standar. Yang bisa Anda lakukan adalah membuat standar bersih, mudah dimengerti dan diikuti.

Ini bukan tentang kepercayaan pada kode Anda sendiri dan keinginan untuk menggunakan, ini adalah tentang perlu memiliki standar pengkodean dan pengujian yang semua orang gunakan untuk membuat hal-hal yang baik, dan setiap programmer harus memahami ini.

Ketika Anda membuat orang dari awal mengikuti standar, itu menjadi refleks dan itu akan diikuti. Membuat aturan bahwa tidak ada kode yang dapat dimasukkan ke dalam basis kode tanpa uji unit akan meyakinkan orang bahwa mereka harus melakukannya. Untuk repositori proyek bahkan ada aturan yang lebih ketat. Sebagai contoh, perusahaan membuat tes unit sebelum benar-benar mengkode unit (ketika mereka membuat spesifikasi modul) dan ini adalah metode yang sangat bagus. Jika seorang programmer menempatkan kode dalam proyek / basis kode kode dijalankan melalui modul tes dan jika tes unit tidak lulus, mereka kembali bekerja.

Jika saat ini sulit untuk menambahkan standar dan aturan, setidaknya pikirkan untuk menambahkannya dalam proyek mendatang.