Halo semuanya, nama saya Yaroslav Astafiev, dan hari ini saya ingin melakukan tur berpemandu dalam menguji ReactJS. Saya tidak akan menyelidiki kompleksitas pengujian aplikasi web menggunakan perpustakaan tertentu (dipandu oleh pendekatan "sulit untuk menguji hanya kode buruk"), sebagai imbalannya saya akan mencoba untuk mendiversifikasi cakrawala Anda. Jadi dalam artikel ini, React lebih merupakan kesempatan untuk mengumpulkan pendekatan pengujian, titik awal yang menggabungkan hipsters dan teknologi. Akan lebih benar untuk bahkan mengatakan bahwa kita akan berbicara tentang prinsip-prinsip pengujian secara umum dengan ilustrasi tentang ReactJS (dan tidak hanya).
Jika Anda menganggap diri Anda seorang guru pengujian -
lewati bagian pertama artikel , ini tentang prinsip dasar pengujian. Jika bagian kedua tidak mengungkapkan sesuatu yang baru untuk Anda, datanglah kepada kami untuk bekerja dan mengajarkan caranya.
Jika pendahuluan tidak menyebabkan serangan sinestesia, selamat datang di kucing.
Tes unit
Unit Jest adalah perpustakaan untuk menguji JavaScript. Jangan suka ini - ambil yang
lain , tapi kemudian
Ava lebih baik. Semuanya sederhana di sini: klik tombol ajaib dan pastikan bahwa nilai tertentu dari "0" telah berubah menjadi "1":
import React from "react" import { MyButton } from "../src/components/dummy/myButton" import renderer from "react-test-renderer" test("MyButton has onPress fn", () => { let x = 0 const instance = renderer .create(<MyButton onPress={() => x++} />) .getInstance() expect(instance.handlePress).toBeDefined() expect(x).toBe(0) instance.props.handlePress() expect(x).toBe(1) })
Sekarang Anda memiliki semua keterampilan yang diperlukan untuk menguji tombol ajaib. Sayangnya, keterampilan ini tidak terkait dengan kehidupan nyata. Komponen Bereaksi tidak dapat terisolasi dengan baik, dan isolasi adalah salah satu prinsip utama pengujian unit. Entah bagaimana, perlu untuk menghapus semua komponen yang entah bagaimana berpartisipasi dalam metode render, kecuali yang diuji. Dan ada solusinya: orang pintar datang dengan mockAPI untuk ini.
Inti dari Mock sederhana: semua yang bukan milik kita adalah
Mock / Stub / Fake / Dummy / Spy dll. Kami "meniru" cara kami membutuhkan perilaku nyata dari suatu komponen, yang dapat memiliki logika yang kompleks, pada data uji yang disiapkan sebelumnya dan membawanya dengan keyakinan bahwa semua komponen yang ditiru bekerja dengan sempurna jika parameter yang benar dimasukkan ke dalamnya.
Ada pustaka
jest-fetch-mock untuk
jest , di dalamnya Anda dapat mendefinisikan moki secara global. Jika Anda tidak menyukai opsi ini, Anda dapat "membasahi" setiap komponen yang Anda butuhkan dalam pengujian secara terpisah.
Fungsi murni pada input yang sama selalu mengembalikan jawaban yang sama. Oleh karena itu, jika dalam logika bisnis kita komponen memiliki fungsi / komponen “tidak bersih”, maka dalam pengujian unit mereka juga perlu “dibersihkan” (tetapi untuk pengujian unit aturan ini tidak selalu benar). Contoh klasik adalah komponen reaksi yang menampilkan tanggal dan waktu saat ini dalam format yang Anda butuhkan, tanggal akan berbeda setiap kali Anda menjalankan tes, dan Anda tidak akan bisa menulis tes unit yang benar. Untuk semua yang tidak setuju, Anda dapat menyulitkan contoh di mana komponen Anda harus menampilkan tanggal dalam format relatif dan menyoroti tanggal yang lebih tua dari satu
tahun dari tanggal
saat ini dengan warna merah.
Dengan demikian, jika Anda memiliki hal-hal dinamis yang bergantung pada waktu / cuaca / tekanan, maka mock akan mendefinisikan ulang panggilan yang Anda butuhkan sehingga tidak ada ketergantungan pada faktor pihak ketiga. Dengan demikian, Anda tidak perlu menunggu
pada tanggal 29 Februari untuk mendapatkan tes jatuh.
Aturan Uji Unit
Masalah yang dijelaskan di atas dan metode untuk menyelesaikannya adalah upaya pendekatan informal untuk pengujian: setiap tes berjalan seperti yang diinginkan. Menurut pendapat saya, kepatuhan terhadap
tiga aturan penting pengujian unit sudah cukup:
- Determinisme
- Isolasi
- Bebas dari faktor eksternal
- Akal sehat
Aturan satu: semua tes harus deterministik. Jika saya menulis tes pada Windows, maka pada Mac itu juga harus memulai dan menghasilkan hasil yang sama. Pengembang Windows senang lupa bahwa nama file pada sistem * nix peka terhadap huruf besar-kecil. Dan Anda beruntung jika
tes berada dalam kerangka CI, dan bukan aplikasi dalam produksi .
Aturan selanjutnya adalah isolasi. Kami membasahi semua komponen yang tidak diuji. Jika ini sulit dilakukan, maka sudah waktunya untuk refactor.
Last but not least: jika ada data yang diterima aplikasi Anda dalam runtime, mereka juga harus dipaku. Ini bisa berupa lokal, ukuran jendela, format tanggal, format angka titik mengambang, dll.
Tes integrasi
Kapan mulai menulis tes integrasi , menurut pendapat saya, adalah pertanyaan terbuka, dan di setiap tim / produk individu keputusan harus dibuat dengan mempertimbangkan faktor internal.
Anda dapat mengambil pendekatan formal: mencapai cakupan
unit tes 80% (tes tertulis yang buruk tidak boleh ditinjau / memerlukan kode baru atau yang diubah untuk dicakup oleh tes), kemudian melakukan audit penuh dan refactoring semua tes tertulis dengan analisis kesalahan khas, memformalkan aturan internal untuk menulis tes dan melakukan penggerebekan seperti itu per tahun. Jika setelah semua tindakan yang dijelaskan di atas unit Anda, cakupan kode tes masih 80% +, maka Anda memiliki tim yang matang, atau Anda sama sekali tidak kritis terhadap kode / tes Anda. Jika cakupan kode menjadi kurang, maka Anda perlu mencapai cakupan 80% lagi dan melanjutkan untuk menulis tes integrasi. Anda dapat tampil kurang formal dan hanya dipandu oleh akal sehat: misalnya, untuk setiap bug yang telah diputar n kali, menulis tes atau membuat sesuatu yang lain, misalnya, melemparkan koin.
Pertanyaan terbuka kedua:
tes apa yang dianggap integrasi ? Mungkin tidak dijawab.
Dalam tes integrasi, kami menguji pekerjaan tidak satu komponen, tetapi beberapa komponen dalam banyak. Tidak ada aturan, tetapi akal sehat memberi tahu Anda:
- Jangan menguji bagaimana itu diberikan, di mana ia dipanggil, dan kapan semuanya akan berakhir;
- Jangan menguji pekerjaan ReactJS, jika tidak berhasil, tidak ada yang akan membantu Anda;
- Jangan menguji bagaimana mesin negara Bereaksi bekerja;
- uji logika bisnis / model data / situasi batas / sesuatu yang sering rusak.
Dalam tes semacam itu, Anda tidak harus memerinci. Mereka berjalan jauh lebih lama dan juga lebih sulit untuk menulisnya, jadi Anda tidak boleh terbawa dan membahas setiap kasus kecil dalam logika aplikasi. Ini mahal dalam hal penyewaan infrastruktur, dan lama dalam hal pengembangan dan waktu pelaksanaan skrip. Seseorang akan menghabiskan hidup mereka pada rutin ini, dan
manajer pengguna akan sedih , dan menunggu fitur baru, dan ...
Alasan lain mengapa Anda tidak boleh mencoba semuanya adalah Keamanan Palsu (Saya telah mencoba untuk menulis poin paling penting di atas). Setiap tim harus membaca tentang kesalahan jenis pertama dan kedua, lemma Neumann-Pearson dan menilai risiko mereka dalam hal uang, burung beo atau ukuran kebenaran lainnya yang diterima dalam tim.
Tetapi ada pengecualian untuk aturan ini, serta yang lainnya.
Lupakan semua yang dikatakan di atas :
- Saat menguji dependensi dinamis. Ketika Anda tidak tahu komponen mana yang akan runtuh, Anda merendernya, tetapi itu mungkin tidak datang. Anda juga perlu menulis tes untuk ini, tidak ada yang membatalkan sirkuit bracker. Entah komponen yang salah yang Anda harapkan, atau komponen yang rusak akan datang. Oleh karena itu, dalam hal ini, kami menulis tes integrasi dan render. Kami memeriksa apakah semuanya berfungsi, jika tidak ada yang jatuh.
- Dengan pixel sempurna (well, Anda mengerti), pengembangan harus membuat dan membedakan tangkapan layar, dan setiap kali perpustakaan komponen diperbarui ke versi baru - perbarui tangkapan layar referensi. Karena lebih mudah
untuk merekrut desainer baru untuk direkonsiliasi daripada memperbaikinya.
Tes foto
Tes integrasi paling sederhana adalah snapshot:
- Kami mengambil komponen, merendernya
- Di render kita menulis console.log (ini)
- Salin data referensi dari konsol
- Bandingkan
Jika Anda ingin sedikit bingung, maka saya menyarankan Anda untuk bermain-main dengan perpustakaan
StoryBook . Ini adalah perpustakaan untuk tes snapshot, yang secara tidak sengaja membungkus ide
StyleGuidist - membuat sistem desain Anda sendiri berdasarkan komponen Bereaksi.
Aturan pertama dari tes snapshot:
jangan pernah katakan, cobalah untuk menguji data . Mereka harus selalu statis, "terkunci" dan independen. Aturan kedua:
tes snapshot yang rusak tidak berarti semuanya buruk . Jika dia merah - bukan fakta bahwa semuanya berjalan. Ada banyak opsi untuk membuat tata letak yang sama, tetapi pohon DOM berbeda. Jadi kami mengabaikan spasi, atribut, kunci, atau kami tidak menguji apa yang membutuhkan begitu banyak waktu dukungan. Atau kita tandai dengan tangan kita apa yang rusak, apa yang tidak. Kami memperbaiki tes yang rusak dan memulai kembali StoryBook dalam mode pembaruan tiruan - mode di mana tes akan membuat komponen dan memasukkan Snapshot sebagai nilai referensi dalam kondisi yang diharapkan.
xState dan React Automata
ReactJS adalah hal yang sulit. Tampaknya perpustakaan itu keren. Saya membuat tiga komponen - sebuah kelas: dan mesin negara sepertinya berfungsi dan kodenya indah. Kemudian Anda menulis di ReactJS selama enam bulan, Anda melihat kode - semacam omong kosong. Anda tidak mengerti di mana kruk, di mana rute, di mana keadaan, di mana cache ... Lalu Anda berpikir: baik, saya akan melakukan seperti yang disarankan Facebook: Saya akan memasang "hokeys", "hooks", sesuatu yang lain dan tiba-tiba melihat diri Anda berpikir bagaimana Anda melakukannya. ru dalam upaya untuk menemukan proyek dengan pengembangan pada reaksi dari awal, sehingga pasti
akan melakukan semuanya dengan indah ...
Semuanya sangat rumit sehingga umumnya mustahil untuk memahami cara kerjanya. Dan itu bekerja sampai seseorang mengeluh. Kami memperbaikinya - dan itu diperbaiki, tetapi rusak ... Salah satu output adalah
mesin negara, satu set negara aplikasi deterministik dan memungkinkan transisi di antara mereka. Dan, seperti yang mereka katakan dalam lingkaran sempit, Anda tidak menulis reaksi jika Anda tidak menghancurkan mesin negara Anda.
Perlu mengingat
xState . Ini adalah mesin keadaan deterministik untuk JavaScript.
Anda dapat membuat UI yang sangat keren di
xState - tautan ke laporan terkait dapat ditemukan dalam dokumentasi perpustakaan
React Automata . Pada gilirannya, React Automata adalah perpustakaan di mana xState diadaptasi dalam ReactJS. Selain itu, ia dapat
membuat tes untuk kondisi mesin negara .
Jika kita memiliki centang pertama benar - lampu hijau menyala. Jika yang kedua salah, maka anjing abu-abu ditarik, dan Bereaksi Automata menghasilkan tes untuk keempat kombinasi parameter ini dan memvalidasi anjing dan umbi. Benar, pada titik tertentu Anda akan ingin mengurangi setengah dari tes, tetapi pada awalnya Anda akan sangat senang ... Dalam hal apapun, ini adalah pandangan yang nyaman pada tes Anda dari samping, itu mengingatkan saya pada gagasan pengujian dengan kekacauan deterministik.
Cypress
Dengan snapshot, kami kira-kira tahu, Anda bisa menuju ke end2end. Kami memiliki semua produk internal, sehingga solusi di tempat adalah satu-satunya pilihan kami. Saya harap Anda memiliki kesempatan untuk menggunakan solusi cloud, maka hal seperti
Cypress akan berguna.
Sebelumnya, Anda memilih kerangka kerja pengujian, mengambil perpustakaan untuk pernyataan, perpustakaan untuk membandingkan XML yang kompleks. Kemudian kami memilih driver dan browser untuk memulai semuanya. Mereka mulai dan menulis banyak tes. Semua ini memakan infrastruktur, Anda perlu memasukkan semuanya ke buruh pelabuhan, lalu mengacaukan beberapa hal yang melihat tes dalam dinamika, menganalisisnya, menunjukkan apa yang salah ...
Orang-orang Cypress melakukan semuanya untuk Anda. Mereka memecahkan beberapa masalah:
menyiapkan lingkungan kerja, menulis kode, menjalankan dan menulis tes. Jika tes rusak, Anda dapat menampilkan tangkapan layar yang menyoroti apa yang rusak. Benar, ini tidak berfungsi untuk ponsel, tetapi di sana, misalnya, adalah
Detox . Ini, tentu saja, sulit dari sudut pandang ambang masuk: Anda harus menyesuaikan aplikasi Anda untuk itu, menulis ulang banyak file, dll. Tetapi jika Anda mau, itu mungkin.
Tes lunak
Ada beberapa jenis tes alternatif yang tidak bisa disebut tes yang baik. Saya menyebutnya tes lunak. Misalnya, linter. Mereka terutama digunakan oleh front-end (dan bahkan, kadang-kadang, inspirasi turun ke javists). Ada banyak linter:
ESLint ,
JSHint ,
Prettier ,
Standard ,
Clinton . Saya menyarankan
Prettier: cepat, murah, ceria, mudah dikonfigurasi, bekerja di luar kotak .
Jika Anda ingin menjadi bingung, Anda dapat mengkonfigurasi ESLint. Biarkan saya memberi Anda sebuah contoh klasik dari sebuah plugin untuknya: ketika seorang pelanggan menemukan komentar dengan ekspresi cabul dalam kode Anda, ia biasanya bersumpah. Pengembang rumit membuat komentar dalam bahasa Rusia sehingga pelanggan tidak menebak. Tetapi pelanggan menebak ... menggunakan penerjemah Google dan menemukan segala sesuatu yang dipikirkan pengembang tentangnya. Jalan keluar dari situasi tidak menyenangkan, mungkin dengan kehilangan uang atau pelanggan. Untuk kasus ini,
Anda selalu dapat mengembangkan plugin untuk ESLint , yang menemukan kata-kata "asli Rusia" dalam kode sumber Anda dan mengatakan: "Oh, maaf, tolak komit Anda."
Keindahan linter dalam JavaScript adalah bahwa mereka
dapat dimasukkan ke dalam kait pre commit . Secara pribadi, saya tidak suka Prettier tidak menyimpan sejarah (walaupun, di sisi lain, Prettier juga tidak mengakumulasi hutang teknis). Dari sudut pandang analisis statistik kode, pengujian semacam itu sangat buruk, karena Anda tidak dapat melihat dinamika proyek, melihat berapa banyak kesalahan yang terjadi kemarin, sehari sebelum kemarin. Pada prinsipnya, masalah ini diselesaikan di
SonarQube , itu juga dalam solusi cloud. Ini adalah penganalisa kode statistik yang menyimpan sejarah proses, dapat bekerja dengan dua lusin bahasa, termasuk bahkan PHP (siapa lagi yang tidak memerlukan analisis statis? :)). Di dalamnya, Anda dapat menonton dinamika kerentanan, bug, utang teknis, dan lainnya.
Tes kompleksitas
Frontenders menggunakan
linter karena mereka menginginkan lekukan yang indah . Kompleksitas juga merupakan tes lunak yang dapat digunakan untuk memeriksa kualitas kode Anda.
Gambar menunjukkan bagaimana saya mencoba mengikuti pemikiran junior yang mengajukan permintaan. Dalam kasus seperti itu, saya sarankan menghancurkan segalanya dan membangun jalan langsung.Tes kompleksitas mengikuti prinsip yang sangat sederhana: mereka menghitung
kompleksitas siklomatik dari algoritma. Misalnya, mereka membaca suatu fungsi, menemukan 10 variabel di dalamnya. Jika 10 - mungkin sulit. Mari kita tentukan kompleksitas 1. Untuk setiap siklus kita akan memberikan 3 poin, untuk satu siklus dalam satu siklus - 9, untuk setiap siklus dalam satu siklus - 27. Kami menambahkan semuanya dan berkata: kompleksitas siklomatik 120, dan seseorang hanya dapat memahami 6. Arti dari penilaian ini adalah untuk mengatakan secara subyektif ketika Anda perlu memperbaiki kode sumber Anda, pisahkan menjadi beberapa bagian, sorot fungsi baru, dan sejenisnya. Dan ya, SonarQube juga bisa melakukannya.
Tes alternatif
Di dunia saya, tes alternatif juga berlaku untuk tes lunak.
Solidaritas adalah hal yang sangat berguna untuk orientasi. Dan tidak hanya untuk front-end, meskipun ditulis dalam JavaScript. Ini memungkinkan Anda untuk
menguji lingkungan kerja . Sebelumnya, perlu untuk menyusun instruksi besar, menunjukkan versi bahasa pemrograman, perpustakaan, daftar perangkat lunak yang diperlukan untuk hanya memulai, menjaga semuanya tetap terbaru dll. Sekarang kita dapat mengatakan ini: “Ini komputer Anda, ini kode sumbernya. Sampai
Solidaritas berlalu , jangan datang. " Pada saat yang sama, ambang entri rendah. Solidaritas dapat membuat sidik jari dari lingkungan kerja yang disesuaikan dan memungkinkan Anda untuk menambahkan aturan yang sangat sederhana untuk memvalidasi tidak hanya perangkat lunak yang diinstal. Dan itu membuat Anda marah ketika mereka datang dengan kata-kata: "Oh, maaf, ada sesuatu yang tidak berhasil bagi saya di sana, dapatkah Anda membantu?"
Kasus penggunaan kedua (ini yang utama) adalah
menguji lingkungan produksi dengan kata-kata: "Tes unit untuk CI tentu saja berlalu, tetapi konfigurasi CI dan PROD sangat bervariasi. Jadi tidak ada jaminan ... ". Tujuan perpustakaan sangat sederhana: untuk memenuhi aturan pertama integrasi berkelanjutan: "semua orang harus memiliki lingkungan yang sama." Bersih, terisolasi sehingga tidak ada efek samping, baik, atau setidaknya sehingga ada lebih sedikit dari mereka ... yang saya coba untuk menipu?
Panggilan API
Kebetulan pengembang dibagi menjadi beberapa tim - beberapa menulis frontend, yang lain menulis backend. Situasi fiktif yang tidak bisa berada di tim nyata: semuanya bekerja kemarin, dan hari ini setelah dua rilis - depan dan belakang - semuanya pecah. Siapa yang harus disalahkan? Saya, sebagai orang dengan pengalaman backend awalnya, selalu mengatakan: front-end.
Sederhana saja, mereka mengacaukan suatu tempat, seperti biasa. Pada satu titik, vendor front-end datang dan berkata: "Di sini kita membaca posting dengan
referensi , membaca panduan ini dan
belajar cara melemparkan REST API Anda . Dan Anda tidak akan percaya itu telah berubah ... " Secara umum, jika backend Anda bukan teman Swagger, openAPI, atau solusi serupa lainnya - ada baiknya mencatat.
Kinerja js
Dan akhirnya, tes kinerja JS.
Tidak ada yang menguji kinerja JS kecuali pembuat browser. Sebagai aturan, mereka semua menggunakan
Benchmark.js . "Oh, dan kami telah mengasah Explorer kami selama 18 tahun sehingga menampilkan satu miliar tablet lebih cepat daripada di Chrome." Siapa yang butuh tablet seperti itu?
Jika Anda ingin melakukan tes kinerja, lebih baik lanjut dengan cara lain: uji end-to-end dan perhatikan cara kerjanya. Pengguna membentuk persepsi tentang bagaimana aplikasi bekerja secara keseluruhan,
pengguna tidak peduli bahwa ini adalah masalah di sisi backend.Kisah perang # 1
Sekarang contoh dari kehidupan. Entah bagaimana bos datang kepada kami dan berkata: "Front Anda bekerja sangat buruk, hampir tidak memuat. Sesuatu harus dilakukan dengan pertunjukan, orang-orang mengeluh. " Kami pikir: sekarang kita akan memiliki dua minggu untuk melakukan tuning, mengambil log
mengapa Anda memperbarui , memilih pohon bergetar, memotong semuanya menjadi potongan dengan memuat dinamis ... Bagaimana jika itu tidak terbakar, maka kita akan memecah semuanya atau hanya memperburuknya? Solusi alternatif perlu dibuat.
Kami membuka browser, lihat: 7,5 MB, 2 detik, semuanya baik-baik saja.
Masukkan Nginx GZip:
Nginx memiliki kemampuan untuk menyesuaikan rasio kompresi, mari kita coba:
Pertumbuhan - 25% dari produktivitas. Berhenti lebih awal. Lihatlah logo desainer kecil di sudut. Itu tetap sangat indah, bahkan jika itu diregangkan, tetapi mengapa kita membutuhkannya?
Inilah yang Anda dapatkan setelah mengoptimalkan satu gambar. Anda dapat mengevaluasi sendiri berat logo. Akhirnya, kami mendatangi pelanggan dan berkata: “unduhan pertama tidak sepenting yang kedua. Dan, aktifkan caching paksa:
... Semua orang senang, semua orang gembira! " Kecuali untuk pengguna, tentu saja.
Akibatnya, kami memutuskan untuk melakukan audit ukuran lebih sering.
Gzip, font, gambar, gaya - tempat-tempat yang jarang dilihat orang, tetapi ada banyak manfaatnya.
Madge dan updtrJS
Langkah selanjutnya:
audit ketergantungan .
Madge adalah sesuatu yang menganalisis kode dan mengatakan: ini adalah kelas yang begitu dan begitu terkait dengan ini dan itu, dll. Jika semuanya melewati satu komponen dan rusak, maka akan ada sedikit kesenangan. Madge adalah alat visualisasi yang hebat, tetapi hanya cocok untuk eksplorasi manual. Ini memiliki opsi, melingkar, yang mencari semua
dependensi siklik di proyek Anda . Jika ada, itu buruk, jika tidak, maka mereka belum menulis.
Rasa sakit kerangka kerja lama dan perpustakaan hampir diselesaikan dengan
updtrJS .
Apakah Anda memiliki 70 ribu baris kode? Apakah Anda mencoba untuk beralih dari Reaksi ke-13 ke ke-16?
Updtr tidak akan membantu Anda pindah, tetapi itu akan membantu Anda mengetahui versi perpustakaan mana yang dapat Anda pindahkan tanpa
konsekuensi serius . Selain itu, ini memungkinkan pengembang untuk tetap dalam tren, membantu menjaga dependensi terbaru. Jika Anda memiliki cakupan tes yang baik, saya sarankan.
Jenis statis
Gunakan pengetikan statis JS , karena pengetikan dinamis
JS bukan fitur sama sekali, ini adalah jurang maut. Flow, typeScript, reasonML itu saja ...
Pengujian kekacauan
Inti dari pengujian kekacauan ini sederhana: mulai browser dan mulai menusuk semua yang menusuk, masukkan semua yang dimasukkan ke semua bidang, dan seterusnya. Sampai rusak. Amazon, exceptions . , « , ». , . :
Gremlin.com Chaos Monkey .
React — 16- , componentDidCatch. , exception, . .
Naughty String , , . , « », internal server error, ?
War Story #2
– . . def generateRandomPostfix(String prefix) { return prefix + "-" + Math.abs(new Random().nextInt()).toString() } def "testCorrectRandomPostfix"(){ given: def prefix = "ASD" when: def result = generateRandomPostfix(prefix) then: result?.matches(/[a-zA-Z]++-[0-9]++/) }
. . , .
. ASD, , . . ( , groovy). Java integer 1 integer. integer integer — .
, . . ? «+» fromX. , - , XML .
.
.
TestCheck.JS — . , , . —
Flow-To-Gen : Flow , .
check( property( gen.int, gen.int, (a, b) => a + b >= a && a + b >= b ) )
{ result: false, failingSize: 2, numTests: 3, fail: [ 2, -1 ], shrunk: { totalNodesVisited: 2, depth: 1, result: false, smallest: [ 0, -1 ] } }
TestCheck « », . , . , , : 0 -1. 2 -1, , . !
. . , . , ? -? permission'? ? , , , , .
3rd party failures . „ “ — .
Production-
production 16- React :
ErrorCeption HoneyBadger (
Sentry ). ,
.Optimizely /-. , , , , , .
Out of the box
JS — . , JavaScript. —
validator.w3.org/checklink . , , , , .
, , .
Achecker.ca/checker .
Webpagetest.org — , .
Tools.pingdom.com — .
www.w3.org/WAI/ER/tools .
. . , Jenkins Multibranch Plugin, - -. -, (« , »), nightly-, - regress, full regress, smart regress ..
— , , , , . , , , .
, , . .