Pemikiran pada ThoughtWorks Radar 4

Radar ThoughtWorks 2024 telah dikeluarkan (anda boleh memuat turun PDF dengan 1 klik, tiada pendaftaran yang menjengkelkan diperlukan). Di bawah adalah 2 perkara:

1. saya membincangkan perkara yang saya keliru tentang Ujian Komponen
2. alat baharu yang menarik untuk menyiasat atau mengetahui sebab alat itu beralih daripada "Menilai" kepada "Mengguna pakai"

Jika anda hanya ingin mengetahui tentang perkara baharu yang menarik untuk dilihat, langkau teguran ujian komponen saya.

Ujian Komponen: Mengamalkan

Saya mempunyai banyak soalan mengenai "Adopsi" ini. Majikan semasa saya telah melaburkan banyak latihan & peralatan untuk membantu pasukan melakukan ujian Komponen, yang saya suka. Apa yang saya tidak suka ialah teknik ujian lain yang definisinya berbeza berdasarkan siapa yang bercakap mengenainya.

Biar saya gariskan beberapa takrifan yang saya lihat di alam liar mengikut susunan kronologi yang saya pelajari tentangnya, dengan apa yang saya _fikir_ takrif ThoughtWorks adalah yang terakhir:

• Buku cerita untuk membantu menguji komponen React secara berasingan, banyak digunakan untuk pengarang rangka kerja komponen
• menguji komponen dalam persekitaran penyemak imbas terpencil menggunakan Ujian Komponen Cypress
• Takrifan terbaharu saya tentang Pengujian Kotak Putih Cypress, bermakna semua panggilan I/O luaran (fetch/xhr, memuatkan JSON, membaca localstorage, dll) adalah cy.dipintas atau ditikam/diejek

Tiada satu pun yang sama. Komponen dalam konteks di atas bermaksud komponen UI, sama ada sesuatu seperti a atau a yang menyusun banyak komponen, kod dan CSS lain. Saya sebut "macam", kerana dalam Buku Cerita dan Cypress, anda menggunakan penyemak imbas sebenar, bukan pelayar palsu seperti JSDom. Dalam konteks ini, saya percaya menggunakan penyemak imbas sebenar boleh menyelesaikan banyak isu, khususnya di sekitar Ujian Penerimaan, bukan Ujian Unit. Saya mempunyai pengalaman yang bertentangan dengan apa yang mereka sebutkan: anda boleh membuat Cypress/Penulis Drama dengan sangat pantas (menggunakan perkara seperti itu. sahaja, stub yang berat, mereka bentuk UI anda agar lebih dipisahkan untuk menguji aliran pengguna tertentu), dan jumlah keyakinan yang saya ada dalam aplikasi berfungsi, untuk pengguna, adalah sangat tinggi. Memandangkan sistem menaip Elm, ini adalah cara utama anda boleh mengesahkan kekurangan syarat perlumbaan dalam kod Elm anda, dan bagus kerana anda boleh menghabiskan lebih banyak masa menulis Ujian Penerimaan menggunakan teknologi tersebut. Ujian kotak putih Cypress TIDAK serpihan; mereka bersifat deterministik, itulah sebabnya kita semua menyayangi mereka.

Walau bagaimanapun, saya mengakui penyahpepijatan boleh mencabar. Hanya kerana anda "dalam penyemak imbas" tidak selalu memberi anda cerapan yang mendalam tentang sebab sesuatu rosak walaupun terdapat titik putus, kata kunci penyahpepijat, kod sumber yang dihimpun, cerapan ke dalam panggilan rangkaian dan pelbagai log yang boleh anda gunakan (bukan lidah di pipi , walaupun dengan semua itu anda masih boleh menjadi seperti “kawan, kenapa ini tidak berkesan…”)

Seterusnya, ThoughtWorks dan Cypress memetik ujian "hujung ke hujung". Takrifan di sini juga berlumpur. Berikut ialah beberapa takrifan yang pernah saya lihat:

• Pengambilan e2e Dave Farley, yang pada asasnya mengesahkan "semua perkara" berfungsi bersama-sama (jangan dikelirukan dengan dorongan untuk Ujian Keseluruhan Awal)
• Ujian Kotak Hitam Cypress, di mana anda TIDAK stub/mengejek panggilan ajax dan I/O lain, dan ini hanya menguji "tapak anda dan integrasinya"
• ThoughtWorks nampaknya mengatakan Playwright/Cypress/Selenium adalah terutamanya alatan e2e di mana saya melihatnya sebagai alat Ujian Penerimaan, dengan pengecualian fungsi Pengujian Komponen Cypress yang mencerminkan sedikit Buku Cerita
• Hillel Wayne memanggil mereka begitu juga

Akhir sekali, saya tidak pernah menikmati sambungan ujian komponen React. Mereka sangat mengejek / kesan sampingan, dan sangat menggalakkan anda untuk mengeluarkan kemahiran JQuery untuk mengesahkan "Komponen saya dipaparkan dengan betul" yang tidak selalunya sama dengan "berfungsi dengan betul", terasa seperti memecahkan abstraksi, dan menguji jika React sedang bekerja. Sebaliknya, sama ada React, Angular atau Elm, saya sentiasa merasakan menguji kod anda berfungsi, mencipta komponen tulen terutamanya dan menguji "Komponen Pintar" (cth. komponen dengan kesan sampingan) yang anda sahkan dalam Ujian Penerimaan (Cypress atau Penulis Drama) .

Pembangun web JavaScript mempunyai pendapat yang berbeza-beza dan pelbagai definisi perkataan. Itu secara amnya baik, tetapi sebagai seseorang yang mempunyai ThoughtWorks sebagai wira hud dewasa muda, sentiasa mengesyorkan Martin Fowler dan karya bertulis ThoughtWorks lain sebagai cadangan yang menarik untuk dipelajari, dan acara ingin bekerjasama dengan mereka suatu hari nanti... anda boleh melihat mengapa sudut pandangan yang bertentangan ini adalah memberi saya krisis iman.

Jadi:

1. setuju dengan ujian komponen dalam pelbagai bentuk
2. tidak bersetuju dengan JSDom dan "tegaskan item senarai 2 komponen saya mempunyai teg tebal dengan teks dalam 'lembu'" dalam bahasa pilihan ujian unit anda.

Untuk nilainya, perkara di atas diwarnakan dalam pelbagai bahasa. Angular dan Lit/WebComponents, sebagai contoh, jika anda mengelak templat mempunyai sebarang logik melebihi if dan menukar pengikatan kepada pembolehubah komponen awam, adalah lebih mudah untuk menguji unit dan menegaskan kesan sampingan berbanding rangka kerja semasa React dan yang lain terdedah. Walau bagaimanapun, Angular dan beberapa rangka kerja WebComponent memerlukan kod persediaan yang sangat sukar untuk dinyahpepijat, manakala React/Elm sebaliknya.

Selain itu, saya tahu mencipta PDF ini adalah usaha yang hebat, dan begitu juga dengan cuba meringkaskan apa sahaja dalam teknologi, jadi saya pasti saya hanya kehilangan banyak gelen konteks.

Penggunaan Berterusan: Mengamalkan

Memang mengagumkan dan melihat CEO saya bercakap tentang perkara ini dalam ceramah tahunannya. Saya tahu acara percubaan CD Minimum boleh menjadi perubahan besar untuk orang ramai, tetapi ini adalah cara terbaik yang saya lihat dalam bekerja, sangat gembira melihatnya dengan jelas dipanggil dalam Adopt.

Golem: Menilai

Saya sangat teruja apabila pencipta Zio terlibat dalam mencipta Mesin Negeri-Yang-Tidak-Boleh-Crash ini sebagai Perkhidmatan, yang dipanggil Golem. Saya lebih teruja kerana mereka mendapat sokongan untuk Grain, bahasa taip FP gaya OCAML dengan baik. Saya tidak dapat mencari masa/inspirasi untuk bermain kerana saya masih berasa terperangkap dalam pusaran "semua perkara adalah AWS". Ya, saya telah bermain & menggunakan CloudFlare dalam pengeluaran, tetapi… sebagai peminat AWS Step Functions, ini kelihatan seperti idea yang bagus. Satu daripada hujung minggu ini saya akan mencuba lagi dengan TypeScript memandangkan Grain nampaknya bukan lagi pilihan.

Bruno: Angkat

Banyak Klien REST ini, sesetengahnya terbina dalam VSCode, disekat oleh pelbagai syarikat kerana mereka mengehoskan butiran API dalaman anda pada pelayan mereka atau menghantar butiran ke tempat lain. Perkara seperti Posman dan Insomnia dan lain-lain telah mula memerlukan langganan walaupun mendakwa mereka tidak melakukannya yang hanya memburukkan keadaan. Oleh itu, terdapat dorongan besar untuk mencari alat serupa yang tidak berkongsi data anda. Bruno adalah salah satu yang saya perlu semak kerana saya tidak lagi dibenarkan menggunakan ThunderClient.

Alat ujian regresi visual: Mengamalkan

Terdapat pelbagai cara CSS boleh memecahkan keseluruhan aplikasi anda, dan tiada cara untuk ujian unit atau ujian penerimaan dengan mudah untuk menghalangnya. Saya benar-benar bergelut dengan alat syot kilat React awal, dan merasakan ROI tidak ada untuk tapak yang lebih kecil memandangkan banyak positif palsu. Alat seperti Applit dan BackstopJS adalah beberapa daripada banyak, termasuk perkhidmatan, untuk mengesahkan rupa dan berfungsi tapak anda ok. Mereka sering mengejar, atau pada masa yang sama, sebagai ujian penerimaan anda dalam saluran paip anda. Saya mungkin mempunyai pengalaman selama 5 minit dengan alatan Applit, tetapi pastinya ingin melihat Backstop.

GitButler: Menilai

Yang paling saya teruja ialah GitButler. Sebagai seseorang yang membenci Permintaan Tarik selepas mengalami Trunk Based Dev, dan kecewa dengan keadaan dan pengabaian pelbagai alat di sekitar"abstraksi terhadap PR", GitButler nampaknya ia boleh memulihkan kewarasan saya dalam konteks beralih kepada membuat PR untuk PR.

Mise: Menilai

Mise agak pelik kerana saya tidak pernah menghadapi masalah dengan nvm untuk mengurus versi Node.js, dan pipenv untuk mengurus/menjalankan projek Python, jadi ingin tahu, cuba lihat perkara ini dan lihat apa yang menjadi kekecohan.

Mockoon: Menilai

Saya benci ejekan. Saya cenderung untuk bekerja dalam bahasa yang membenarkan kesan sampingan, dan dengan pembangun yang tidak mengikuti Pure Core, Imperative Shell. Jadi apa sahaja yang boleh saya lakukan untuk mengetahui lebih lanjut tentang musuh saya, dan cara mengurusnya, adalah penggunaan masa yang baik, dan Mockoon ialah seorang lagi pencipta olok-olok tersebut.

Rspack: Menilai

Syukurlah, saya tidak perlu menyepadukan dengan Webpack. Malangnya, saya telah dipengaruhi beberapa kali oleh _orang lain_ integrasi dengan Webpack. Vite adalah menghirup udara segar; sangat pantas, dan ia berkesan. Jadi menarik untuk mendengar pesaing lain mengenai kelajuan. Vite menang bukan sahaja kerana kepantasannya yang menakjubkan, tetapi Pengalaman Pembangun yang mengagumkan begitu hebat lihat apa yang berlaku di sini dengan Rspack.

Zed: Menilai

Teruja untuk mencuba Zed IDE walaupun VSCode mempunyai cengkaman pada saya, iaitu kerana pengaturcaraan pasangan terbina dalam, kelajuan super pantas dan kerana pencipta Roc lang menyertai pasukan mereka.

Pkl: ​​Perbicaraan

Saya mula-mula beralih ke Pkl semasa fasa Dhall Trough of Disillusionment saya (Dhall hebat, tetapi lelaki itu sukar) oleh James Ward. Ia kelihatan seperti bahasa yang mempunyai jenis yang mencukupi untuk menyusun fail konfigurasi YAML/JSON dengan lebih selamat. Saya mempunyai cukup banyak salah konfigurasi YAML/JSON yang memecahkan pengeluaran, yang saya mula mencari cara untuk menyusun masalah tersebut, dan Dhall banyak membantu, tetapi keluk pembelajaran dan ralat pengkompil adalah kejam untuk diselesaikan, dan saya tidak pernah mendapat keseronokan di kalangan rakan sebaya . Berharap Pkl membuat in-road di sini.

Kesimpulan

Pastikan anda memuat turun PDF itu sendiri, kerana saya telah mengabaikan TON teknologi baharu dan sedia ada di sana (LLM, infra, sains data) yang saya rasa membosankan, tetapi orang lain mungkin mendapati menarik.

Atas ialah kandungan terperinci Pemikiran pada ThoughtWorks Radar 4. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!