Pada 6-7 Desember, konferensi Heisenbag kelima diadakan di Moskow.
Slogannya adalah "Menguji. Bukan hanya untuk penguji! ”, Dan selama dua tahun kunjungan rutin ke Heisenbags, saya (sebelumnya pengembang Java, sekarang menjadi pemimpin teknis di sebuah perusahaan kecil yang tidak pernah bekerja di QA) berhasil belajar banyak dalam pengujian dan mengimplementasikan banyak hal dalam tim kami. Saya ingin berbagi ulasan subjektif dari laporan yang saya ingat saat ini.
Penafian. Tentu saja, ini hanya sebagian kecil (8 dari 30) laporan yang dipilih berdasarkan preferensi pribadi saya. Hampir semua laporan ini entah bagaimana terkait dengan Java dan tidak ada satu pun tentang front-end dan pengembangan ponsel. Di beberapa tempat saya akan membiarkan diri saya polemik dengan pembicara. Jika Anda tertarik pada ulasan yang lebih lengkap dan netral, menurut tradisi itu akan muncul
di blog penyelenggara . Tetapi, mungkin, akan menarik bagi seseorang untuk mengetahui hanya tentang laporan-laporan yang tidak dapat mereka kunjungi.
Foto dalam artikel tersebut berasal dari twitter resmi konferensi.Baruch Sadogursky. Kami memiliki DevOps. Mari kita memecat semua penguji
(Dalam foto - hype ketika Baruch mendistribusikan buku Liquid Software )Mereka yang terlibat di Jawa dan menghadiri konferensi JUGRU Group, Baruch Sadogursky tidak perlu diperkenalkan. Namun, ia tampil untuk pertama kalinya di Heisenbug.
Singkatnya - itu adalah laporan ulasan tentang ide-ide utama DevOps. Kebutuhan audiens akan laporan semacam itu tetap ada, karena ketika ditanya "Berikan definisi DevOps" kepada audiens, orang pertama-tama masih menjawab "ini orang yang seperti itu ..."
Tetapi bahkan mereka yang telah mempelajari sesuatu tentang topik ini, akan sangat menarik untuk belajar tentang studi-studi dari asosiasi DORA
devops-research.com , yang menerima persentase varietas pekerjaan manual dalam tim dengan kinerja yang berbeda. Dan tentang kurva yang menghubungkan kecepatan dan kualitas pengiriman (pada titik tertentu, kecepatan menurun, karena kita perlu waktu untuk "tes yang lebih baik", tetapi ketika tim berkembang, korelasinya menjadi langsung):
Meskipun judul laporan itu provokatif, dan dalam jadwal laporan itu ditandai dengan kategori "akan terbakar", isinya, menurut saya, cukup umum. Itu, tentu saja, bukan tentang pemecatan penguji di bawah kondisi transformasi Devops, tetapi tentang perubahan sifat pekerjaan penguji.
Alan Page dan Nikolai Alimenkov berbicara banyak tentang hal ini setahun yang lalu. Baik peran yang berubah dan pengembangan "horisontal" keterampilan berbentuk T dibahas setahun lalu di meja bundar "
apa yang harus diketahui oleh seorang penguji pada tahun 2018 ".
“Tentu saja, jika kamu tidak ingin berubah, ada pekerjaan untukmu, meskipun tidak begitu menarik. Sejauh ini, masih ada pekerjaan untuk mereka yang ingin mendukung sistem yang ditulis dalam COBOL di tahun 70-an, ”kata Baruch.
Artyom Eroshenko. Perlu merevisi proyek? Punya IDEA!
Artyom akrab bagi peserta Heisenbag dengan laporan tentang sistem pelaporan Allure (misalnya,
inilah laporannya tentang peluang Allure yang muncul pada 2018 dari Heisenbug sebelumnya di St. Petersburg). Allure sendiri lahir dalam konteks proyek dengan ribuan, puluhan ribu dan bahkan lebih dari ratusan ribu tes dan dirancang untuk menyederhanakan interaksi antara pengembang dan penguji. Ini memiliki kemampuan untuk menghubungkan tes dengan sumber daya eksternal seperti sistem tiket dan melakukan dalam sistem kontrol versi. Di tim mikro kami, sementara jumlah tes hanya mencapai puluhan, kami sepenuhnya mengatasi sarana standar. Tetapi ketika jumlah tes di salah satu produk mencapai 700 dan tugas keseluruhannya adalah untuk membuat laporan berkualitas tinggi bagi pelanggan, saya mulai melihat ke arah Allure.
Namun, laporan ini bukan tentang Allure, meskipun tentang dia juga.
Artyom meyakinkan publik bahwa menulis plugin untuk IntelliJ IDEA adalah kegiatan yang sederhana dan menarik. Mengapa ini diperlukan? Untuk mengotomatisasi modifikasi kode massal. Misalnya, untuk menerjemahkan sejumlah besar kode sumber dari JUnit4 ke JUnit5. Atau dari penggunaan Allure 1 hingga Allure 2. Atau untuk mengotomatiskan penandaan tes dengan komunikasi dengan sistem detak.
Mereka yang bekerja dengan IDEA tahu trik apa yang dapat dilakukan dengan kode (misalnya, menerjemahkan kode secara otomatis menggunakan for-loop ke dalam kode menggunakan Java Streaming dan sebaliknya, atau langsung menerjemahkan Java ke Kotlin). Yang lebih menarik adalah melihat bagaimana tabir kerahasiaan atas transformasi kode di IDEA dibuka, kami diundang untuk mengambil bagian dalam hal ini dan membuat plugin sendiri untuk kebutuhan unik kami. Lain kali, ketika saya perlu melakukan sesuatu dengan basis kode yang besar, saya akan mengingat laporan ini dan melihat bagaimana ini dapat diotomatisasi menggunakan plug-in generik di IDEA.
Kirill Merkushev. Proyek Java dan Reactor - bagaimana dengan tes?
Menurut saya, laporan ini bisa saja terjadi di konferensi Joker atau JPoint Java. Kirill berbicara tentang bagaimana ia menggunakan kerangka
projectreactor.io dalam arsitektur layanan
microsoft dengan log peristiwa tunggal (Kafka), sedikit tentang esensi pengkodean pada "aliran reaktif", termasuk bagaimana aplikasi yang menggunakan kerangka kerja ini dapat di-debug dan diuji.
Life juga mendorong tim kami untuk menggunakan arsitektur dengan satu event log, dan kami juga melihat Kafka. Benar, untuk acara streaming, kami bereksperimen dengan Kafka Streams API (di mana, menurut saya, lebih banyak hal seperti pemrosesan stateful diimplementasikan di luar kotak secara transparan untuk pengembang), dan bukan Reactor. Namun, seperti yang selalu terjadi dengan teknologi baru, "rake" dan "jebakan" tidak diketahui sebelumnya. Karena itu, penting untuk mendengarkan kisah seorang spesialis yang sudah bekerja dengan teknologi.
Leonid Rudenko. Mengelola Cluster Selenoid dengan Terraform
Jika laporan sebelumnya mengingatkan pada konferensi JPoint, maka yang ini tentu tentang
DevOops . Leonid berbicara tentang cara menggunakan spesifikasi Terraform untuk menaikkan dan mengkonfigurasi cluster Selenoid. Tentang apa itu Selenoid itu sendiri, ada
laporan tentang Heisenbug tahun lalu - ini adalah sistem terdistribusi yang kaya yang berfungsi sebagai layanan elastis dan memungkinkan Anda untuk menjalankan sejumlah besar tes Selenium di berbagai browser. Seperti sistem apa pun yang membutuhkan penyebaran pada beberapa mesin, menginstal Selenoid secara manual sulit. Di sini, sistem Konfigurasi-sebagai-Kode modern datang untuk menyelamatkan.
Leonid membuat tinjauan yang cukup terperinci tentang kemampuan Terraform - sebuah sistem yang mungkin tidak dikenal oleh sebagian besar pemirsa, tetapi sebenarnya sudah terkenal dengan DevOps-automation (misalnya, pada konferensi Devoops-2018 ada
laporan yang sangat baik oleh Anton Babenko tentang praktik terbaik untuk membuat dan memelihara kode pada Terraform). Lebih lanjut, diperlihatkan bagaimana menggunakan skrip Terraform untuk menggambarkan parameter kontainer buruh pelabuhan dengan Selenoid untuk masing-masing mesin di cluster dan parameter dari mesin virtual cluster itu sendiri.
Meskipun kasus spesifik yang dipertimbangkan oleh Leonid tentu saja dapat memudahkan tugas penempatan Selenoid, saya tidak setuju dengan pembicara tentang segalanya. Pada dasarnya, ia menggunakan Terraform untuk dua tugas berbeda: membuat sumber daya dan mengonfigurasinya. Dan ini mengarah pada fakta bahwa Leonid terpaksa menjalankan Terraform sekali untuk membuat mesin virtual dan sekali lagi untuk masing-masing mesin virtual untuk menaikkan kontainer buruh pelabuhan. Menurut pendapat saya, Terraform, yang memecahkan masalah membuat sumber daya dengan baik, tidak menyelesaikan masalah konfigurasi dengan sangat baik. Adalah mungkin untuk menghindari penggandaan proyek terraform dan beberapa peluncurannya menggunakan sistem konfigurasi khusus, misalnya Ansible, atau solusi lain.
Tetapi secara umum, sebagai "program pendidikan" untuk penguji di bidang Infrastruktur sebagai Kode, laporan ini sangat berguna.
Andrey Markelov. Pengujian integrasi elegan kebun binatang microservice dengan TestContainers dan JUnit 5 menggunakan contoh platform SMS global
Dan lagi tentang layanan microser! Kali ini, percakapannya adalah tentang bagaimana menjalankan tes yang memerlukan peluncuran dan interaksi beberapa layanan pada saat yang sama. JUnit5 dengan
sistem Ekstensi dan kerangka kerja TestContain yang terkenal (dan sangat bagus) diusulkan sebagai dasar solusi (lihat, misalnya,
laporan tahun lalu oleh Sergey Egorov ).
Jika Anda menulis sesuatu di Java dan masih tidak tahu apa itu TestContainers, saya sangat menyarankan Anda mempelajarinya. TestContainers memungkinkan, menggunakan teknologi Docker, langsung dalam kode uji untuk meningkatkan basis data nyata dan layanan lainnya, menghubungkannya melalui jaringan dan, sebagai hasilnya, melakukan pengujian integrasi di lingkungan yang dibuat pada saat pengujian diluncurkan dan dihancurkan segera setelah itu. Pada saat yang sama, semuanya bekerja langsung dari kode Java, terhubung sebagai ketergantungan Maven dan tidak perlu menginstal apa pun selain Docker di server mesin / CI pengembang. Kami telah menggunakan TestContainers selama lebih dari satu tahun sekarang.
Andrey menunjukkan contoh yang cukup mengesankan tentang bagaimana Anda dapat meresepkan konfigurasi lingkungan pengujian untuk pengujian ujung-ke-ujung menggunakan JUnit5 Extensions, anotasi khusus, dan TestContainers. Misalnya, menulis anotasi di atas pengujian Anda (kode kondisional)
@Billing @Messaging
kita dapat, secara relatif, menulis
@Test void systemIsDoingRightThings(BillingService b, MessagingService m) {...}
ke dalam parameter yang antarmuka Java akan dilewati di mana Anda dapat berkomunikasi dengan layanan nyata yang diangkat (tanpa disadari oleh pengembang tes) dalam wadah.
Contoh-contoh ini terlihat sangat elegan. Bagi saya, sebagai pengguna aktif TestContainers dan JUnit 5, mereka dapat dimengerti dan relatif mudah diimplementasikan.
Tetapi secara umum, dengan pendekatan ini, pertanyaan besar tetap tidak terselesaikan, terkait dengan fakta bahwa cara mengkonfigurasi sistem pengujian dan produksi pada dasarnya berbeda.
Menerapkan rilis cepat dalam produksi tanpa takut merusak semuanya adalah mungkin hanya jika selama pengujian end-to-end tidak hanya seluruh sistem diuji, tetapi juga cara untuk mengkonfigurasinya. Jika kami berulang kali menjalankan skrip penyebaran sistem selama proses pengembangan dan pengujian, kami tidak akan ragu bahwa skrip ini akan berfungsi bahkan ketika diluncurkan dalam produksi. Peran kode yang mengonfigurasi lingkungan pengujian dalam contoh Andrey dilakukan oleh anotasi. Tetapi dalam produksi kami membuat sistem menggunakan kode yang sama sekali berbeda - Kemungkinan, Kubernetes, apa pun - tidak terlibat dengan cara apa pun dengan pengujian sistem tersebut. Dan ini membatasi tes ini, yang tidak sepenuhnya ujung ke ujung.
Andrey Glazkov. Sistem pengujian dengan dependensi eksternal: masalah, solusi, Mountebank
Bagi mereka yang topik laporannya relevan, saya sangat menyarankan Anda untuk menonton
presentasi yang bagus oleh Andrei Solntsev tentang pendekatan berprinsip pada sistem pengujian yang bergantung pada layanan eksternal. Solntsev berbicara dengan sangat meyakinkan tentang perlunya menggunakan tiruan sistem eksternal untuk pengujian komprehensif. Dan Andrei Glazkov dalam laporannya menggambarkan salah satu sistem untuk pembasahan seperti itu - Mountebank, ditulis dalam NodeJS.
Anda dapat mengangkat Mountebank sebagai server dan "melatih" jawaban atas permintaan melalui jaringan dengan cara yang mirip dengan cara kami "melatih" antarmuka mengejek ketika menulis unit test. Satu-satunya perbedaan adalah bahwa itu adalah tiruan dari layanan jaringan. Kasus aneh menggunakan Mountebank adalah kemampuan untuk menggunakannya sebagai proxy - mengirim beberapa permintaan ke sistem eksternal nyata.
Perlu dicatat di sini bahwa saya akan merekomendasikan bahwa pengembang Java (dan Andrei setuju di area diskusi) juga melihat ke perpustakaan WireMock, yang dibuat di Java dan dapat dijalankan dalam mode tertanam, yaitu langsung dari tes tanpa menginstal apapun Entah layanan ke mesin pengembang atau server CI (meskipun juga dapat berfungsi sebagai server mandiri). Seperti halnya Mountebank, WireMock mendukung mode proxy. Kami memiliki pengalaman positif dengan WireMock.
Keuntungan Mountebank, bagaimanapun, adalah dukungan protokol tingkat rendah (WireMock hanya berfungsi untuk HTTP) dan kemampuan untuk bekerja di "kebun binatang" berbagai teknologi (ada perpustakaan untuk berbagai bahasa untuk Mountebank).
Kirill Tolkachev. Menguji dan menangis dengan Uji Boot Spring
Dan lagi Java, microservices dan JUnit 5. Kirill adalah pembicara lain dari konferensi Joker dan JPoint, yang terkenal di komunitas Jawa, yang berbicara untuk pertama kalinya di Heisenbug.
Laporan ini adalah versi modifikasi dari laporan
Musim Semi Kutukan tahun lalu, dengan contoh-contoh yang dimodifikasi untuk JUnit5 dan Spring Boot 2. Berbagai masalah praktis terkait dengan mengkonfigurasi tes Spring Boot dalam pengujian komponen / layanan mikro diperiksa secara mendalam. Sebagai contoh, saya terkesan dengan contoh menggunakan
@SpringBootConfiguration StopConfiguration kosong di tempat yang tepat di pohon sumber untuk menghentikan proses pemindaian konfigurasi, serta kemungkinan menggunakan
@MockBean dan
@SpyBean bukannya mengolok-olok. Seperti laporan lain oleh Cyril dan Evgeny Borisov, ini adalah bahan yang masuk akal untuk kembali ke dalam proses penggunaan praktis dari Kerangka Kerja Pegas.
Andrey Karpov. Apa yang dapat dilakukan oleh penganalisa statis, yang tidak dapat dilakukan oleh programmer dan penguji
Analisis kode statis adalah hal yang baik. Menurut kanon Pengiriman Kontinu, itu harus menjadi fase pertama dari pipa pengiriman, menyaring kode dengan masalah yang dapat dideteksi dengan "membaca" kode tersebut. Analisis statis baik karena cepat (jauh lebih cepat daripada tes) dan murah (tidak memerlukan upaya tambahan dari tim dalam bentuk tes menulis: semua cek telah ditulis oleh penulis penganalisis).
Andrey Karpov, salah satu pendiri proyek PVS-Studio (yang akrab dengan pembaca Habr dengan
blognya ) membuat laporan tentang contoh bug apa dalam analisis kode produk yang dikenal yang ditemukan menggunakan PVS-Studio. PVS Studio sendiri adalah produk polyglot, mendukung C, C ++, C # dan, yang lebih baru, Java.
Terlepas dari kenyataan bahwa contoh-contoh di atas menarik dan kegunaan analisis statis mereka jelas, menurut pendapat saya, laporan Andrey memiliki kekurangan.
Pertama, laporan itu dibuat semata-mata berdasarkan pertimbangan produk PVS-Studio (yang menurut pembicara, "label harga rata-rata adalah $ 10.000"). Tetapi perlu disebutkan bahwa, pada kenyataannya, dalam banyak bahasa ada banyak sistem analisis statis OpenSource yang dikembangkan. Di Jawa saja - Checkstyle dan SpotBugs gratis (penerus proyek FindBugs yang dibekukan), serta penganalisa IntelliJ IDEA, yang dapat dijalankan secara terpisah dari IDE dan menerima laporan, membuat kemajuan luar biasa.
Kedua, berbicara tentang analisis statis, bagi saya tampaknya selalu menyebutkan keterbatasan mendasar dari metode ini. Tidak semua orang melalui teori algoritma di universitas dan terbiasa dengan "masalah shutdown," misalnya.
Dan akhirnya, masalah memperkenalkan analisis statis ke dalam basis kode yang ada tidak diangkat sama sekali, yang masih mencegah banyak dari penggunaan analisis yang rutin pada proyek. Sebagai contoh, kami menjalankan analisa pada proyek warisan besar dan menemukan 100.500 vorings. Tidak ada waktu dan upaya untuk memperbaikinya di tempat, dan secara besar-besaran mengubah sesuatu dalam kode adalah risiko. Apa yang harus dilakukan dengan ini, bagaimana membuat analisis statis berfungsi sebagai gerbang kualitas? Masalah ini dibahas di area diskusi dengan Andrei, tetapi masalah ini tidak dipertimbangkan dalam laporan itu sendiri.
Secara umum, saya berharap Andrey dan timnya sukses. Produk mereka menarik dan ide untuk menempati ceruknya di bidang ini sangat berani.
***
Mungkin saya tidak akan mengatakan apa-apa tentang intisari akhir dari hari pertama dan kedua: keduanya merupakan pertunjukan hak cipta yang hanya perlu Anda tonton. Berbicara tentang mereka seperti menceritakan kembali dengan kata-kata, misalnya, pertunjukan oleh band rock.
Dalam laporan saya
setahun yang lalu, saya sudah mencoba menyampaikan suasana umum konferensi dan berbicara tentang apa yang terjadi di area diskusi, saat makan siang dan di pesta, jadi saya tidak akan mengulangi lagi.
Sebagai penutup, saya ingin mengucapkan terima kasih kepada penyelenggara atas konferensi yang diadakan dengan indahnya. Seperti yang saya pahami, ketertarikan pada konferensi sedikit melebihi harapan, ada overbooking dan bahkan tidak semua orang punya cukup oleh-oleh. Tetapi yang pasti, semua orang memiliki hal-hal yang lebih penting: laporan menarik, ruang diskusi, makanan dan minuman. Saya menantikan pertemuan baru!