Bagaimana menjadi lebih baik dalam menguji kode Anda sendiri

Saya adalah pengembang perangkat lunak yang relatif baru, dan salah satu hal yang saya pikir harus saya tingkatkan adalah kemampuan saya untuk menguji kode saya sendiri. Setiap kali saya mengembangkan fungsionalitas baru, saya merasa sangat sulit untuk mengikuti semua jalur yang memungkinkan sehingga saya dapat menemukan bug. Saya cenderung mengikuti jalan di mana semuanya bekerja. Saya tahu ini adalah masalah terkenal yang dimiliki programmer, tetapi kami tidak memiliki penguji di perusahaan saya saat ini dan kolega saya tampaknya cukup pandai dalam hal ini.

Di organisasi saya, kami tidak melakukan pengembangan berbasis pengujian atau pengujian unit. Itu akan banyak membantu saya tetapi tidak mungkin ini akan berubah.

Menurut kalian apa yang bisa saya lakukan untuk mengatasi ini? Pendekatan apa yang Anda gunakan saat menguji kode Anda sendiri?

Tugas seorang pembuat kode adalah membangun sesuatu.

Tugas seorang penguji adalah memecahkan banyak hal.

Yang paling sulit adalah menghancurkan barang yang baru saja Anda bangun. Anda akan berhasil hanya dengan melewati penghalang psikologis ini.

Franciso, saya akan membuat beberapa asumsi di sini, berdasarkan apa yang Anda katakan:

"Kami tidak melakukan TDD atau pengujian unit. Ini akan banyak membantu saya, tetapi tidak mungkin ini akan berubah."

Dari sini, saya menduga tim Anda tidak memberikan banyak nilai pada pengujian atau manajemen tidak akan menganggarkan waktu bagi tim untuk mencoba dan merapikan kode yang ada dan menjaga utang teknis seminimal mungkin.

Pertama, Anda perlu meyakinkan tim / manajemen Anda nilai pengujian. Bersikaplah diplomatis. Jika manajemen membuat tim Anda bergerak maju, Anda perlu menunjukkan kepada mereka beberapa fakta, seperti tingkat cacat untuk setiap rilis. Menghabiskan waktu memperbaiki kerusakan bisa lebih baik dihabiskan untuk hal-hal lain, seperti meningkatkan aplikasi dan membuatnya lebih adaptif dengan persyaratan di masa depan.

Jika tim dan manajemen secara umum apatis memperbaiki kode dan Anda merasa tidak bahagia tentangnya, Anda mungkin perlu mencari tempat lain untuk bekerja, kecuali jika Anda bisa meyakinkan mereka seperti yang saya katakan. Saya mengalami masalah ini pada tingkat yang berbeda di semua tempat saya bekerja. Itu bisa berupa apa saja dari kurangnya model domain yang tepat, hingga komunikasi yang buruk dalam tim.

Peduli terhadap kode Anda dan kualitas produk yang Anda kembangkan adalah atribut yang baik dan yang Anda selalu ingin dorong orang lain.

Jika Anda kode dalam C, Objective-C atau C ++ Anda dapat menggunakan CLang Static Analyzer untuk mengkritik sumber Anda tanpa benar-benar menjalankannya.

Ada beberapa alat debugging memori yang tersedia: ValGrind, Guard Malloc pada Mac OS X, Electric Fence pada * NIX.

Beberapa lingkungan pengembangan menyediakan opsi untuk menggunakan pengalokasi memori debug, yang melakukan hal-hal seperti mengisi halaman yang baru dialokasikan dan halaman yang baru dibebaskan dengan sampah, mendeteksi pembebasan pointer yang tidak terisi, dan menulis beberapa data sebelum dan setelah setiap heap block, dengan debugger menjadi disebut jika pola diketahui dari data itu pernah berubah.

Beberapa pria di Slashdot mengatakan dia mendapatkan banyak nilai dari satu baris sumber baru dalam debugger. "Itu dia," katanya. Saya tidak selalu mengikuti sarannya, tetapi ketika saya memilikinya sangat membantu saya. Bahkan jika Anda tidak memiliki test case yang merangsang jalur kode yang tidak umum, Anda dapat mengubah variabel dalam debugger Anda untuk mengambil jalur tersebut, katakan dengan mengalokasikan sebagian memori, kemudian menggunakan debugger untuk mengatur pointer baru Anda ke NULL alih-alih alamat memori, kemudian melangkah melalui penangan kegagalan alokasi.

Gunakan pernyataan - makro pernyataan () di C, C ++ dan Objective-C. Jika bahasa Anda tidak memberikan fungsi yang tegas, tulis sendiri.

Gunakan penegasan secara bebas, lalu simpan di kode Anda. Saya sebut menegaskan () "Tes yang terus menguji". Saya menggunakannya paling umum untuk memeriksa prasyarat pada titik masuk sebagian besar fungsi saya. Itu salah satu bagian dari "Programming by Contract", yang dibangun ke dalam bahasa pemrograman Eiffel. Bagian lainnya adalah postconditions, yaitu, menggunakan assert () pada function return points, tetapi saya menemukan bahwa saya tidak mendapatkan jarak tempuh sebanyak itu sebagai prasyarat.

Anda juga dapat menggunakan penegasan untuk memeriksa invarian kelas. Meskipun tidak ada kelas yang benar-benar diperlukan untuk memiliki invarian, kelas yang dirancang paling masuk akal memang memilikinya. Kelas invarian adalah suatu kondisi yang selalu benar selain di dalam fungsi anggota yang mungkin sementara menempatkan objek Anda ke keadaan tidak konsisten. Fungsi tersebut harus selalu mengembalikan konsistensi sebelum kembali.

Dengan demikian setiap fungsi anggota dapat memeriksa invarian saat masuk dan keluar, dan kelas dapat mendefinisikan fungsi yang disebut CheckInvariant yang dapat dipanggil kode lain kapan saja.

Gunakan alat cakupan kode untuk memeriksa baris mana dari sumber Anda yang benar-benar diuji, kemudian rancang tes yang merangsang jalur yang tidak diuji. Misalnya Anda dapat memeriksa penangan memori rendah dengan menjalankan aplikasi Anda di dalam VM yang dikonfigurasi dengan sedikit memori fisik, dan tidak ada file swap atau yang sangat kecil.

(Untuk beberapa alasan saya tidak pernah tahu soal rahasia, sementara BeOS dapat berjalan tanpa file swap, itu sangat tidak stabil seperti itu. Dominic Giampaolo, yang menulis sistem file BFS, mendesak saya untuk tidak menjalankan BeOS tanpa swap. Saya tidak lihat mengapa itu penting, tetapi itu pasti semacam artefak implementasi.)

Anda juga harus menguji respons kode Anda terhadap kesalahan I / O. Cobalah menyimpan semua file Anda di jaringan yang dibagi, kemudian lepaskan kabel jaringan Anda saat aplikasi Anda memiliki beban kerja yang tinggi. Demikian pula, lepaskan kabel - atau matikan nirkabel Anda - jika Anda berkomunikasi melalui jaringan.

Satu hal yang menurut saya sangat menyebalkan adalah situs web yang tidak memiliki kode Javascript yang kuat. Halaman Facebook memuat lusinan file Javascript kecil, tetapi jika salah satu di antaranya gagal diunduh, seluruh halaman akan rusak. Harus ada beberapa cara baik untuk memberikan toleransi kesalahan, katakanlah dengan mencoba kembali unduhan, atau untuk memberikan semacam fallback yang masuk akal ketika beberapa skrip Anda tidak mengunduh.

Coba bunuh aplikasi Anda dengan debugger atau dengan "kill -9" di * NIX saat itu tepat di tengah penulisan file yang besar dan penting. Jika aplikasi Anda dirancang dengan baik, seluruh file akan ditulis atau tidak akan ditulis sama sekali, atau mungkin jika hanya ditulis sebagian, apa yang ditulis tidak akan rusak, dengan data apa yang disimpan dapat sepenuhnya digunakan oleh aplikasi setelah membaca kembali file.

database selalu memiliki I / O disk yang toleran terhadap kesalahan, tetapi hampir tidak ada jenis aplikasi lain yang melakukannya. Sementara filesystem journal mencegah kerusakan filesystem jika terjadi kegagalan daya atau crash, mereka tidak melakukan apa-apa untuk mencegah korupsi atau hilangnya data pengguna akhir. Itu adalah tanggung jawab aplikasi pengguna, tetapi hampir tidak ada yang lain selain database yang menerapkan toleransi kesalahan.

Ketika saya melihat pengujian kode saya, saya biasanya melalui serangkaian proses pemikiran:

1. Bagaimana cara memecah "benda" ini menjadi potongan ukuran yang dapat diuji? Bagaimana saya bisa mengisolasi apa yang ingin saya uji? Rintisan apa yang harus saya buat?
2. Untuk setiap chunk: Bagaimana cara menguji chunk ini untuk memastikan bahwa ia merespons dengan benar terhadap serangkaian input yang benar?
3. Untuk setiap chunk: Bagaimana saya menguji bahwa chunk merespon dengan benar terhadap input yang salah (NULL pointer, nilai tidak valid)?
4. Bagaimana cara menguji batas (misalnya, di mana nilai beralih dari yang ditandatangani menjadi yang tidak ditandatangani, 8 bit menjadi 16 bit, dll.)?
5. Seberapa baik pengujian saya mencakup kode? Apakah ada kondisi yang saya lewatkan? [Ini adalah tempat yang bagus untuk alat cakupan kode.] Jika ada kode yang terlewat dan tidak pernah dapat dieksekusi, apakah itu benar-benar perlu ada di sana? [Itu pertanyaan lain!]

Cara termudah yang saya temukan untuk melakukan ini adalah mengembangkan tes saya bersama dengan kode saya. Begitu saya telah menulis bahkan sepotong kode, saya suka menulis tes untuk itu. Mencoba melakukan semua pengujian setelah kode beberapa ribu baris kode dengan kompleksitas kode siklomatik non-sepele adalah mimpi buruk. Menambahkan satu atau dua tes lagi setelah menambahkan beberapa baris kode sangat mudah.

BTW, hanya karena perusahaan tempat Anda bekerja dan / atau kolega Anda tidak melakukan Pengujian Unit atau TDD, tidak berarti Anda tidak dapat mencobanya, kecuali jika mereka secara khusus dilarang. Mungkin menggunakannya untuk membuat kode yang kuat akan menjadi contoh yang baik untuk orang lain.

Selain saran yang diberikan dalam jawaban lain, saya sarankan menggunakan alat analisis statis (Wikipedia memiliki daftar sejumlah alat analisis statis untuk berbagai bahasa ) untuk menemukan cacat potensial sebelum pengujian dimulai serta memantau beberapa metrik yang berkaitan dengan testabilitas kode, seperti kompleksitas siklomatik , ukuran kompleksitas Halstead , dan kohesi dan penggandengan (Anda dapat mengukurnya dengan fan-in dan fan-out).

Menemukan sulit untuk menguji kode dan membuatnya lebih mudah untuk menguji akan, membuat Anda lebih mudah untuk menulis kasus uji. Selain itu, menangkap cacat sejak dini akan menambah nilai bagi seluruh praktik jaminan kualitas Anda (yang mencakup pengujian). Dari sini, membiasakan diri dengan alat pengujian unit dan alat mengejek akan membuatnya lebih mudah bagi Anda untuk mengimplementasikan pengujian Anda.

Anda bisa melihat kemungkinan penggunaan Tabel Kebenaran untuk membantu Anda menentukan semua jalur potensial dalam kode Anda. Tidak mungkin untuk memperhitungkan semua kemungkinan dalam fungsi yang kompleks, tetapi begitu Anda memiliki penanganan yang ditetapkan untuk semua jalur yang dikenal, Anda dapat membuat penanganan untuk kasus lainnya.

Sebagian besar dari kemampuan khusus ini dipelajari melalui pengalaman. Setelah Anda menggunakan kerangka kerja tertentu untuk waktu yang signifikan, Anda mulai melihat pola dan ciri perilaku yang akan memungkinkan Anda melihat sepotong kode dan melihat di mana perubahan kecil dapat menyebabkan kesalahan besar. Satu-satunya cara saya dapat memikirkan untuk meningkatkan bakat Anda dalam hal ini adalah latihan.

Jika seperti yang Anda katakan Anda tidak perlu pengujian Unit, saya tidak melihat pendekatan yang lebih baik daripada mencoba untuk memecahkan kode Anda secara manual.

Cobalah untuk mendorong kode Anda ke batas . Misalnya mencoba untuk mengirimkan variabel ke fungsi yang melebihi batas batas. Apakah Anda memiliki fungsi yang seharusnya memfilter input pengguna? Coba masukkan kombinasi karakter yang berbeda.

Pertimbangkan sudut pandang pengguna . Cobalah menjadi salah satu pengguna yang akan menggunakan aplikasi atau pustaka fungsi Anda.

tetapi kami tidak memiliki penguji di perusahaan saya saat ini dan kolega saya tampaknya cukup pandai dalam hal ini

Kolega Anda harus benar-benar luar biasa untuk tidak mengikuti TDD atau pengujian unit dan tidak pernah menghasilkan bug sehingga pada tingkat tertentu saya ragu bahwa mereka tidak melakukan pengujian unit apa pun sendiri.

Saya menduga bahwa kolega Anda melakukan lebih banyak pengujian daripada membiarkannya, tetapi karena fakta ini tidak diketahui oleh manajemen maka organisasi menderita sebagai akibat karena manajemen mendapat kesan bahwa pengujian yang sebenarnya tidak dilakukan dan jumlah bug rendah sehingga pengujian tidak penting dan waktu tidak akan dijadwalkan untuk itu.

Bicaralah dengan kolega Anda dan cobalah untuk mencari tahu jenis pengujian unit apa yang mereka lakukan dan meniru itu. Di lain waktu, Anda dapat membuat prototipe cara yang lebih baik untuk menguji unit dan atribut TDD dan perlahan-lahan memperkenalkan konsep-konsep ini kepada tim untuk adopsi yang lebih mudah.

• Tulis tes Anda sebelum Anda menulis kode Anda.
• Setiap kali Anda memperbaiki bug yang tidak tertangkap oleh tes, tulis tes untuk menangkap bug itu.

Anda harus bisa mendapatkan liputan tentang apa yang Anda tulis bahkan jika organisasi Anda tidak memiliki liputan penuh. Seperti banyak hal dalam pemrograman, pengalaman melakukannya berulang-ulang merupakan salah satu cara terbaik untuk menjadi efisien dalam hal itu.

Selain semua komentar lain, karena Anda mengatakan kolega Anda pandai menulis tes tidak bahagia, mengapa tidak meminta mereka untuk berpasangan dengan Anda dalam menulis beberapa tes.

Cara terbaik untuk belajar adalah melihat bagaimana hal itu dilakukan dan menarik apa yang Anda pelajari dari itu.

Pengujian kotak hitam! Anda harus membuat kelas / metode Anda dengan pengujian dalam pikiran. Tes Anda harus didasarkan pada spesifikasi perangkat lunak dan harus didefinisikan dengan jelas pada diagram Urutan Anda (melalui kasus penggunaan).

Sekarang karena Anda mungkin tidak ingin melakukan pengembangan berbasis tes ...

Masukkan validasi input pada semua data yang masuk; jangan percaya siapapun. Kerangka kerja .net memiliki banyak pengecualian berdasarkan argumen yang tidak valid, referensi nol dan status tidak valid. Anda seharusnya sudah berpikir untuk menggunakan validasi input pada lapisan UI sehingga trik yang sama di perangkat tengah.

Tetapi Anda harus benar-benar melakukan semacam pengujian otomatis; hal-hal itu menyelamatkan nyawa.

Dalam pengalaman saya

Unit uji, jika tidak sepenuhnya otomatis, itu tidak berguna. Ini lebih seperti bos berambut runcing bisa membeli. Mengapa ?, karena Unit Tes menjanjikan Anda untuk menghemat waktu (dan uang) mengotomatisasi beberapa proses pengujian. Tetapi, beberapa alat unit tes melakukan yang sebaliknya, itu memaksa programmer untuk bekerja dengan cara yang aneh dan memaksa yang lain untuk membuat tes yang diperluas. Sebagian besar waktu, itu tidak akan menghemat jam kerja tetapi meningkatkan waktu perpindahan dari QA ke pengembang.

UML adalah pembuang waktu lain. satu papan tulis + pena bisa melakukan hal yang sama, lebih murah dan cepat.

BTW, Bagaimana menjadi pandai dalam pengkodean (dan menghindari bug)?

• a) atomitas. Satu fungsi yang melakukan satu tugas sederhana (atau beberapa tugas tunggal). Karena mudah dimengerti, mudah dilacak dan mudah diselesaikan.

• b) Homologi. Jika, misalnya, Anda memanggil database menggunakan prosedur store kemudian lakukan untuk sisa kode.

• c) Identifikasi, kurangi, dan isolasi "kode kreatif". Sebagian besar kode cukup banyak copy & paste. Kode kreatif adalah kebalikannya, kode yang baru dan bertindak sebagai prototipe, bisa gagal. Kode ini rentan terhadap bug logika, jadi penting untuk mengurangi, mengisolasi, dan mengidentifikasinya.

• d) "Thin ice" kode, adalah kode yang Anda tahu itu "salah" (atau berpotensi berbahaya) tetapi masih perlu, misalnya kode tidak aman untuk proses multi-tugas. Hindari jika Anda bisa.

• e) Hindari kode kotak hitam, ini termasuk kode yang tidak dilakukan oleh Anda (misalnya kerangka kerja) dan ekspresi reguler. Sangat mudah untuk melewatkan bug dengan kode semacam ini. Sebagai contoh, saya bekerja dalam proyek menggunakan Jboss dan saya menemukan bukan hanya satu tapi 10 kesalahan di Jboss (menggunakan versi stabil terbaru), itu adalah PITA untuk menemukan mereka. Hindari Hibernate khusus, itu menyembunyikan implementasi, maka bug.

• f) tambahkan komentar dalam kode Anda.

• g) input pengguna sebagai sumber bug. kenali itu. Misalnya, SQL Injection disebabkan oleh input pengguna.

• h) Identifikasi elemen buruk tim dan pisahkan tugas yang diberikan. Beberapa programmer cenderung mengacaukan kode.

• i) Hindari kode yang tidak perlu. Jika, misalnya, kelas membutuhkan Antarmuka kemudian menggunakannya, jika tidak hindari untuk menambahkan kode yang tidak relevan.

a) dan b) adalah kuncinya. Misalnya, saya punya masalah dengan sistem, ketika saya mengklik tombol (simpan) itu tidak menyimpan formulir. Kemudian saya membuat daftar periksa:

• tombolnya berfungsi? ... ya.
• database menyimpan sesuatu? tidak, jadi kesalahannya ada di langkah tengah.
• lalu, kelas yang menyimpan dalam pekerjaan database ?. tidak <- ok, saya menemukan kesalahan. (itu terkait dengan izin basis data). Kemudian saya memeriksa tidak hanya prosedur ini tetapi setiap prosedur yang melakukan hal yang sama (karena homologi kodenya). Butuh 5 menit untuk melacak bug dan 1 menit untuk menyelesaikannya (dan banyak bug lainnya).

Dan sidenote

Sebagian besar waktu QA menghisap (sebagai bagian terpisah dari Dev), tidak ada gunanya jika mereka tidak bekerja dalam proyek. Mereka melakukan beberapa tes generik dan tidak banyak. Mereka tidak dapat mengidentifikasi sebagian besar bug logika. Dalam kasus saya, saya bekerja di bank bergengsi, seorang programmer menyelesaikan kode kemudian mengirimkannya ke QA. QA menyetujui kode dan dimasukkan ke dalam produksi ... kemudian kode gagal (epik gagal), apakah Anda tahu siapa yang disalahkan ?. ya, programmer.

Penguji dan pemrogram menghadapi masalah dari sudut yang berbeda, tetapi kedua peran harus sepenuhnya menguji fungsionalitas dan menemukan bug. Di mana peran berbeda dalam fokus. Penguji klasik melihat aplikasi hanya dari luar (yaitu kotak hitam). Mereka ahli dalam persyaratan fungsional aplikasi. Seorang programmer diharapkan menjadi ahli dalam persyaratan fungsional dan kode (tetapi cenderung lebih fokus pada kode).

(Tergantung pada organisasi apakah programmer secara eksplisit diharapkan untuk menjadi ahli dalam persyaratan. Apapun, harapan implisit ada - jika Anda merancang sesuatu yang salah, Anda - bukan persyaratan orang - menerima kesalahan.)

Peran ahli ganda ini membebani pikiran programmer dan, kecuali yang paling berpengalaman, dapat mengurangi kemahiran dalam persyaratan. Saya menemukan bahwa saya harus secara mental menggeser persneling untuk mempertimbangkan pengguna aplikasi. Inilah yang membantu saya:

1. Debugging ; atur breakpoint dalam kode dan jalankan aplikasi. Setelah Anda mencapai breakpoint, melangkah melalui garis saat Anda berinteraksi dengan aplikasi.
2. Pengujian otomatis ; tulis kode yang menguji kode Anda. Ini hanya membantu pada tingkatan di bawah UI.
3. Kenali penguji Anda ; mereka mungkin tahu aplikasi lebih baik daripada Anda, jadi belajarlah dari mereka. Tanyakan kepada mereka apa kelemahan aplikasi Anda, dan taktik apa yang mereka gunakan untuk menemukan bug.
4. Kenali pengguna Anda ; belajar berjalan di posisi pengguna Anda. Persyaratan fungsional adalah sidik jari pengguna Anda. Sering ada banyak hal yang diketahui pengguna Anda tentang aplikasi yang mungkin tidak jelas dalam persyaratan fungsional. Ketika Anda memahami pengguna Anda dengan lebih baik - sifat pekerjaan mereka di dunia nyata dan bagaimana aplikasi Anda seharusnya membantu mereka - Anda akan lebih memahami apa yang seharusnya menjadi aplikasi tersebut.

Saya pikir Anda ingin bekerja di dua bidang. Pertama adalah politis, membuat organisasi Anda untuk mengadopsi pengujian pada tingkat tertentu (dengan harapan bahwa seiring waktu mereka akan mengadopsi lebih banyak). Bicaralah dengan teknisi QA di luar tempat kerja Anda. Temukan daftar buku-buku QA . Lihat-lihat artikel wikipedia yang relevan . Biasakan diri Anda dengan prinsip dan praktik QA. Mempelajari hal ini akan mempersiapkan Anda untuk membuat kasus yang paling meyakinkan yang Anda bisa dalam organisasi Anda. Departemen QA yang baik memang ada dan mereka memberi nilai tambah yang cukup besar bagi organisasi mereka.

Sebagai pengembang individu, adopsi strategi untuk digunakan dalam pekerjaan Anda sendiri. Gunakan TDD sendiri dengan mengembangkan kode dan tes bersama. Jaga tes tetap jelas dan terawat dengan baik. Jika ditanya mengapa Anda melakukan ini, Anda dapat mengatakan Anda mencegah regresi dan itu membuat proses berpikir Anda lebih terorganisir (keduanya akan benar). Ada seni untuk menulis kode yang dapat diuji , mempelajarinya. Jadilah contoh yang baik untuk sesama pengembang Anda.

Sebagian saya berkhotbah kepada diri saya sendiri di sini, karena saya melakukan hal ini jauh lebih sedikit daripada yang saya tahu harus saya lakukan.