Dalam kehidupan setiap pengembang, momen datang ketika ia berpikir tentang membuat komponen uji untuk gagasannya. Saya akan menjadi lebih baik - dalam kehidupan setiap pengembang yang baik. Ketika Anda seorang junior dan tidak memikul tanggung jawab khusus, Anda memiliki hak untuk banyak kesalahan dan Anda dapat memperbaikinya kapan saja. Anda tidak bertanggung jawab atas produk yang Anda buat dan tidak memiliki motivasi untuk menghabiskan waktu ekstra untuk memeriksa ulang kode yang dihasilkan. “Tidak ada, kusen ini tidak dapat direproduksi”, “benda ini tampaknya berfungsi”, “well, setidaknya, ia melakukan apa yang diperlukan” - jika Anda ingin melampaui tingkat pembibitan programmer, Anda harus meniadakan masing-masing pemikiran ini.
Dengan pengembangan pengalaman pemrograman Anda sendiri, Anda memiliki klien baru yang lebih banyak dan lebih keren. Anda bahkan akan senang dengan beberapa (dari semua, jika Anda beruntung) - orang baik dan membayar dengan murah hati dan tidak pilih-pilih tentang masalah yang muncul. Mari kita lihat satu kasus sederhana (sangat sederhana, tetapi hal utama yang ada di baliknya) membuat form handler dari seorang programmer yang tidak tahu kerumitannya.
Jadi, tugas sederhana telah tiba - untuk menulis form handler. Tujuannya adalah untuk menerima aplikasi dari pelanggan untuk pembelian batu bata. Pelanggan itu besar, ia terlibat dalam pengiriman besar batu bata dalam jumlah besar (misalnya, dengan jumlah lebih dari 500.000 rubel - untuk merasakan setidaknya beberapa tingkat tanggung jawab atas apa yang terjadi). Persaingan sangat ketat - pelanggan dapat dengan cepat pergi ke pemasok batu bata jika mereka tidak merespons dalam sehari.
Programmer kami diberitahu bahwa perlu untuk menyimpan data klien dari formulir - nama perwakilan, nomor telepon, nama perusahaan klien, volume pesanan, dan bidang deskripsi pesanan opsional. Otak Porakinin, bentuk sederhana dengan cepat dibuat dengan bidang standar untuk bagian depan situs:
Data dari formulir dikirim oleh permintaan AJAX, tanpa memuat ulang halaman. Lebih lanjut, programmer mengambil desain form handler dan dia perlu mengatasi tugas yang agak sepele - menambahkan entri untuk klien baru ke tabel pesanan yang sudah ada dan mengirim email kepada pelanggan dengan pemberitahuan tentang klien baru.
Formulir berfungsi, data berhasil disimpan, pelanggan puas. Tetapi tiba-tiba sebuah panggilan marah datang dari pelanggan, “jadi mereka mengatakan, pesanan telah tiba - perusahaan jutawan ingin membeli semua batu bata dari saya, tetapi nomor telepon belum datang dari formulir dan bagaimana saya bisa menghubungi mereka sekarang?! Besok mereka akan menemukan pemasok lain! Bagaimana Anda melakukannya?! Ini salahmu ... " Pelanggan menangis dan melempar, tanpa rasa takut, tanpa kepercayaan dan rasa hormat. Situasi ini sangat standar untuk junior - tidak adanya validasi dan pengujian data yang masuk dari formulir. Tugas pertama (validasi) diselesaikan dengan sangat sederhana dengan menambahkan aturan validasi:
Untuk selanjutnya, klien situs hanya akan menunjukkan data yang benar yang kami butuhkan untuk diproses lebih lanjut. Pada tahap yang sama, pengembang memiliki ide untuk menguji kode untuk menghindari situasi yang canggung. Misalnya, menguji bidang nama keluarga akan terlihat seperti ini (untuk menyederhanakan contoh dasar, perlindungan csrf dinonaktifkan):
Kami tahu bahwa jika tidak ada bidang ini, kode harus mengembalikan jawaban dengan kesalahan dan status 400 terdaftar oleh kami. Metode pengujian seperti itu ditentukan untuk setiap situasi tertentu (atau validasi bidang tertentu, semuanya tergantung pada tugas dan imajinasi pengembang).
Tetapi apakah ada metode pengembangan yang berbeda dari "Saya lakukan, tapi sekarang saya akan periksa"? Kami pertama-tama menulis kode, menemukan tiang-tiang eksekusi, memperbaikinya, dan kemudian mengingat tentang tes. Pendekatan ini bisa menyamping bagi kami dan pelanggan kami, mengingat klien multi-juta yang hilang (meskipun secara teoritis, semua klien tersebut akan menjadi). Dan kemudian saya bertanya-tanya - bagaimana jika kita memulai logika menciptakan aplikasi dari ujung yang berlawanan - pertama kita akan membuat tuntutan pada "pelaksana", dan kemudian kita akan membuatnya memenuhi persyaratan ini? Ayo kita coba.
Kami meninggalkan tugas seperti sebelumnya, kami hanya mengubah pendekatan untuk itu. Kita perlu menulis form handler dengan bidang fio, telepon, corp, quant dan konten. Hasil eksekusi yang sukses adalah status 200, menambahkan bidang ke Pesan dengan pesan "ok" dan mengembalikan data pada catatan yang dimasukkan, opsi lain - status 400 dan daftar kesalahan.
Pertama-tama, kita perlu menulis metode pengujian untuk mengisi data formulir secara valid:
Selanjutnya, buat rute dan metode pengontrol yang diperlukan (saat kosong). Jika kita menjalankan tes sekarang, maka diharapkan mendapatkan kesalahan. Memvalidasi data yang valid tidak semua yang kita butuhkan. Sekarang kita mulai menguji validasi bidang formulir. Kami menentukan bidang mana yang diperlukan - fio, telepon, corp, quant dan menambahkan metode untuk verifikasi (komentar opsional):
Form handler hanya perlu memeriksa untuk data masuk, telepon, corp, quant. Karena kami menghapus semua bidang yang diperlukan dari permintaan, kesalahan dalam kesalahan harus dikembalikan untuk masing-masing. Dalam hal setidaknya satu dari mereka tidak hadir - masalah eksekusi. Jika diinginkan, Anda dapat menambahkan cek untuk pesan, seperti yang dilakukan sebelumnya (periksa "ok").
Kami mengeluarkan cek untuk panjang minimum bidang fio, telepon, dan corp (pemeriksaan serupa akan dilakukan untuk panjang maksimum dan untuk karakter yang tidak valid di bidang ini).
Cek kami sudah ada, Anda dapat menjalankan dan memeriksa
Sempurna Aplikasi kami jatuh dalam 5 dari 5 tes. Tujuan kami selanjutnya adalah melalui metode pengujian yang menetapkan nilai tidak valid ke bidang dan membentuk aturan validasi untuk data yang masuk. Logikanya kira-kira seperti ini: bidang fio tidak boleh kosong; panjangnya tidak kurang dari 3 dan tidak lebih dari 120; ini adalah string dengan set karakter yang diizinkan dalam nama (huruf, tanda hubung, indentasi). Hasil dari logika ini di semua bidang:
Menanggapi file, daftar kesalahan telah ditambahkan kesalahan yang sesuai dengan setiap bidang "masalah". Ini akan membantu kami memeriksa bidang tertentu untuk validasi (assertJsonStructure dalam file pengujian). Selanjutnya, kami menambahkan metode untuk validasi dan mendapatkan versi final:
Dan akhirnya, kita dapat memeriksa bagaimana skrip kita bekerja dalam pengujian (saya ingat, ada 5 gagal dalam 5 tes).
Seperti yang Anda lihat, semua tes berhasil lulus dan hanya satu entri dimasukkan ke dalam basis data (karena hanya satu metode yang dikonfigurasikan untuk bekerja dengan benar).
Apa temuannya? Pengembangan aplikasi, dimulai dengan tes, adalah pilihan yang lebih baik daripada penulisan fungsionalitas biasa. Kebutuhan untuk menerima dari metode hanya apa yang dibutuhkan sebanding dengan disiplin tentara - kode melakukan apa yang Anda butuhkan, bukan langkah ke samping. Namun, pendekatan ini memiliki sisi negatif (walaupun kontroversial) - faktanya adalah bahwa menulis fungsionalitas tambahan (yang menguji) juga membutuhkan waktu yang dialokasikan untuk pengembangan proyek. Bagi saya, pilihannya jelas - seorang programmer yang baik harus menulis tes, dan memulai dengan fungsionalitas tes membantu untuk menulis proyek yang berfungsi dengan baik dan dapat diandalkan. Saya akan mencoba menggunakannya dalam sesuatu yang kurang sepele.