Judul Kotlin diklaim lebih terkait dengan pengembangan Android, tetapi mengapa tidak bereksperimen? Dengan bantuannya, kami menemukan cara untuk sedikit menyederhanakan otomatisasi pengujian API dari salah satu layanan kami, serta untuk memfasilitasi pekerjaan penguji yang tidak terbiasa dengan pemrograman dan nuansa bahasa Jawa.
Apa yang kita lakukan? Kami sedang mengembangkan layanan untuk mengirimkan kuesioner broker untuk menghitung dan menerima keputusan. Dan terlepas dari kenyataan bahwa ini adalah solusi perbankan, pengembangan dilakukan oleh tim scrum kecil, di mana 1-2 spesialis terlibat dalam pengujian, tergantung pada beban dan situasi pada proyek.
Di bawah potongan, kami akan memberi tahu Anda tentang hasil percobaan kami, yang dengan senang hati kami transfer ke produksi.
Tanpa muka
Layanan kami dikembangkan untuk berintegrasi dengan antarmuka mitra dan tidak memiliki UI sendiri. Karenanya, dalam hal ini, menguji API secara langsung adalah satu-satunya pilihan yang tersedia. Meskipun uji API memiliki sejumlah keunggulan bahkan dengan antarmuka:
- memungkinkan Anda untuk memulai pengujian pada tahap pengembangan layanan;
- menyederhanakan lokalisasi kesalahan;
- umumnya mengurangi waktu pengujian.
Layanan kami mencakup serangkaian API untuk mentransfer data kuesioner klien untuk perhitungan dan untuk mendapatkan solusi untuk pinjaman mobil. Pemeriksaan berikut dapat dibedakan sebagai tugas pengujian tingkat tinggi utama:
- format bidang dan parameter;
- kebenaran kode status dan pesan kesalahan;
- bidang yang diperlukan dan logika layanan.
Momen penting
Tim menyiapkan MVP layanan dalam waktu yang sangat singkat, dan tes otomatis pada awalnya ditulis oleh pengembang produk. Autotests lebih cepat dan lebih mudah untuk dimasukkan dalam proyek, jadi mereka awalnya terkait erat dengan kodenya dan didasarkan pada Java stack, REST-terjamin, dan kerangka uji TestNG.
Dengan pengembangan proyek, keterlibatan penguji dalam proses otomatisasi tumbuh. Saat ini, tugas mendukung dan memperbarui autotes sepenuhnya berada pada departemen pengujian. Dalam hal ini, menjadi perlu untuk menyesuaikan pendekatan terhadap otomasi - untuk menyederhanakan tes sebanyak mungkin dan membuatnya independen dari kode utama. Dan, dengan demikian, untuk mengatasi kesulitan yang timbul:
- komunikasi dengan kode membuat tes lebih rentan terhadap perubahan desain, membutuhkan banyak tenaga untuk mempertahankan kinerja;
- hubungan yang kompleks meningkatkan waktu untuk mencari informasi dan menyelidiki kesalahan;
- Sulit untuk melibatkan karyawan baru dari departemen pengujian dalam bekerja dengan kode Java, itu memerlukan pelatihan penguji dan sejumlah besar waktu untuk memasuki proyek.
Oleh karena itu, kami memutuskan untuk mengubah pendekatan pengujian dan merumuskan persyaratan berikut untuk alat baru:
- kompatibilitas penuh dengan Java, yang memungkinkan Anda untuk menulis ulang pemeriksaan secara bertahap, sambil terus bekerja dengan tes lama;
- kode sederhana, intuitif;
- bahasa bebas dan stabil;
- pemilihan autotest dalam proyek terpisah.
Apa yang harus dilakukan Kotlin dengannya
Bahasa Kotlin memenuhi kebutuhan kita sebanyak mungkin.
Selain kompatibilitas penuh dengan Java di Kotlin, kami tertarik pada fitur-fitur berikut:
- keringkasan bahasa membuat kode menjadi jelas dan mudah dibaca;
- gula sintaksis;
- kode intuitif dan masuknya spesialis dengan mudah ke dalam proyek;
- kemampuan untuk mentransfer autotests dari Jawa ke Kotlin secara bertahap dan tanpa rasa sakit, sebagian jika perlu.
Tentu saja, ada juga kerugiannya, terutama jika dibandingkan dengan Jawa. Pertama, komunitas yang relatif kecil: mencari bantuan dan jawaban untuk pertanyaan di Jawa jauh lebih mudah daripada dengan Kotlin. Kedua, secara umum, Jawa adalah bahasa yang lebih universal dengan lebih banyak kemampuan dan sejumlah besar pengembangan dan perpustakaan.
Tapi, jujur saja, untuk tujuan pengujian, kita tidak membutuhkan kemampuan luas yang hanya bisa disediakan oleh Java. Karena itu, kami lebih suka kesederhanaan dan singkatnya Kotlin.
Dari kata-kata hingga perbuatan
Sebagai hasil dari transisi parsial ke bahasa baru, kami menerima keuntungan nyata dalam biaya tenaga kerja untuk spesialis, penyederhanaan signifikan dari kode dan pengurangan volumenya. Ini jelas terlihat dalam contoh spesifik dari pengujian layanan kami untuk memproses profil broker.
Di Kotlin, Anda dapat menginisialisasi objek permintaan dengan satu baris kode. Misalnya, kelas ApplicationDTO (untuk mengirim kuesioner ke solusi) dan ErrorDTO (kesalahan yang berasal dari layanan) terlihat seperti ini:
Kotlin memungkinkan Anda untuk menetapkan nilai bidang selama inisialisasi. Ini menghemat banyak waktu saat menulis tes: saat membuat objek, bidang sudah diisi dengan data yang valid, kami hanya mengubah nilai-nilai yang merujuk pada pemeriksaan saat ini.
Anotasi JsonIgnoreProperties memungkinkan Anda untuk tidak menentukan semua bidang dalam kelas jika tidak diperlukan untuk tes dan tidak perlu diperiksa. Jika bidang diterima yang tidak ditentukan dalam deskripsi, pengujian tidak akan gagal dengan kesalahan.
Tanda tanya pada jenis variabel menunjukkan bahwa pada titik tertentu itu bisa nol. Tetapi ketika menggunakan variabel, ini harus diperhitungkan dan diproses. Akhirnya, tidak seperti tes Java, NullPointerException dapat dihindari dengan anggun di sini.
Mari kita ilustrasikan dengan contoh sederhana pengecekan kesalahan untuk login yang salah:
class ApplicationTests {
val DEFAULT_LOGIN = "consLogin"
val ERROR_CODE = "3"
val BASE_URI = "https://base_url.com"
@Test
fun incorrectLogin() {
val incorrectLogin = DEFAULT_LOGIN + "INCORRECT";
val res = given()
.spec(spec)
.body(ApplicationDTO)
.`when`()
.post(endpointApplication(incorrectLogin)
.then()
.statusCode(400)
.extract().`as`(ErrorDTO::class.java)
assertThat(res.error_message).containsIgnoringCase(" ")
assertThat(res.error_code).isEqualToIgnoringCase(ERROR_CODE)
}
companion object{
private var spec: RequestSpecification? = null
@JvmStatic
@BeforeClass
fun initSpec() {
spec = RequestSpecBuilder()
.setContentType(ContentType.JSON)
.setBaseUri(BASE_URI)
.addFilter(ResponseLoggingFilter())
.addFilter(RequestLoggingFilter())
.build()
}
}
}Kami membuat spesifikasi untuk kueri di BeforeClass, yang kami gunakan kembali dalam semua tes kelas ini. Jackson membuat cerita bersambung dan deserializes objek json, yang menyederhanakan hal: Anda tidak perlu bekerja dengan mereka sebagai dengan string, karena ini, jumlah kesalahan berkurang secara signifikan.
Dengan Kotlin, kami secara signifikan mengurangi jumlah kode, yang berarti kami membuat hidup lebih mudah bagi "penulis" dan "pembaca". Kelas ApplicationDTO sudah berisi konstruktor dan beberapa metode lain (kode hash (), salin (), dll.) - kita tidak perlu "membebani" kode dengan mereka dan pengembang autotest pemula tidak terganggu oleh mereka. Mereka tidak perlu diperbarui jika ada perubahan, yang mengurangi waktu untuk mengedit.
Juga sangat nyaman bahwa Kotlin mendukung argumen bernama - kode ini cukup mudah dibaca, dan tidak perlu menulis setter untuk kelas objek json sendiri.
Cobalah hal-hal baru secara gratis
Saya ingin mencatat keterbukaan dan kehijauan Kotlin dan semua perpustakaan yang kami gunakan, yang sangat menyederhanakan pekerjaan dan memperluas kemungkinan untuk bereksperimen dan memperkenalkan pendekatan baru. Setuju, selalu lebih mudah untuk mencoba hal-hal baru secara gratis, dan jika gagal, kembalilah ke praktik lama.
Di masa depan, kami berencana untuk mengembangkan pendekatan baru dan skala untuk proyek lain, menerjemahkan sisa API dan tes antarmuka pengguna ke Kotlin.
PS: Terlepas dari kenyataan bahwa Kotlin terutama terkait dengan pengembangan Android, ruang lingkup penggunaannya, seperti yang Anda mengerti, tidak terbatas pada ini. Mengurangi waktu yang dihabiskan untuk menulis kode, kesederhanaan dan keringkasannya akan membantu mengurangi biaya tenaga kerja dalam menyelesaikan banyak masalah. Jika kami memiliki kasus baru dengan Kotlin, kami pasti akan memberi tahu Anda tentang mereka.di sini .