Kata pengantar
Pernahkah Anda merasa ada hantu di dunia ketika Anda menyetel sepotong kode tertentu?
Pernahkah Anda mengalami masalah dalam mengatur API, Anda selalu merasa bahwa itu adalah masalah dalam memanggil antarmuka pihak ketiga atau dokumentasi tidak benar?
Pernahkah Anda merasa bahwa sumber masalahnya adalah cara yang salah untuk menggunakannya?
Apakah Anda selalu merasa bahwa dokumentasi atau lingkungan tidak cocok saat memasang layanan?
Percaya pada proses dan metode dan tidak pernah disesatkan oleh hasilnya .........
Ringkasan
Kode modular sering mirip dengan penyelidikan suatu kasus, tetapi pentingnya hasilnya berbeda. Polisi menyelidiki kasus agar orang -orang aman, sedangkan kode modular kami adalah untuk stabilitas sistem. Dengan cara ini, kita seharusnya tidak secara keliru menuduh sepotong kode dan program, agar tidak dihukum secara tidak masuk akal.
Metode proses berikut berasal dari ringkasan pribadi. Dari perspektif pribadi, beberapa metode generasi sebelumnya telah diakumulasikan melalui pengalaman jangka panjang, dan tentu saja mereka sangat dirujuk dan teoretis. Sebagai metode pribadi, mereka mungkin lebih cocok untuk DS seperti kita.
Metode pengujian
Mode Prosedural Kode
Hal pertama yang harus diperhatikan saat mode pengkodean adalah prosesnya. Anda harus mengklarifikasi gagasan hasil akhir, yaitu proses melakukan kejahatan, dan menindaklanjuti langkah demi langkah dalam proses kejahatan untuk mendapatkan hasil kejahatan. Selama analisis proses kejahatan, setiap keraguan harus ditandai (yaitu, informasi log yang disebutkan dalam kode). Setelah proses analisis seperti itu, uji kotak hitam dilakukan, input ditambahkan, dan hasilnya diverifikasi. Akhirnya, verifikasi penilaian Anda berdasarkan tanda dari setiap langkah untuk menemukan alasannya.
Solusi di atas adalah mode prosedural. Keuntungan dari metode ini terbukti dengan sendirinya. Anda dapat secara langsung menganalisis seluruh proses melalui tes, tetapi metode ini memakan waktu dan tidak apa-apa untuk mengklarifikasi logika kode Anda sendiri, tetapi sulit untuk memahami kode logika orang lain.
Mode Uji Unit
Tujuan dasar pengujian unit adalah untuk memastikan operasi normal dari fungsi, kelas atau modul fungsional, termasuk pengujian dan verifikasi situasi abnormal. Sebagai pemrogram, metode verifikasi paling favorit adalah "menumpuk" (arti mengemudi tiang adalah untuk menyediakan data default palsu). Metode ini sangat nyaman untuk disesuaikan, tetapi satu kerugian adalah bahwa ia tidak dapat digunakan lagi, karena setelah verifikasi kami normal, banyak pengembang akan berkomentar atau menghapusnya. Oleh karena itu, jika kami menyelesaikan pengembangan di lingkungan pengembangan, tetapi kami berharap bahwa ketika menguji verifikasi lingkungan, kami harus menulis ulang logika mengemudi tumpukan lainnya. Lalu, dengan cara ini, akan lebih merepotkan ketika kita berada di internet. Karena ada begitu banyak ketidaknyamanan, Anda dapat mencoba metode berikut.
Tambahkan kelas tes unit. Kelas ini perlu mengontrol izinnya dan hanya dapat dieksekusi melalui login latar belakang atau baris perintah. Fungsi kelas ini adalah untuk mendeteksi logika kunci dari sistem dan membuat hasil output uji yang sesuai. Anda harus percaya bahwa semua kelas antarmuka dapat diuji melalui kelas tes unit. Sering kali pemrogram mempertanyakan apakah kita harus melakukan ini? Bahkan, kita benar -benar perlu melakukannya. Bagaimanapun, banyak tes sekarang dilakukan dalam tes kotak hitam.
Metode modular ini cocok selama proses pengembangan dan dapat memastikan bahwa kode jaringan kami saat ini berjalan secara normal setelah dirilis. Saya berharap semua orang juga akan mentransfer proses ini ke tahap pengembangan ketika merencanakan waktu pengembangan.
Metode penentuan posisi cepat
Apakah dua proses yang pertama sangat rumit terlalu ideal? Kode saya hanya 100 baris, dan sistemnya tidak rumit. Jika ini masalahnya, maka lakukan analisis penentuan posisi dengan cepat. Berkali -kali saya bertemu
1. Input normal, outputnya tidak normal;
2. Input normal, logikanya abnormal, dan outputnya tidak normal;
3. Inputnya abnormal, logikanya normal, dan outputnya normal;
4. Pengecualian input, pengecualian logika, output tidak ada.
Selama proses pengembangan pribadi saya, saya sering menemukan beberapa jenis masalah di atas. Misalnya, selama proses pengembangan Node.js, saya menemukan string.length dan mengatakan bahwa tidak ada metode panjang untuk string. Pada saat itu, saya bingung dan bertanya pada diri sendiri mengapa string lain memiliki metode panjang, dan mengapa tidak ada metode seperti itu? Banyak siswa mungkin tahu bahwa masalahnya adalah bahwa string ini sama sekali bukan string, tetapi hanya bahwa Anda telah mengidealkannya sebagai string sendiri, yang berarti bahwa ada masalah dengan apa yang Anda masukkan. Maka cara terbaik untuk menemukan masalah ini adalah dengan mencetak input dan mencetak output.
Mungkin program lain tidak sesederhana itu, tetapi yang paling mendasar adalah membuat penilaian input dan output pada fungsi yang menghadapi pengecualian dalam fungsi utama, sehingga mereka dapat dengan cepat menemukan.
Ingat: Jangan mengambilnya di luar konteks dan menjadi benar sendiri.
Metode dan prosedur di atas hanya dirangkum berdasarkan PHP atau Node.js. Mungkin ada persamaan atau perbedaan dalam C&C ++. Jika Anda tidak menyukainya, harap hargai.