Geekly articles weekly

Monolith untuk ratusan versi klien: cara kami menulis dan memelihara tes



Halo semuanya!

Saya adalah pengembang backend di tim server Badoo. Pada konferensi HighLoad tahun lalu, saya membuat presentasi , versi teks yang ingin saya bagikan dengan Anda. Posting ini akan sangat berguna bagi mereka yang menulis tes untuk backend sendiri dan mengalami masalah dengan pengujian kode warisan, serta mereka yang ingin menguji logika bisnis yang kompleks.

Apa yang akan kita bicarakan? Pertama, saya akan berbicara secara singkat tentang proses pengembangan kami dan bagaimana hal itu mempengaruhi kebutuhan kami untuk tes dan keinginan untuk menulis tes ini. Kemudian kita akan naik turun piramida otomatisasi tes, mendiskusikan jenis tes yang kita gunakan, berbicara tentang alat-alat di dalamnya masing-masing dan masalah apa yang kita pecahkan dengan bantuan mereka. Pada akhirnya, pertimbangkan cara memelihara dan menjalankan semua ini.

Proses pengembangan kami


Kami telah menggambarkan proses pengembangan kami:


Pegolf adalah pengembang backend. Pada titik tertentu, tugas pengembangan tiba padanya, biasanya dalam bentuk dua dokumen: persyaratan dari sisi bisnis dan dokumen teknis yang menggambarkan perubahan dalam protokol interaksi kami antara backend dan klien (aplikasi seluler dan situs).

Pengembang menulis kode dan menjalankannya, dan lebih awal dari semua aplikasi klien. Semua fungsionalitas dilindungi oleh beberapa tanda fitur atau pengujian A / B, ini ditentukan dalam dokumen teknis. Setelah itu, sesuai dengan prioritas saat ini dan peta jalan produk, aplikasi klien dirilis. Bagi kami, pengembang backend, benar-benar tidak dapat diprediksi ketika fitur tertentu akan diterapkan pada klien. Siklus rilis untuk aplikasi klien agak lebih rumit dan lebih lama dari kita, sehingga manajer produk kami benar-benar menyulap prioritas.

Budaya pengembangan yang diadopsi oleh perusahaan sangat penting: pengembang backend bertanggung jawab atas fitur tersebut sejak saat penerapannya di backend hingga integrasi terakhir pada platform terakhir tempat ia semula direncanakan untuk mengimplementasikan fitur ini.

Situasi ini sangat mungkin: enam bulan lalu, Anda meluncurkan beberapa fitur, tim klien tidak menerapkannya untuk waktu yang lama, karena prioritas perusahaan telah berubah, Anda sudah sibuk mengerjakan tugas-tugas lain, Anda memiliki tenggat waktu baru, prioritas - dan di sini rekan kerja Anda berlari dan mereka berkata: “Apakah kamu ingat benda yang kamu cucikan enam bulan yang lalu? Dia tidak bekerja. " Dan alih-alih terlibat dalam tugas baru, Anda memadamkan api.



Oleh karena itu, pengembang kami memiliki motivasi yang tidak biasa untuk programmer PHP - untuk memastikan bahwa ada masalah sesedikit mungkin selama fase integrasi.

Apa yang ingin Anda lakukan pertama-tama untuk memastikan fitur tersebut berfungsi?

Tentu saja, hal pertama yang terlintas dalam pikiran adalah melakukan pengujian manual. Anda mengambil aplikasi, tetapi tidak tahu caranya - karena fitur ini baru, pelanggan akan mengurusnya dalam enam bulan. Yah, pengujian manual tidak memberikan jaminan bahwa untuk waktu yang akan berlalu dari rilis backend ke awal integrasi, tidak ada yang akan merusak apa pun pada klien.

Dan di sini tes otomatis datang membantu kami.

Tes unit


Tes paling sederhana yang kami tulis adalah Tes unit. Kami menggunakan PHP sebagai bahasa utama untuk backend, dan PHPUnit sebagai kerangka kerja untuk pengujian unit. Ke depan, saya akan mengatakan bahwa semua tes backend kami ditulis berdasarkan kerangka kerja ini.

Tes unit yang paling sering kita bahas adalah beberapa kode kecil yang terisolasi, periksa kinerja metode atau fungsi, yaitu, kita berbicara tentang unit kecil logika bisnis. Tes unit kami tidak boleh berinteraksi dengan apa pun, mengakses database atau layanan.

Softmock


Kesulitan utama yang dihadapi pengembang saat menulis tes unit adalah kode yang tidak dapat diuji, dan ini biasanya kode warisan.

Contoh sederhana. Badoo berusia 12 tahun, dulu startup yang sangat kecil, yang dikembangkan oleh beberapa orang. Startup cukup sukses ada tanpa tes sama sekali. Kemudian kami menjadi cukup besar dan menyadari bahwa Anda tidak dapat hidup tanpa tes. Tetapi pada saat ini banyak kode telah ditulis yang berfungsi. Jangan menulis ulang hanya untuk kepentingan pengujian! Itu tidak masuk akal dari sudut pandang bisnis.

Oleh karena itu, kami mengembangkan pustaka sumber terbuka kecil SoftMocks , yang membuat proses penulisan tes kami lebih murah dan lebih cepat. Ini memotong semua termasuk / memerlukan file PHP dan on-the-fly menggantikan file sumber dengan konten yang dimodifikasi, yaitu kode yang ditulis ulang. Ini memungkinkan kami membuat stubs untuk kode apa pun. Ini merinci bagaimana fungsi perpustakaan.

Ini seperti apa yang terlihat bagi pengembang:

//mock  \Badoo\SoftMocks::redefineConstant($constantName, $newValue); //mock  : , ,  \Badoo\SoftMocks::redefineMethod( $class, $method, $method_args, $fake_code ); //mock  \Badoo\SoftMocks::redefineFunction( $function, $function_args, $fake_code );

Dengan bantuan konstruksi sederhana seperti itu, kita dapat mendefinisikan kembali secara global semua yang kita inginkan. Secara khusus, mereka memungkinkan kita untuk menghindari keterbatasan pembuat standar PHPUnit. Artinya, kita dapat mengejek metode statis dan pribadi, mendefinisikan ulang konstanta dan melakukan lebih banyak lagi, yang tidak mungkin dilakukan di PHPUnit biasa.

Namun, kami mengalami masalah: tampaknya bagi pengembang bahwa jika ada SoftMock, tidak perlu menulis kode yang diuji - Anda selalu dapat "menyisir" kode dengan global mock kami dan semuanya akan bekerja dengan baik. Tetapi pendekatan ini mengarah pada kode yang lebih kompleks dan akumulasi "kruk." Karena itu, kami mengadopsi beberapa aturan yang memungkinkan kami menjaga situasi tetap terkendali:

  1. Semua kode baru harus mudah diuji dengan mengolok-olok PHPUnit standar. Jika kondisi ini terpenuhi, maka kodenya dapat diuji dan Anda dapat dengan mudah memilih bagian kecil dan mengujinya saja.
  2. Diperbolehkan untuk menggunakan SoftMock dengan kode lama yang ditulis dengan cara yang tidak cocok untuk pengujian unit, serta dalam kasus di mana terlalu mahal / panjang / sulit untuk dilakukan sebaliknya (tekankan yang diperlukan).

Kepatuhan terhadap aturan-aturan ini dipantau dengan cermat pada tahap tinjauan kode.

Pengujian Mutasi


Secara terpisah, saya ingin mengatakan tentang kualitas unit test. Saya pikir banyak dari Anda menggunakan metrik seperti cakupan kode. Tetapi dia, sayangnya, tidak menjawab satu pertanyaan: "Sudahkah saya menulis unit test yang bagus?" Ada kemungkinan bahwa Anda menulis tes seperti itu, yang sebenarnya tidak memeriksa apa pun, tidak mengandung pernyataan tunggal, tetapi menghasilkan cakupan kode yang sangat baik. Tentu saja, contohnya dilebih-lebihkan, tetapi situasinya tidak begitu jauh dari kenyataan.

Baru-baru ini, kami mulai memperkenalkan pengujian mutasi. Ini adalah konsep yang agak lama, tetapi tidak terlalu terkenal. Algoritma untuk pengujian semacam itu cukup sederhana:

  • ambil kode dan cakupan kode;
  • parsim dan mulai mengubah kode: true ke false,> ke> =, + to - (secara umum, membahayakan dalam segala hal);
  • untuk setiap perubahan mutasi tersebut, jalankan suite tes yang mencakup string yang diubah;
  • jika tes jatuh, maka itu bagus dan benar-benar tidak memungkinkan kita untuk memecahkan kode;
  • jika tes telah lulus, kemungkinan besar, tes tersebut tidak cukup efektif, terlepas dari cakupan, dan mungkin perlu untuk melihatnya lebih dekat, untuk memberikan beberapa penegasan (atau ada area yang tidak dicakup oleh tes).

Ada beberapa kerangka kerja yang sudah jadi untuk PHP, seperti Humbug dan Infection. Sayangnya, mereka tidak cocok untuk kita, karena mereka tidak kompatibel dengan SoftMocks. Oleh karena itu, kami menulis utilitas konsol kecil kami sendiri, yang melakukan hal yang sama, tetapi menggunakan format cakupan kode internal kami dan berteman dengan SoftMocks. Sekarang pengembang memulai secara manual dan menganalisis tes yang ditulis olehnya, tetapi kami sedang berupaya memperkenalkan alat ke dalam proses pengembangan kami.

Pengujian integrasi


Dengan bantuan tes integrasi, kami memeriksa interaksi dengan berbagai layanan dan basis data.

Untuk lebih memahami ceritanya, mari kembangkan promo fiksi dan tutupi dengan tes. Bayangkan bahwa manajer produk kami memutuskan untuk mendistribusikan tiket konferensi ke pengguna kami yang paling berdedikasi:


Promo harus ditampilkan jika:

  • pengguna di bidang "Kerja" menunjukkan "programmer",
  • pengguna berpartisipasi dalam uji A / B HL18_promo,
  • Pengguna terdaftar lebih dari dua tahun lalu.

Dengan mengklik tombol "Dapatkan Tiket", kita harus menyimpan data pengguna ini ke beberapa daftar untuk mentransfernya ke manajer kami yang mendistribusikan tiket.

Bahkan dalam contoh yang agak sederhana ini, ada hal yang tidak dapat diverifikasi menggunakan tes unit - interaksi dengan database. Untuk melakukan ini, kita perlu menggunakan tes integrasi.

Pertimbangkan cara standar untuk menguji interaksi basis data yang ditawarkan oleh PHPUnit:

  1. Naikkan database uji.
  2. Kami menyiapkan DataTables dan Kumpulan Data.
  3. Jalankan tes.
  4. Kami menghapus database pengujian.

Kesulitan apa yang ada dalam menunggu dengan pendekatan seperti itu?

  • Anda perlu mendukung struktur DataTables dan DataSets. Jika kami mengubah tata letak tabel, maka perlu untuk mencerminkan perubahan ini dalam pengujian, yang tidak selalu nyaman dan membutuhkan waktu tambahan.
  • Butuh waktu untuk menyiapkan database. Setiap kali mengatur tes, kita perlu mengunggah sesuatu di sana, membuat beberapa tabel, dan ini lama dan menyusahkan jika ada banyak tes.
  • Dan kelemahan terpenting: menjalankan tes-tes ini secara paralel membuatnya tidak stabil. Kami mulai ujian A, ia mulai menulis ke meja tes, yang ia buat. Pada saat yang sama, kami meluncurkan tes B, yang ingin bekerja dengan tabel tes yang sama. Akibatnya, penyumbatan timbal balik dan situasi tak terduga lainnya muncul.

Untuk menghindari masalah ini, kami mengembangkan DBMocks perpustakaan kecil kami sendiri.

DBMocks


Prinsip operasi adalah sebagai berikut:

  1. Dengan bantuan SoftMocks, kami mencegat semua pembungkus yang digunakan untuk bekerja dengan basis data.
  2. Kapan
    kueri melewati mock, parse query SQL dan tarik DB + TableName darinya, dan dapatkan host dari koneksi.
  3. Pada host yang sama di tmpfs kami membuat tabel sementara dengan struktur yang sama dengan yang asli (kami menyalin struktur menggunakan SHOW CREATE TABLE).
  4. Setelah itu, kami akan mengalihkan semua permintaan yang akan datang melalui tiruan ke tabel ini ke yang sementara yang baru dibuat.

Apa artinya ini bagi kita:

  • tidak perlu terus merawat struktur;
  • tes tidak lagi dapat merusak data dalam tabel sumber, karena kami mengarahkan mereka ke tabel sementara dengan cepat;
  • kami masih menguji kompatibilitas dengan versi MySQL yang sedang kami tangani, dan jika permintaan tiba-tiba tidak lagi kompatibel dengan versi baru, maka pengujian kami akan melihat dan menghentikannya.
  • dan yang paling penting, tes sekarang terisolasi, dan bahkan jika Anda menjalankannya secara paralel, utas akan menyebar ke tabel sementara yang berbeda, karena kami menambahkan kunci unik untuk setiap tes dalam nama-nama tabel uji.

Pengujian API


Perbedaan antara tes unit dan API diilustrasikan dengan baik oleh GIF ini:


Kunci berfungsi dengan baik, tetapi terpasang pada pintu yang salah.

Pengujian kami mensimulasikan sesi klien, dapat mengirim permintaan ke backend, mengikuti protokol kami, dan backend meresponsnya sebagai klien nyata.

Uji Kelompok Pengguna


Apa yang kita butuhkan untuk berhasil menulis tes seperti itu? Mari kita kembali ke kondisi acara promo kami:

  • pengguna di bidang "Kerja" menunjukkan "programmer",
  • pengguna berpartisipasi dalam uji A / B HL18_promo,
  • Pengguna terdaftar lebih dari dua tahun lalu.

Ternyata, di sini semuanya tentang pengguna. Dan pada kenyataannya, 99% dari pengujian API memerlukan pengguna terdaftar yang sah, yang hadir di semua layanan dan basis data.

Di mana mendapatkannya? Anda dapat mencoba mendaftarkannya pada saat pengujian, tetapi:

  • panjang dan memakan sumber daya;
  • setelah menyelesaikan tes, pengguna ini harus dihapus entah bagaimana, yang merupakan tugas yang tidak sepele jika kita berbicara tentang proyek besar;
  • akhirnya, seperti dalam banyak proyek sangat sarat lainnya, kami melakukan banyak operasi di latar belakang (menambahkan pengguna ke berbagai layanan, replikasi ke pusat data lain, dll.); tes tidak tahu apa-apa tentang proses seperti itu, tetapi jika mereka secara implisit mengandalkan hasil eksekusi mereka, ada risiko ketidakstabilan.


Kami mengembangkan alat yang disebut Test Users Pool. Ini didasarkan pada dua ide:

  1. Kami tidak mendaftarkan pengguna setiap saat, tetapi menggunakannya berkali-kali.
  2. Setelah pengujian, kami mereset data pengguna ke keadaan semula (pada saat pendaftaran). Jika ini tidak dilakukan, tes akan menjadi tidak stabil dari waktu ke waktu, karena pengguna akan "dicemari" dengan informasi dari tes lain.


Ini berfungsi seperti ini:



Pada titik tertentu, kami ingin menjalankan pengujian API kami di lingkungan produksi. Mengapa kita menginginkan ini? Karena infrastruktur pembangunan tidak sama dengan produksi.

Meskipun kami berusaha untuk terus mengulangi infrastruktur produksi pada ukuran yang dikurangi, devel tidak akan pernah menjadi salinan penuh dari itu. Untuk benar-benar yakin bahwa bangunan baru memenuhi harapan dan tidak ada masalah, kami mengunggah kode baru ke klaster praproduksi, yang berfungsi dengan data dan layanan produksi, dan menjalankan pengujian API kami di sana.

Dalam hal ini, sangat penting untuk memikirkan bagaimana mengisolasi pengguna uji dari yang asli.

Apa yang akan terjadi jika pengguna uji mulai terlihat nyata di aplikasi kita.


Bagaimana cara mengisolasi? Setiap pengguna kami memiliki bendera is_test_user . Pada tahap pendaftaran, itu menjadi yes atau no , dan tidak ada perubahan lagi. Dengan tanda ini, kami mengisolasi pengguna di semua layanan. Penting juga bahwa kami mengecualikan pengguna pengujian dari analisis bisnis dan hasil pengujian A / B agar tidak mengubah statistik.

Anda dapat pergi dengan cara yang lebih sederhana: kami mulai dengan fakta bahwa semua pengguna tes "dipindahkan" ke Antartika. Jika Anda memiliki layanan geoservice, ini adalah cara yang sepenuhnya berfungsi.

API QA


Kami tidak hanya membutuhkan pengguna - kami membutuhkannya dengan parameter tertentu: untuk bekerja sebagai programmer, berpartisipasi dalam tes A / B tertentu dan telah terdaftar lebih dari dua tahun yang lalu. Untuk pengguna tes, kami dapat dengan mudah menetapkan profesi menggunakan API backend kami, tetapi masuk ke tes A / B adalah probabilistik. Dan kondisi registrasi lebih dari dua tahun lalu umumnya sulit dipenuhi, karena kita tidak tahu kapan pengguna muncul di pool.

Untuk mengatasi masalah ini, kami memiliki QA API. Faktanya, ini adalah pintu belakang untuk pengujian, yang merupakan metode API yang terdokumentasi dengan baik yang memungkinkan Anda mengelola data pengguna dengan cepat dan mudah dan mengubah status mereka dengan melewati protokol utama komunikasi kami dengan klien. Metode ini ditulis oleh pengembang backend untuk insinyur QA dan untuk digunakan dalam pengujian UI dan API.

QA API hanya dapat diterapkan dalam kasus pengguna tes: jika tidak ada tanda yang sesuai, tes akan segera jatuh. Berikut adalah salah satu metode QA API kami yang memungkinkan Anda untuk mengubah tanggal pendaftaran pengguna menjadi yang sewenang-wenang:



Sehingga akan terlihat seperti tiga panggilan yang akan memungkinkan Anda untuk dengan cepat mengubah data pengguna uji sehingga memenuhi kondisi tampilan promo:

  • Di bidang "Kerja", "programmer" ditunjukkan:
    addUserWorkEducation?user_id=ID&works[]=Badoo,

  • Pengguna berpartisipasi dalam uji A / B HL18_promo:
    forceSplitTest?user_id=ID&test=HL18_promo
  • Terdaftar lebih dari dua tahun yang lalu:
    userCreatedChange?user_id=ID&created=2016-09-01


Karena ini adalah pintu belakang, sangat penting untuk memikirkan keamanan. Kami melindungi layanan kami dengan beberapa cara:

  • terisolasi di tingkat jaringan: layanan hanya dapat diakses dari jaringan kantor;
  • dengan setiap permintaan kami memberikan rahasia, yang tanpanya mustahil untuk mengakses QA API bahkan dari jaringan kantor;
  • metode hanya bekerja dengan pengguna uji.


Remotemock


Untuk bekerja dengan backend remote tes API, kita mungkin perlu mengejek. Untuk apa? Misalnya, jika uji API di lingkungan produksi mulai mengakses database, kita perlu memastikan bahwa data di dalamnya dibersihkan dari data uji. Selain itu, mengejek membantu membuat respons pengujian lebih cocok untuk pengujian.

Kami memiliki tiga teks:



Badoo adalah aplikasi multibahasa, kami memiliki komponen pelokalan yang kompleks yang memungkinkan Anda menerjemahkan dan menerima terjemahan dengan cepat untuk lokasi pengguna saat ini. Pelokalan kami terus bekerja untuk meningkatkan terjemahan, melakukan tes A / B dengan token, dan mencari formulasi yang lebih sukses. Dan, saat melakukan tes, kita tidak bisa tahu teks mana yang akan dikembalikan oleh server - itu dapat berubah kapan saja. Tetapi kita dapat menggunakan RemoteMocks untuk memeriksa apakah komponen lokalisasi diakses dengan benar.

Bagaimana cara kerja RemoteMock? Tes meminta backend untuk menginisialisasi mereka untuk sesi, dan setelah menerima semua permintaan selanjutnya backend memeriksa untuk mengejek untuk sesi saat ini. Jika ya, itu hanya menginisialisasi mereka menggunakan SoftMocks.

Jika kita ingin membuat mock jarak jauh, kita mengindikasikan kelas atau metode mana yang perlu diganti dan dengan apa. Semua permintaan backend berikutnya akan dieksekusi dengan mempertimbangkan tiruan ini:

 $this->remoteInterceptMethod( \Promo\HighLoadConference::class, 'saveUserEmailToDb', true );

Nah, sekarang mari kita kumpulkan uji API kami:

 //       $app_startup = [ 'supported_promo_blocks' => [\Mobile\Proto\Enum\PromoBlockType::GENERIC_PROMO] ]; $Client = $this->getLoginedConnection(BmaFunctionalConfig::USER_TYPE_NEW, $app_startup); //  $Client->getQaApiClient()->addUserWorkEducation(['Badoo, ']); $Client->getQaApiClient()->forceSplitTest('HL18_promo'); $Client->getQaApiClient()->userCreatedChange('2016-09-01'); //     $this->remoteInterceptMethod(\Promo\HighLoadConference::class, 'saveUserEmail', true); //,   ,   $Resp = $Client->ServerGetPromoBlocks([]); $this->assertTrue($Resp->hasMessageType('CLIENT_NEXT_PROMO_BLOCKS')); $PromoBlock = $Resp->CLIENT_NEXT_PROMO_BLOCKS; … //   CTA, ,   ,   $Resp = $Client->ServerPromoAccepted($PromoBlock->getPromoId()); $this->assertTrue($Resp->hasMessageType('CLIENT_ACKNOWLEDGE_COMMAND'));


Sedemikian sederhananya, kami dapat menguji fungsionalitas apa pun yang muncul untuk pengembangan di backend dan membutuhkan perubahan dalam protokol seluler.

Aturan Penggunaan Uji API


Segalanya tampak baik-baik saja, tetapi kami kembali menemui masalah: tes API ternyata terlalu nyaman untuk pengembangan dan ada godaan untuk menggunakannya di mana-mana. Akibatnya, setelah kami menyadari bahwa kami mulai menyelesaikan masalah dengan bantuan tes API yang tidak dimaksudkan.

Kenapa ini buruk? Karena tes API sangat lambat. Mereka masuk jaringan, beralih ke backend, yang mengambil sesi, pergi ke database dan banyak layanan. Oleh karena itu, kami mengembangkan seperangkat aturan untuk menggunakan tes API:
  • Tujuan pengujian API adalah untuk memeriksa protokol interaksi antara klien dan server, serta integrasi yang benar dari kode baru

  • diperbolehkan untuk mencakup proses yang rumit dengan mereka, misalnya, rantai tindakan;
  • mereka tidak dapat digunakan untuk menguji variabilitas kecil dari respons server - ini adalah tugas unit test;
  • selama tinjauan kode, kami memeriksa termasuk tes.

Tes UI


Karena kami sedang mempertimbangkan piramida otomatisasi, saya akan memberi tahu Anda sedikit tentang tes UI.

Pengembang backend di Badoo tidak menulis tes UI - untuk ini kami memiliki tim khusus di departemen QA. Kami membahas fitur dengan tes UI ketika sudah diingat dan distabilkan, karena kami percaya bahwa tidak masuk akal untuk menghabiskan sumber daya pada otomatisasi fitur yang agak mahal, yang, mungkin, tidak akan melampaui uji A / B.

Kami menggunakan Calabash untuk uji otomatis seluler, dan Selenium untuk web. Ini berbicara tentang platform kami untuk otomatisasi dan pengujian.

Uji coba


Kami sekarang memiliki 100.000 unit test, 6.000 - tes integrasi dan 14.000 tes API. Jika Anda mencoba menjalankannya dalam satu utas, maka bahkan pada mesin kami yang paling kuat, proses penuh semua akan memakan waktu: modular - 40 menit, integrasi - 90 menit, tes API - sepuluh jam. Itu terlalu panjang.

Paralelisasi


Kami berbicara tentang pengalaman kami dalam memparalelkan tes unit dalam artikel ini .

Solusi pertama, yang tampaknya jelas, adalah menjalankan tes di banyak utas. Tapi kami melangkah lebih jauh dan membuat cloud untuk peluncuran paralel untuk dapat mengukur sumber daya perangkat keras. Sederhana, karyanya terlihat seperti ini:



Tugas yang paling menarik di sini adalah distribusi tes antara utas, yaitu, pemecahannya menjadi potongan-potongan.

Anda dapat membaginya secara merata, tetapi semua tes berbeda, sehingga mungkin ada bias yang kuat dalam waktu pelaksanaan utas: semua utas telah mencapai, dan satu untai selama setengah jam, karena "beruntung" dengan tes yang sangat lambat.

Anda dapat memulai beberapa utas dan mengumpankannya satu per satu. Dalam hal ini, kekurangannya kurang jelas: ada biaya overhead untuk menginisialisasi lingkungan, yang, dengan sejumlah besar tes dan pendekatan ini, mulai memainkan peran penting.

Apa yang telah kita lakukan Kami mulai mengumpulkan statistik pada waktu yang dibutuhkan untuk menjalankan setiap tes, dan kemudian mulai menyusun potongan sedemikian rupa sehingga, menurut statistik, satu utas akan berjalan tidak lebih dari 30 detik. Pada saat yang sama, kami mengemas tes cukup erat dalam potongan untuk membuatnya lebih kecil.

Namun, pendekatan kami juga memiliki kelemahan. Itu terkait dengan tes API: mereka sangat lambat dan menghabiskan banyak sumber daya, mencegah tes cepat dari dieksekusi.

Oleh karena itu, kami membagi cloud menjadi dua bagian: pertama, hanya tes cepat yang diluncurkan, dan yang kedua, baik cepat dan lambat dapat diluncurkan. Dengan pendekatan ini, kami selalu memiliki bagian dari cloud yang dapat menangani tes cepat.



Akibatnya, tes unit mulai berjalan dalam satu menit, tes integrasi dalam lima menit, dan tes API dalam 15 menit. Artinya, lari penuh alih-alih 12 jam tidak lebih dari 22 menit.

Menjalankan uji cakupan kode


Kami memiliki monolit kompleks yang besar, dan, dengan cara yang baik, kami harus terus menjalankan semua tes, karena perubahan di satu tempat dapat merusak sesuatu di tempat lain. Ini adalah salah satu kelemahan utama arsitektur monolitik.

Pada titik tertentu, kami sampai pada kesimpulan bahwa Anda tidak perlu menjalankan semua tes setiap saat - Anda dapat membuat proses berdasarkan cakupan kode:

  1. Ambil beda cabang kami.
  2. Kami membuat daftar file yang dimodifikasi.
  3. Untuk setiap file kami mendapatkan daftar tes,
    yang menutupinya.
  4. Dari tes ini kami membuat satu set dan menjalankannya di cloud uji.

Di mana mendapatkan liputan? Kami mengumpulkan data sekali sehari ketika infrastruktur lingkungan pengembangan idle. Jumlah tes yang dijalankan menurun tajam, kecepatan menerima umpan balik dari mereka, sebaliknya, telah meningkat secara signifikan. Untung!

Bonus tambahan adalah kemampuan untuk menjalankan tes untuk tambalan. Terlepas dari kenyataan bahwa Badoo belum menjadi startup untuk waktu yang lama, kami masih dapat dengan cepat mengimplementasikan perubahan dalam produksi, dengan cepat menuangkan hot fix, meluncurkan fitur, dan mengubah konfigurasi. Sebagai aturan, kecepatan meluncurkan patch sangat penting bagi kami. , .

. , , , . . , code coverage . , , — , - , . .

API-, code coverage. , , . - , API- .

Kesimpulan


  • , . - , , - .
  • ≠ . code review , .
  • , , . .
  • . .
  • , ! , .


, Badoo PHP Meetup 16 . PHP-. , . ! 12:00, — YouTube- .

Source: https://habr.com/ru/post/id443768/

More articles:


All Articles