Rspec-core: Pertimbangkan kembali `shared_context_metadata_behavior`

Saya ingin memanggil @myronmarston sebagai kekuatan pendorong di belakang :apply_to_host_groups .

Terima kasih telah menulis ini @pirj dan memanggil saya untuk berkomentar :).

Saya masih berpikir bahwa penyertaan implisit dari grup contoh bersama melalui metadata masih memiliki masalah. #1790 menguraikan masalah yang saya lihat dengannya ketika saya menulis masalah itu. Secara keseluruhan, perilaku inklusi implisit terasa tidak konsisten dengan RSpec lainnya, IMO; pertimbangkan bahwa semua cara lain yang memanfaatkan metadata RSpec, Anda mengonfigurasinya di blok RSpec.configure . Memiliki 1 fitur RSpec menggunakan metadata secara implisit (tanpa mengharuskan pengguna untuk mengonfigurasinya secara eksplisit dalam RSpec.configure ) adalah sesuatu yang saya harapkan akan membingungkan pengguna yang telah menggunakan metadata RSpec tetapi tidak mengetahui perilaku penyertaan implisit . Baik rspec-rails#1579 dan rspec-rails#1241 adalah contohnya: pengguna menandai grup contoh bersama mereka dengan metadata, mengharapkannya untuk bertindak seperti metadata pada tindakan grup normal (mis. memicu penyertaan config.include 'd modul, tersedia untuk pemfilteran, dll) dan terkejut melihat perilakunya tidak seperti itu. Faktanya, mereka sangat terkejut dengan hal itu sehingga mereka melaporkannya sebagai bug meskipun berfungsi seperti yang dirancang. Itu menunjukkan kepada saya bahwa itu adalah desain yang buruk untuk memulai: jika itu benar-benar selaras dengan RSpec lainnya, itu tidak akan mengarahkan pengguna untuk melaporkannya sebagai bug.

Sebagai kotak pasir untuk polisi rubocop-rspec baru, saya telah mengumpulkan daftar proyek Ruby yang paling banyak bintangnya yang menggunakan RSpec, rspec dunia nyata, ~ total 35 proyek. Dari 35 itu (termasuk repo RSpec juga!), 7 menggunakan :apply_to_host_groups di pembantu spesifikasi mereka:

Semantik yang tepat untuk menandai grup contoh bersama dengan metadata adalah sesuatu yang saya harapkan 99% dari pengguna RSpec tidak pernah memikirkan dan situasi membingungkan yang dipecahkan oleh perilaku yang lebih baru relatif jarang .... jadi saya tidak terkejut dengan itu sama sekali. TBH, saya menduga :apply_to_host_groups mungkin terutama digunakan oleh proyek yang menghasilkan (atau membuat ulang) spec_helper.rb setelah kami mengubah kode konfigurasi spec_helper.rb dihasilkan di 3589ab577d09db88ef5d5f0d60e8c35bfc55691f.

Untuk pengguna yang ingin memicu penyertaan grup contoh bersama berdasarkan metadata, disediakan API config.include_context yang, IMO, lebih sederhana, lebih konsisten, dan lebih eksplisit yang melakukannya secara otomatis untuk pengguna karena mereka menandai grup bersama dan grup normal dengan metadata yang sama. AFAIK, tidak ada yang disediakan :trigger_inclusion yang tidak dapat dicapai oleh pengguna yang menggunakan config.include_context secara eksplisit. (Jika ada sesuatu yang tidak dapat dicapai dengan cara itu, beri tahu saya!). OTOH, jika pengguna ingin menandai grup contoh bersama mereka dengan beberapa metadata, dan menerapkannya di mana pun grup bersama disertakan...Saya tidak berpikir ada mekanisme alternatif untuk ini. (Sebenarnya, mungkin config.define_derived_metadata dapat digunakan untuk mensimulasikan ini, tetapi IMO yang terasa seperti "menyelesaikan" untuk fitur yang kurang).

Secara pribadi, saya belum pernah melihat :apply_to_Host_groups digunakan seperti yang dirancang.

Inilah cara saya menggunakannya:

• Saya telah menandai sementara grup contoh bersama dengan :focus , :pending , atau :skipped sehingga saya dapat fokus pada (atau memfilter) spesifikasi yang bergantung pada contoh bersama tertentu kelompok. Grup contoh bersama umumnya berarti ada beberapa masalah lintas sektoral yang berlaku untuk semua grup termasuk, dan dapat menjalankan hanya spesifikasi tersebut (atau mengecualikan spesifikasi tersebut) bisa sangat berguna. Perlu dicatat bahwa penggunaan fitur ini umumnya tidak akan muncul dalam kode yang dikomit untuk proyek apa pun, karena :focus , :skip dan :pending biasanya merupakan perubahan sementara yang tidak berkomitmen (terutama :focus ).
• Ini bisa sangat berguna sebagai cara untuk mengekspresikan dependensi pada kode test harness lainnya. Misalnya, pertimbangkan sebuah proyek yang secara kondisional membungkus contoh dalam transaksi DB ketika mereka diberi tag :db . (Hal ini dapat dicapai dengan mendefinisikan DB support misalnya kelompok bersama dengan tepat around hook, dan kemudian menggunakan config.include_context "DB support", :db ). Sekarang bayangkan pengembang ingin mendefinisikan grup contoh bersama baru bernama logged in as admin yang mendefinisikan kait before yang membuat pengguna admin dalam database dan masuk sebagai pengguna tersebut menggunakan uji rak atau apa pun . Karena grup contoh bersama yang baru ini berinteraksi dengan database di hook before , ia memiliki ketergantungan pada grup contoh bersama DB support . IMO, cara terbersih untuk mengekspresikan ketergantungan ini adalah dengan menandai grup contoh bersama logged in as admin dengan :db sehingga dukungan DB diterapkan secara otomatis ketika logged in as an admin disertakan dalam grup host . Anda dapat melakukan include_context 'DB support' di grup contoh logged in as an admin untuk menerapkan transaksi DB secara otomatis, tetapi jika cara "normal" Anda mengelolanya di tempat lain adalah melalui tag :db itu aneh untuk tidak dapat melakukannya di sini.

Kami juga menggunakannya. rspec-harapan:

TERTAWA TERBAHAK-BAHAK :). Saya tidak terlalu terkejut dengan itu; kami belum secara historis memutakhirkan RSpec ke semua pengaturan konfigurasi "standar" terbaru, dll, terutama jika masalah alamat pengaturan konfigurasi baru tidak terjadi dalam pengujian RSpec. Cukup mudah untuk mengubah penyertaan yang dipicu metadata rspec-expectations untuk menggunakan config.include_context , bukan?

Kesimpulan awal: proyek Ruby populer yang menggunakan RSpec yang mengonfigurasi shared_context_metadata_behavior ke :apply_to_host_groups melakukan ini secara membabi buta dan tidak pernah menggunakannya.

Sejujurnya saya akan terkejut jika ada lebih dari segelintir pengguna yang telah memikirkan bagaimana tepatnya mereka ingin metadata grup contoh yang dibagikan untuk berperilaku, untuk kemudian pergi dan mengatur opsi konfigurasi ke perilaku yang mereka inginkan. Saya membayangkan hampir semua penggunaan :apply_to_host_groups dalam konfigurasi disebabkan oleh pembuatannya melalui rspec --init .

Saya tidak berpikir itu adalah argumen yang menentang :apply_to_host_groups , meskipun; seperti yang saya lihat, setengah dari manfaat :apply_to_host_groups adalah ia menonaktifkan perilaku penyertaan otomatis warisan implisit yang berlawanan dengan intuisi. Separuh manfaat lainnya adalah memungkinkan perilaku baru yang lebih sesuai (IMO, YMMV, tentu saja) dengan keseluruhan desain RSpec. Sebuah proyek yang mengonfigurasi :apply_to_host_groups dan kemudian tidak pernah benar-benar menandai grup bersama dengan metadata masih dapat mengambil manfaat dari opsi ini; masih ada perilaku yang berpotensi membingungkan yang mereka hindari. Misalnya, jika pengembang untuk sementara menandai grup bersama dengan :focus , bermaksud untuk memfokuskannya... ada baiknya RSpec tidak menyertakan grup bersama di grup lain yang menjadi :focus ed pada.

Tidak masuk akal untuk menerapkan metadata yang ditentukan untuk grup bersarang yang dibuat secara implisit.

Saya pikir :apply_to_host_groups masih memberikan perilaku yang bermanfaat untuk kasus ini, meskipun Anda benar bahwa menerapkan metadata ke grup Host tidak benar-benar berlaku di sini. Pertimbangkan kasus sekelompok contoh bersama yang semuanya bergantung pada database (dalam proyek yang menandai contoh tersebut dengan :db untuk membungkusnya dalam transaksi DB). Ini berguna bagi pengguna untuk dapat menandai grup contoh bersama mereka dengan :db untuk mengekspresikan ketergantungan pada database (dan untuk secara otomatis membungkus semua contoh yang ada dalam transaksi DB). Meskipun it_behaves_like tidak akan menggabungkan metadata :db ke dalam metadata grup host, masih bagus untuk dapat menandai grup bersama dengan :db dan menerapkannya ke contoh di dalamnya. Perilaku :trigger_inclusion warisan menghalangi kemungkinan ini karena ketika Anda melakukannya shared_examples_for "common metadata support", :db , tag :db digunakan untuk menyertakan otomatis grup bersama ini di :db -tagged kelompok.

Ini pada dasarnya adalah inti dari mengapa saya pikir :apply_to_host_groups lebih disukai: kami memiliki cara untuk menyertakan grup contoh bersama berdasarkan metadata menggunakan config.include_context (yang dengan baik mencerminkan config.include untuk modul. ..), tetapi jika kami secara implisit menggunakan metadata grup bersama untuk memicu penyertaan, ini mencegah pengguna untuk dapat menandai contoh bersama mereka dengan metadata umum di tingkat grup. Dan jika kami menggunakan metadata grup bersama dengan cara itu, maka IMO ekstensi alami itu untuk include_context / include_examples (ketika penyertaan tidak bersarang) adalah menggabungkan metadata dengan host metadata grup. (Tapi YMMV; itu hanya model mental saya tentang cara kerja metadata RSpec).

Namun, mengapa termasuk_konteks? Yah, kami hanya memiliki include_context pada objek Konfigurasi kami. Tidak ada include_examples atau it_behaves_like di sana.

Itu dengan desain. IMO, akan mengejutkan (dan aneh) untuk secara otomatis memasukkan beberapa contoh bersama di banyak grup contoh berdasarkan konteks. Seorang pengguna dapat melihat file spesifikasi, melihat 4 blok it (menyarankan menjalankan file akan menjalankan 4 contoh), menjalankannya, dan terkejut melihat 20 contoh dijalankan (misalnya karena 16 contoh bersama disertakan) . IMO, contoh adalah hal utama yang harus dilihat dan dipahami untuk memahami bagaimana rangkaian tes disusun, dan cara kerjanya. Kode harness pengujian bersama (misalnya metode helper, let s, atau hook around yang mengelola transaksi DB...) tidak memiliki kebutuhan yang sama untuk terlihat. Faktanya, saya cenderung menggunakan grup contoh bersama (dan include_context ) secara khusus untuk menyembunyikan detail yang tidak penting dari penambahan noise ke banyak spesifikasi. Misalnya, untuk masalah lintas sektoral seperti penangkapan log, atau transaksi DB, saya tidak ingin setiap pengujian yang memiliki masalah tersebut memiliki gangguan kode yang terlihat untuk mengelola hal-hal tersebut. Mampu menandai grup dengan :db atau :capture_logs dan membiarkan config.include_context menerapkan kode bersama untuk saya, menghasilkan spesifikasi dengan rasio signal-to-noise yang lebih tinggi. Ini tidak sama dengan include_examples / it_behaves_like , yang tidak dimaksudkan untuk digunakan untuk jenis masalah lintas sektoral yang sama yang bagus untuk ditangani secara otomatis.

Bagaimanapun, itu dua sen saya :). Karena saya tidak lagi terlibat dalam pemeliharaan RSpec, saya tidak merasa berkewajiban untuk memberikan pendapat saya secara berlebihan.

Terima kasih banyak atas jawaban yang mendetail dan berwawasan luas, @myronmarston!

bermanfaat bahwa RSpec tidak menyertakan grup bersama di grup lain yang sedang :focused aktif

Itu memang akan menjadi pendewaan kebingungan.

Keraguan saya hilang, saya akan melanjutkan dengan menjadikan :apply_to_host_groups sebagai opsi default dan satu-satunya.
Saya akan tetap membuka tiketnya, akan menghubungkan PR ke sana.

Keraguan saya hilang, saya akan melanjutkan dengan menjadikan :apply_to_host_groups sebagai opsi default dan satu-satunya.

Mungkin ada baiknya menghapus opsi konfigurasi sepenuhnya, mengingat rencananya adalah untuk tidak mendukung perilaku lain apa pun. Atau mungkin untuk kompatibilitas mundur itu dapat didefinisikan tetapi diabaikan (walaupun itu bisa membingungkan jika pengguna mengonfigurasi perilaku warisan ...). Saya tidak tahu apakah Anda berencana merilis RSpec 3.99 (seperti yang kami lakukan dengan 2.99) untuk memberikan peringatan pemutakhiran, tetapi jika Anda menggunakan rute itu 3.99 dapat mempertahankan opsi dan memperingatkan dengan tepat dan 4.0 tidak dapat memiliki opsi di semua mungkin.

Terima kasih atas jawaban terperinci @myronmarston :joy: Saya menutup ini karena saya setuju, dan menilai dari PR Phil dia juga yakin.