Mungkin setiap rasa sakit mengetahui rasa sakit ini - dokumentasi yang tidak relevan. Tidak peduli seberapa keras tim berusaha, dalam proyek-proyek modern kami akan merilis begitu sering sehingga hampir tidak mungkin untuk menggambarkan semua perubahan. Tim pengujian kami, bersama dengan analis sistem, memutuskan untuk mencoba merevitalisasi dokumentasi proyek kami.
Proyek web Alfa-Bank menggunakan kerangka kerja otomatisasi pengujian
Akita , yang digunakan untuk skrip BDD. Sampai saat ini, kerangka kerja ini telah mendapatkan popularitas besar karena ambang masuknya rendah, kegunaan dan kemampuan untuk menguji tata letak. Tetapi kami memutuskan untuk melangkah lebih jauh - berdasarkan skenario pengujian yang dijelaskan untuk menghasilkan dokumentasi, dengan demikian sangat mengurangi waktu yang dihabiskan para analis untuk masalah abadi memperbarui dokumentasi.
Bahkan, bersama dengan Akita, plugin pembuatan dokumentasi sudah digunakan, yang melalui langkah-langkah dalam skrip dan mengunggahnya ke format html, tetapi untuk menjadikan dokumen ini populer, kami perlu menambahkan:
- Tangkapan layar
- nilai variabel (file konfigurasi, akun pengguna, dll.);
- status dan parameter kueri.
Kami melihat plug-in yang ada, yang, pada kenyataannya, merupakan penganalisa statis dan menghasilkan dokumentasi berdasarkan skrip yang dijelaskan dalam file .feature. Kami memutuskan untuk menambah speaker, dan agar tidak membuat plug-in seperti plug-in, kami memutuskan untuk menulis sendiri.
Pertama, kami memutuskan untuk mencari tahu bagaimana kami dapat mengumpulkan tangkapan layar dan nilai variabel yang digunakan dalam skrip uji dari file fitur. Semuanya ternyata sangat sederhana. Mentimun, saat menjalankan tes untuk setiap file fitur, membuat cucumber.json terpisah.
Di dalam file ini berisi objek-objek berikut:
Nama dan kata kunci kasus uji:
Susunan elemen - skrip dan langkah itu sendiri:
Kolom keluaran berisi informasi tambahan, misalnya, variabel - alamat, tautan, akun pengguna, dll .:
Embeddings berisi tangkapan layar yang diambil selenium selama pengujian:
Jadi, kita hanya perlu membaca file cucumber.json, mengumpulkan nama-nama suite pengujian, skrip pengujian, menarik langkah-langkahnya, mengumpulkan informasi tambahan dan tangkapan layar.
Agar dokumentasi dapat menampilkan permintaan yang terjadi di latar belakang atau untuk tindakan tertentu, kami harus meminta bantuan pengembang kami. Dengan bantuan proxy, kami dapat menangkap traceId, yang menghasilkan permintaan layanan front-end. Dengan traceId yang sama, log ditulis dalam elastis, dari mana kami menarik semua parameter kueri yang diperlukan ke dalam laporan pengujian dan dokumentasi.
Akibatnya, kami mendapat file dalam format Asciidoc - format file yang nyaman, sedikit lebih rumit daripada analog markdown, tetapi memiliki lebih banyak opsi format (Anda dapat menyisipkan gambar atau tabel, yang tidak dapat dilakukan dalam penurunan harga).
Untuk mengonversi Asciidoc yang dihasilkan ke format lain, kami menggunakan Ascii doctorj, yang merupakan versi resmi untuk alat Java AsciiDoctor. Sebagai hasilnya, kami mendapatkan dokumentasi siap pakai dalam format html, yang dapat diunduh dalam pertemuan, dikirim ke kolega atau dimasukkan ke dalam repositori.
Bagaimana cara terhubung?
Sekarang, untuk menghasilkan dokumentasi front-end untuk proyek Anda, Anda hanya perlu menghubungkan plugin dokumentasi untuk itu dan setelah menjalankan semua tes, jalankan perintah
adoc .
Apa yang ingin kita tingkatkan?
- Tambahkan langkah teknis yang dapat dikonfigurasi.
Di versi plugin saat ini ada langkah-langkah "Dan tangkapan layar diambil ...". Langkah-langkah seperti itu tidak memuat semantik untuk dokumentasi, dan kami ingin menyembunyikannya. Sekarang kita telah menjahitkannya di dalam plugin, dan mereka dilewati, tetapi ada kekurangan - setiap penambahan langkah ini mengarah pada fakta bahwa kita perlu membangun versi baru dari plugin. Untuk menghindari hal ini, kami berencana untuk mentransfer langkah-langkah tersebut ke file konfigurasi dan menuliskan langkah-langkah yang tidak ingin kita lihat dalam skrip. - Buat plugin sourse terbuka.
Tim mana yang cocok untuk implementasi kita?
- gunakan Mentimun (atau kerangka kerja serupa);
- ingin memiliki dokumentasi terkini untuk garis depan dan basis pengetahuan;
- Mereka ingin melibatkan analis dalam pengujian.
Hasil:
Pilot di beberapa tim menunjukkan bahwa dengan bantuan plugin kami mengelola untuk menjaga dokumentasi tetap mutakhir, analis tidak perlu lagi menghabiskan waktu untuk memeliharanya. Selain itu, penerapan fitur ini membuat kami berpikir untuk terus menerapkan BDD penuh dalam tim. Hari ini, kami sedang melakukan percobaan - analis merumuskan jalur positif untuk klien, menunjukkan batasan bisnis menggunakan langkah-langkah BDD Akita, penguji, pada gilirannya, menulis langkah-langkah khusus dan pemeriksaan tambahan untuk skenario ini.
Ngomong-ngomong, tentang holivar, apakah BDD diperlukan atau tidak, pada hari Senin kita akan mengadakan
pertemuan khusus .