Dalam artikel sebelumnya, saya berbagi pengalaman otomasi saya pada Robot Framework. Sekarang kita akan berbicara tentang pendekatan yang sedikit berbeda untuk menguji API untuk proyek di Kotlin.
Mengambil keuntungan dari kebebasan untuk memilih tumpukan teknologi dan mengandalkan keinginan untuk mencoba sesuatu yang baru "dalam pertempuran", saya beralih ke Rest-Assured. Bukan tanpa kesulitan, kolega saya dan saya meluncurkan tes, dan sebagai hasil dari pengembangan pendekatan, kami mencatatnya dalam daftar tugas utama untuk tugas semacam ini.
(gambar digunakan sebagai parodi)Semuanya dimulai dengan fakta bahwa permintaan diterima untuk mengotomatiskan pengujian API pada salah satu proyek baru di
segmen Ad-tech . Kami melakukan Manajer Kampanye, DMP, dan beberapa integrasi dengan sistem pihak ketiga. Dan para penguji memiliki tugas yang sangat sederhana: mengotomatisasi pengujian asap untuk integrasi lebih lanjut ke dalam CI dan pemantauan terus-menerus dari API ini, karena sistem pihak ketiga terikat padanya dan operasi yang benar sangat penting. Verifikasi logika bisnis dalam kasus ini tidak diperlukan, karena layanan yang diuji pada dasarnya adalah antarmuka proxy.
Mengapa Istirahat Dijamin?
Dari sudut pandang otomatisasi pengujian, kami berhasil bekerja di berbagai bidang - UI, web, seluler, desktop, backend, REST API, SOAP.
Proyek sebelumnya memberi kami banyak pengalaman di Kerangka Robot, jadi akan lebih logis untuk menggunakannya. Sebagian besar tim penguji sudah mengenalnya, dan jika diperlukan penggantian, ini akan dilakukan dengan cepat dan tanpa rasa sakit. Tetapi keputusan berbeda dibuat.
Pertama, proyek itu sendiri ditulis di Kotlin dan dibangun menggunakan Gradle. Pada saat yang sama, pada tahap desain, autotests diputuskan untuk tidak mengalokasikan proyek terpisah. Seperti disebutkan dalam komentar di artikel sebelumnya, menempel bersama Jawa (Kotlin) dan Kerangka Robot adalah masalah besar, jadi tidak ada gunanya merujuk ke RF. Plus, melihat kembali bekerja dengan robot, saya tertarik mencoba pendekatan yang berbeda. Selain itu, pada proyek ini kita dapat secara mandiri memilih tumpukan teknologi - bisnis tidak menetapkan kondisinya sendiri.
Dalam mencari ide, saya beralih ke tim pengembangan kami, serta kolega dari pengujian, dan CTO menyarankan
saya untuk melihat Rest-Assured (
rest-assured.io ). Setelah saya membaca dokumentasi dan tes sampel dalam sumber terbuka, pendekatan yang diusulkan oleh Rest-Assured tampak sangat menarik bagi saya. Ini berarti menerima respons dari backend dalam bentuk JSON, yang kami deserialisasi menjadi objek Java lama yang baik.
Selanjutnya, dengan struktur ini, Anda dapat bekerja seperti pada objek normal. Sebagai hasilnya, kami memiliki pendekatan berorientasi objek yang sepenuhnya normal untuk memvalidasi korespondensi dari respons API terhadap struktur objek yang dijelaskan. Sebagai bonus, kami mendapatkan pengujian cepat terhadap struktur respons yang gagal - jika objek yang diterima dengan melakukan deserialisasi, respons API berbeda dalam jumlah bidang atau nama mereka, pengujian akan turun bahkan sebelum memeriksa data dengan kesalahan deserialisasi. Jadi kami akan mengerti jika kami perlu memperbaiki backend atau memperbarui tes sesuai dengan persyaratan API baru. Dalam kasus kami, ini penting karena, seperti yang saya sebutkan di atas, banyak subsistem pihak ketiga terkait dengan API.
Untuk keakuratan, saya perhatikan bahwa kira-kira tes anti-gagal yang sama dapat diperoleh pada RF, tetapi dengan cara yang sedikit berbeda. Namun, kisah hari ini bukan tentang itu. Secara pribadi, itu lebih nyaman dan mudah dimengerti bagi saya untuk masuk dari sisi Istirahat Diasuransikan dengan entitas yang memiliki bidang dan metode tertentu.
Tes bulu
Sebelum mulai menggunakan tumpukan pada proyek nyata, saya memutuskan untuk mencobanya pada layanan CRUD kecil. Agar tidak segera mempraktikkan kesalahannya sendiri, ia memutuskan untuk mencari praktik terbaik di tumpukan ini dan dengan cepat menemukan
artikel oleh Philip Hauer , di mana ia mencerminkan pengalaman otomasi pada Rest-Assured. Setelah mempelajari artikel itu, menulis versi kerja dari tes layanan saya tidaklah sulit. Mereka ternyata sederhana, mudah dibaca dan dimengerti.
Ke pertempuran!
Proyek dimulai, dan ketika struktur respons pertama dijelaskan, persiapan dokumentasi uji dan penulisan autotest dimulai. Untuk memahami gambaran besarnya, saya akan memberikan setumpuk percobaan lengkap:
- Jawa
- JUnit4 - eksekusi dan parameterisasi skrip pengujian (anotasi standar @Parametrize),
- Diasuransikan - membangun dan menjalankan permintaan,
- AssertJ - validasi dari nilai yang diterima,
- Daya pikat - bangunan pelaporan,
- Gradle - assembly
- Jackson - deserialisasi.
Ketika tes pertama ditulis, masalah parameterisasi yang tepat menjadi jelas. Untuk menyampaikan nilai-nilai sederhana data dan hasil yang diharapkan tampak sangat tidak efisien dan jelek. Saya tidak punya waktu untuk menyelesaikan masalah ini sebelum liburan, tetapi rekan-rekan saya, yang terlibat selama ketidakhadiran saya, menyelesaikannya. Untuk parameterisasi yang indah dan mudah dibaca, mereka memutuskan untuk membuat kelas dasar dengan fungsi menambahkan, menerima, dan menghapus parameter objek, dari mana semua kelas yang objeknya digunakan untuk memanggil metode API yang sesuai diwarisi.
Ini benar-benar memungkinkan untuk membuat data yang diperlukan dan mengirimkannya dalam parameter uji.
Istirahat Diasuransikan memungkinkan Anda untuk membatalkan respon terhadap kelas yang diperlukan. Jawaban yang dihasilkan didekomposisi menjadi struktur yang sebelumnya dikenal menggunakan Jackson. Kelas-kelas untuk deserialisasi terlihat sesederhana mungkin - semua bidang yang diharapkan dengan tipenya dijelaskan.
Selanjutnya, pekerjaan sederhana dengan objek dan pernyataan bidang tertentu dan nilai-nilainya berlanjut.
Hal yang paling sulit dan tidak jelas yang saya temui dalam pendekatan ini adalah ketidakmampuan untuk melewatkan null ke Rest-Assured sebagai salah satu parameter (hasilnya adalah penurunan NullPointerException). Rupanya, ini adalah masalah yang diketahui, tetapi pengembang tidak akan memperbaiki situasi, merekomendasikan untuk mengirim bidang kosong atau tidak mengirimnya sama sekali. Kami menghadapi masalah ini sudah pada tahap ketika dasar proyek sudah siap dan hanya tinggal menambahkan kelas uji. Karenanya, kami hanya sedikit memperbaiki kode kami.
Secara umum, saya suka pendekatannya. Sangat mengherankan bahwa setelah beberapa waktu mulai diterapkan pada proyek pelanggan lain (meskipun bukan dari pasokan kami). Dan kami menempatkan tumpukan rakitan untuk API pengujian otomasi (JUnit + AssertJ + Rest-Assured) ke dalam kategori kunci untuk proyek Java / Kotlin. Dalam Python, menariknya akan berlawanan dengan intuisi, karena lebih baik bahwa pengembangan dan pengujian kompetensi tumpang tindih.
Perlu juga dicatat bahwa salah satu keuntungan dari solusi ini adalah skalabilitas dan kemampuan beradaptasi dengan logika yang kompleks. Ini berarti bahwa itu paling cocok untuk proyek-proyek serius di mana sangat masuk akal untuk menggambarkan objek besar, kode bersih dan arsitektur blok, ketika ada bagian terpisah yang bertanggung jawab untuk mempersiapkan, mengirim dan menerima data dalam bentuk yang dapat dibaca, serta verifikasi data selanjutnya untuk kepatuhan beberapa kondisi. Dalam proyek-proyek kecil, semua ini tidak ada artinya untuk ditarik.
Ringkasan
Dalam sekitar satu bulan, kami dapat mengotomatisasi sekitar 250 tes dan memberikan tingkat cakupan yang diperlukan. Tentu saja, setelah proses otomatisasi berakhir, sebuah presentasi internal diadakan untuk semua orang, sehingga karyawan memiliki gagasan tentang pekerjaan yang dilakukan dan dapat belajar dari pengalaman yang diperoleh pada proyek ini.
Penulis artikel: Dmitry Masters
PS Kami menerbitkan artikel kami di beberapa situs Runet. Berlangganan ke halaman kami di
VK ,
FB atau
saluran Telegram untuk mencari tahu tentang semua publikasi kami dan berita Maxilect lainnya.