Dalam pekerjaan saya, saya selalu menggunakan unit test. Bagaimana dengan kamu? Dalam pengalaman saya, kebanyakan programmer sangat jarang. Saat mewawancarai kandidat pekerjaan di tim saya, saya selalu mengajukan pertanyaan: "Apakah Anda memiliki pengalaman pengujian?" Dan yang paling sering saya dengar sebagai respons: "Tidak." Dan jika Anda bertanya mengapa, maka jawaban yang paling umum adalah: "Pelanggan tidak membiarkan saya melakukan ini."

Pendekatan ini mengejutkan saya. Akankah Anda memberi tahu pembuatnya merek beton mana yang akan dipilih untuk membangun rumah? Atau mekanik otomatis - bagian mana dari mesin yang akan diperbaiki, dan yang tidak, jika mesin telah menyala di dalam mobil? Ini tidak mungkin, karena ini adalah masalah teknis yang serius, solusinya harus dipercayakan kepada profesional. Seorang profesional memiliki keterampilan dan alat yang diperlukan yang memungkinkannya untuk menyelesaikan masalah lebih cepat dan lebih murah.

Mengapa menghitung uang?

KUH Perdata memiliki konsep "menyelamatkan kontraktor melalui pengalaman dan pengetahuan". Artinya adalah bahwa pekerjaan dilakukan oleh seorang profesional yang tahu bagaimana mengoptimalkan proses, bagaimana melakukan yang lebih baik, tetapi pada saat yang sama lebih murah. Dan pengembang sebagai profesional harus memberikan solusi terbaik kepada pelanggan dengan sedikit uang.

Tetapi sebenarnya, programmer berfokus pada sesuatu yang lain. Banyak dari mereka yakin bahwa pengembangan perangkat lunak adalah proses teknis murni, yang, tentu saja, memiliki nilai, tetapi tugas programmer adalah menulis, bukan untuk menghitung uang. Namun, menurut pendapat saya, pembangunan terutama merupakan proyek ekonomi, di belakangnya ada uang dan perhitungan, dan hanya setelah itu merupakan tugas teknis.

Logikanya di sini sederhana: bisnis - bagi pelanggan yang memerintahkan kami pengembangan perangkat lunak untuk perusahaan mereka - pada kenyataannya, tidak memerlukan perangkat lunak sama sekali. Bisnis membutuhkan uang, manfaat yang akan diberikan oleh perangkat lunak ini.

Ini berarti bahwa programmer tidak dapat melakukannya tanpa memahami ekonomi pembangunan, mengetahui biaya solusi teknis dan mana dari mereka yang optimal dalam hal tidak hanya teknologi, tetapi juga keuangan.

Pengembangan perangkat lunak pada umumnya bukan bagian termurah dari bisnis, tetapi perangkat lunak berkualitas buruk dapat menyebabkan kerugian besar. Bahkan downtime menyebabkan hilangnya keuntungan, dan masalah perangkat lunak dapat menyebabkan jutaan kerugian. Oleh karena itu, pengembang sebagai profesional harus yakin dengan kualitas produknya dan menjaminnya kepada kliennya. Tetapi kualitas produk adalah indikator yang paling penting. Dan pelanggan harus tahu bahwa kualitas ini dapat diukur dan percaya diri di dalamnya. Dan bagaimana tepatnya tugas programmer.

Saya, seperti banyak kolega saya, percaya bahwa programmer tidak boleh mendiskusikan solusi teknik dengan pelanggan. Cukup umum untuk mengetahui apa yang penting bagi klien, fungsionalitas apa, dan untuk tujuan apa yang dibutuhkan. Keputusan mana yang harus dipilih adalah tanggung jawab programmer. Dan dalam kerangka tanggung jawab ini, ia harus menggunakan praktik rekayasa terbaik untuk proyek tertentu dengan biaya yang dapat dibenarkan secara ekonomi. Oleh karena itu, para profesional yang tahu bagaimana membuat proses pengembangan lebih murah menang.

Tes mana yang lebih menguntungkan

Salah satu praktik yang memungkinkan Anda untuk mengontrol kualitas produk adalah pengujian. Tapi tes mana yang lebih menguntungkan? Untuk menjawab pertanyaan ini, cukup membandingkan beberapa parameter. Semua tes dapat dibagi secara kondisional tidak hanya berdasarkan jenis teknologi, tetapi juga oleh kecepatan, dan yang paling penting - berdasarkan biaya.

Uji unit - pengujian unit produksi. Maksud saya maksud unit unit, tergantung pada bahasa yang diwakili oleh kelas, fungsi, file yang lebih jarang. Menggunakan pendekatan TDD, pengujian awalnya ditenun ke dalam proses pengembangan produk. Suatu proyek dapat menggunakan ribuan tes semacam itu untuk menguji setiap potongan kode. Mereka memiliki indikator kecepatan yang sangat baik - seluruh rangkaian tes dapat diselesaikan dalam hitungan detik. Ini adalah tes termurah.

Tes integrasi - menguji unit 2x-3x atau lebih bersamaan. Mungkin ada ratusan atau ribuan tes seperti itu pada suatu proyek, tergantung pada programmer. Kecepatan - detik atau menit untuk seluruh rangkaian uji. Biaya lebih tinggi daripada unit test.

Tes penerimaan mensimulasikan tindakan pengguna dengan suatu program. Mereka memerlukan persiapan lingkungan operasional, oleh karena itu, mereka kompleks dan mahal. Kuantitas per proyek - biasanya satu tes dilakukan untuk kisah bisnis. Kecepatan kerja biasanya dari puluhan menit hingga beberapa jam untuk seluruh rangkaian tes.

Yang paling mahal dan sulit adalah pengujian manual . Anda perlu merekrut seseorang, melatihnya, membuat dan memberinya peta riwayat bisnis sehingga ia menguji perangkat lunak baru di atasnya. Pengujian semacam itu membutuhkan beberapa hari untuk seluruh rangkaian pengujian.

Segala jenis tes membutuhkan persiapan, serta investasi uang tertentu. Dan untuk mendapatkan penghematan (dan karenanya bermanfaat), pertama-tama kita harus memperhitungkan kecepatan pengujian dan kerumitan peluncurannya. Jika proyek tidak memiliki tes otomatis, maka hanya ada satu jalan keluar - pengujian manual, yang paling mahal dan lambat.

Namun, pendekatan modern untuk pengembangan perangkat lunak adalah siklus berkelanjutan: dalam seminggu fungsionalitas baru atau versi baru dibuat dan diperiksa secara otomatis atau manual. Artinya, produk sering berubah, dan semua perubahan ini harus dikontrol sehingga programmer yakin bahwa fungsi baru dan lama berfungsi dengan baik. Oleh karena itu, pengujian manual segera kehilangan semua indikator.

Adapun berbagai jenis pengujian otomatis, ada tiga aspek penting yang perlu dipertimbangkan.

Pertama-tama, ini reliabilitas - betapa mudahnya untuk mematahkan tes (ini adalah indikator terbaik untuk unit test).

Maka lingkungan yang diperlukan untuk menjalankan tes. Tes unit sangat sederhana, mereka sendiri menciptakan lingkungan di sekitar unit yang diuji. Tes integrasi memerlukan layanan yang harus diinstal, dijalankan, dll. Tes penerimaan memerlukan persiapan, karena aplikasi harus bekerja di lingkungannya.

Dan akhirnya - cakupan (cakupan uji). Tes unit memiliki cakupan yang baik dan digunakan di seluruh proyek. Tes integrasi biasanya digunakan pada bagian-bagian tertentu dari proyek, yaitu, mereka tidak sepenuhnya mencakup program. Cakupan tes penerimaan lebih buruk - ini disebabkan oleh kompleksitas penulisan dan menjalankannya, paling sering mereka mencakup kasus bisnis utama, ini adalah 20-40% dari total volume proyek.

Kesimpulan

Jadi, ternyata unit test memimpin dalam semua indikator analisis komparatif singkat ini. Dalam praktik saya, paling sering saya menggunakannya, itu memberikan kualitas yang cukup. Jika persyaratan kualitas meningkat, maka kami beralih ke penerimaan. Penggunaan tes integrasi tergantung pada pelanggan, yang mungkin ingin menguji bagian-bagian tertentu dari proyek.

Tumpukan teknologi saya saat ini adalah angular dan .net. Dan jika pada pengujian sisi server tidak menimbulkan pertanyaan besar, maka pengujian aplikasi klien masih, di banyak tempat, tidak jelas bagi semua orang. Pada proyek klien saya, jumlah tes unit bervariasi dari beberapa ratus hingga beberapa ribu. Pada artikel selanjutnya saya akan mencoba berbagi teknik utama untuk menguji aplikasi sudut.