Cucumber-js: Hasil skenario & tag hilang

Tidak. Anda tidak dapat dengan mudah mengakses tag dari kasus uji. Tidak ada rencana untuk kembali ke hasil skenario lama. Apa kasus penggunaan Anda untuk membutuhkan tag?

Dalam kasus saya, saya memiliki ketergantungan pada sistem tag. Untuk mendapatkan beberapa data di afterhooks.

Sesuatu seperti ini:

<strong i="7">@SuiteName</strong> <strong i="8">@SuiteSectionName</strong> <- These tags tell the suite
Feature: 

<strong i="9">@TC1563697</strong> <- This tag identifies the testcase in the test management tool <strong i="10">@New</strong>
Scenario: 
    Given  
    When 
    Then 

Anda dapat membuat kait yang hanya berjalan untuk skenario dengan tag tertentu: https://github.com/cucumber/cucumber-js/blob/v3.0.1/docs/support_files/hooks.md#tagged -hooks

Saya juga memiliki beberapa kasus penggunaan untuk mengetahui tag skenario. Diberikan contoh Sudo berikut (sintaks versi hilang sedikit karena saya memiliki kasus uji di 1.3.1, dan saya melihat yang terbaru 3.0.1):

<strong i="6">@set_video</strong> <strong i="7">@youtube</strong>
Scenario: User should see youtube video

<strong i="8">@set_video</strong> <strong i="9">@vimeo</strong>
Scenario: User should see vimeo video


this.After({tags: @set_video}, function (testCase) {
  let tags = testCase.scenario.tags;

_.forEach(tags, (function (tag) {
 if(tag === '<strong i="10">@youtube</strong>') {
   setVideo('youtube');
 }
if(tag === '<strong i="11">@vimeo</strong>') {
 setVideo('vimeo');
}
});

}

Saya memiliki satu tag yang mengatakan kapan kait harus dijalankan dan saya memiliki tag lain yang bertindak sebagai data untuk membuat kait lebih dinamis agar berfungsi untuk kasus penggunaan lain. Kalau tidak, saya menemukan diri saya membuat kait yang sama dengan logika yang sama dan hanya mengubah data yang saya berikan. Saya merasa mengetahui tag sangat berguna dan alat yang sangat ampuh untuk membuat kait lebih fleksibel.

Bisakah saya juga bertanya di sini saya sepertinya tidak bisa mendapatkan objek hasil di kait Setelah di 3.0.1. Saya mencoba testCase, scenarioResult, dan scenario. Apakah saya melewatkan sesuatu?

Kami memiliki kasus di mana kami menyimpan kasus uji kami di TestRail dan kami mengunduhnya dan menyimpannya sebagai file fitur sebelum dijalankan.

Kemudian di hook setelah kami mengirim hasil tes terperinci ke database SQL kami. Hasil tersebut antara lain:

• ID fitur dari TestRail - diambil dari tag (setiap fitur secara otomatis membuat tag dengan ID fitur)
• pengecualian yang dilemparkan - diambil dari scenario.getException() dalam mentimun 1.x
• semua tag fitur ini ditandai dengan
• langkah yang gagal - kami menggunakan kait stepResult untuk mendapatkan hasil dari setiap langkah
• banyak info lain yang diambil dari TestRail menggunakan ID fitur yang diambil dari tag

Jadi dengan perubahan mentimun 3.x saat ini, kami tidak akan pernah dapat beralih karena itu benar-benar merusak infrastruktur kami.

@pawelus Infrastruktur saya melakukan hal yang persis sama.
Sepertinya karena Anda tidak kehilangan apa pun dari melakukan tindakan ini secara tidak sinkron (yaitu infrastruktur pengujian Anda yang sebenarnya tidak "peduli" tentang pembaruan TestRail), Anda dapat memindahkan kode itu ke pemformat khusus, dan menggunakan informasi yang berasal dari acara protokol untuk membangun dan mengirim laporan.

Secara pribadi saya memiliki skrip pembungkus yang meluncurkan mentimun.
Itu mengunduh skenario TestRail sebelum mentimun diluncurkan, jadi itu bukan masalah besar bagi saya untuk memindahkan kode laporan TestRail dari kait mentimun dan ke skrip pembungkus.
Setelah mentimun selesai, skrip membaca hasil keluaran JSON mentimun, dan mengkompilasi semua informasi yang dibutuhkan dari sana.

Sepertinya Anda harus mengatur ulang kode Anda.
Saya pikir memindahkan semua tindakan pra/pasca ke skrip pembungkus adalah solusi bagus yang mengembalikan beberapa kontrol yang telah hilang di V3.
Ini masih agak menyusahkan, karena saya harus membuat cerita bersambung informasi konteks penting untuk memperkaya hasil yang dihasilkan (karena keadaan infrastruktur saya dihancurkan pada saat kode yang relevan berjalan), tetapi itu bisa dilakukan.

Saya pikir kehilangan kemampuan untuk mengetahui tag di kait akan memalukan. Itu adalah satu-satunya cara untuk membuat sedikit lebih dapat dikonfigurasi karena Anda tidak dapat meneruskannya parameter Saya menambahkan tag tambahan dan kemudian melihat mana yang diterapkan pada skenario saat ini untuk memanggil fungsi dengan input yang berbeda.

@yaronassa kami menjalankan pengujian kami melalui

Kami mengunduh fitur sebelum Busur Derajat dimulai seperti yang Anda lakukan tetapi mengirimkan hasil ke database adalah cerita yang berbeda.

Dengan sharding & tes yang berjalan di kisi Selenium dan menjalankan kembali fitur yang gagal, akan cukup merepotkan dan logika rumit untuk mendapatkan hasil dalam urutan yang benar dalam database. Cukup banyak pekerjaan untuk mengembalikan kemampuan yang kami miliki di mentimun 1 dan 2.

Juga membuat pemformat khusus hanya untuk mendapatkan hasil langkah tidak terdengar benar.

Hei, aku bersamamu.
Saya ingin akses tidak terbatas ke status mentimun saat ini - fitur, skenario, dan langkah, dengan seluruh koleksi propertinya, dan akses tulis (saya bahkan ingin akses ke "tumpukan panggilan" skenario di masa depan, dengan kemampuan untuk memanipulasinya sebelumnya ).

Melihat mentimunJS sengaja menjauh dari "visibilitas batin" semacam ini, saya menawarkan jenis solusi yang menurut saya dapat bekerja di masa mendatang. Secara pribadi, saya pikir akan tiba saatnya di mana pengotak-atik seperti kita harus menggunakan metode utama dalam internal Mentimun untuk mempertahankan akses semacam ini.
Dan tidak apa-apa - saya kira ada selusin dari kita, dan ribuan pengguna biasa.

Jika memungkinkan saya juga akan mendukung nama skenario. Memang saya menambahkan kemampuan snapshot dan saya perlu tahu nama skenario untuk memberi nama snapshot saya.

@gd46 Anda dapat melakukan hal berikut:

this.After({tags: "<strong i="7">@set_video</strong> and @youtube"}, function () {
  setVideo('youtube');
})

this.After({tags: "<strong i="8">@set_video</strong> and @vimeo"}, function () {
  setVideo('vimeo');
})

Itu tidak memiliki duplikasi selain dari flag @set_video .

@pawelus

Kemudian di hook setelah kami mengirim hasil tes terperinci ke database SQL kami.

Apakah Anda perlu melakukan ini di hook After ? Bisakah Anda melakukan ini setelah tes Anda selesai dengan mem-parsing hasil formatter json? Anda dapat menggunakan formatter protokol acara untuk melanjutkan ini karena hasil terjadi meskipun itu akan memerlukan pemrosesan lebih lanjut. Hasil sampingan dari perubahan 3.x adalah hasil parsing keluar dari file dukungan dan ke proses mandiri. Saya pikir ini adalah pemisahan yang lebih baik dan idealnya bagaimana hal-hal dibangun pada awalnya.

@bnadim

Anda dapat menambahkan tangkapan layar dengan fungsi attach agar mereka dikeluarkan dalam formatter potocol / json dan kemudian melakukan beberapa pemrosesan pos untuk menyimpannya ke file berdasarkan nama skenario. Sisi tidak: nama skenario tidak dijamin unik sedangkan skenario uri dan nomor barisnya.

@charlierudolph saya kira itu adalah solusi pengganti yang solid untuk kebutuhan saya. Ini juga menghilangkan kebutuhan untuk menganalisis skenario yang sedang berjalan. Itu mungkin mengarah pada pendefinisian beberapa kombinasi kait yang menjelaskan kombinasi berbeda yang dapat ditangani oleh fungsi tertentu dalam sebuah kait.

Jadi misalnya saya memiliki contoh serupa di mana saya mendapatkan tag skenario yang berjalan saat ini membaginya berdasarkan pola dan menggunakan bagian dari kecocokan sebagai parameter ke suatu fungsi. Dalam kasus ini semua langkah yang perlu terjadi adalah sama dan satu-satunya yang berubah adalah parameternya. Jadi ini akan mengurangi beberapa langkah penyiapan di hook sehingga bisa bekerja untuk banyak kasus.

Salah satu contohnya:

tags: <strong i="9">@clear_w2OnlyUser</strong>, <strong i="10">@clear_w2OnlyArcotEnableUser</strong>

I split based on <strong i="11">@clear_</strong> and grab the second half as the parameter. tagName coming from the old scenario result of getTags, getName. 

let profileToClear = tagName.split('<strong i="12">@clear_</strong>')[1];

browser.waitForAngularEnabled(false);
browser.get(url);
login();
navigate();
deleteProfile(profileToClear);

Beri tahu saya pendapat Anda tentang ini? Saya percaya contoh Anda akan menjadi pengganti yang mudah dalam beberapa kasus. Tetapi di tempat lain di mana ada beberapa langkah tambahan yang perlu dilakukan, Anda bisa berpotensi menduplikasi semua langkah ini.

Kasus penggunaan saya adalah saya menyiapkan mockserver untuk setiap skenario, berdasarkan tag yang saya tahu bagaimana seharusnya berperilaku. Menambahkan kait untuk skenario yang diberi tag tertentu sangat intensif pemeliharaan, karena saya perlu menambahkan kait untuk setiap skenario yang saya dukung...

Kami juga menggunakan scenario.name di kait Sebelum dan Setelah kami untuk mencatat nama skenario. Dengan cara ini kita dapat melihat kapan skenario tertentu dimulai dan berakhir saat menganalisis hasil pengujian. Perubahan ini merusak fitur itu.

Saya menggunakan Mentimun-js untuk mendorong Selenium. Baik lokal dan Browserstack

Saya menggunakan status pengujian (fitur, skenario, tag, hasil, dll) di kait untuk banyak hal penting.

• untuk memiliki perubahan URL khusus Skenario
• melewatkan tes secara dinamis berdasarkan konfigurasi browser saat ini
• Gunakan URL khusus skenario untuk merekam hasil pengujian kembali ke Browserstack
• Gunakan nama Fitur dan Skenario untuk menghasilkan nama sesi di Browserstack
• Parse tag untuk mengidentifikasi dan mengatur skenario resolusi browser tertentu

Semua ini dikemas dalam aplikasi untuk mengaktifkan instans bersamaan guna mengurangi waktu berjalan secara keseluruhan.

Mengapa ini dijatuhkan?
Apakah mereka tidak akan pernah kembali?

@gd46

Apakah skenario yang dijalankan melibatkan jenis profil tersebut? Mungkin Anda dapat membuat skenario menyimpan jenis profil apa yang berinteraksi dengan dunia dan kemudian Anda memiliki satu tag yang jelas yang meminta penghapusan profil yang disimpan?

@justusromijn

Untuk server tiruan Anda, bisakah Anda memindahkan pengaturan dari berbasis tag ke menggunakan langkah yang mendefinisikan apa pengaturannya? Kemudian Anda dapat membuat parameter dengan mudah.

@Jordyderuijter

Anda dapat mencatat baris skenario dan uri (yang sebenarnya unik dan mencegah Anda harus mencari nama skenario).

@leggebroten

untuk memiliki perubahan URL khusus Skenario

Anda dapat menggunakan langkah untuk ini sebagai gantinya atau menggunakan tag unik

melewatkan tes secara dinamis berdasarkan konfigurasi browser saat ini

Bagaimana Anda melewatkan tes secara dinamis? #912 menambahkan dukungan untuk ini

Gunakan URL khusus skenario untuk merekam hasil pengujian kembali ke Browserstack

Anda dapat menggunakan baris dan uri alih-alih nama. Seperti disebutkan sebelumnya, garis dan uri dijamin unik sedangkan namanya tidak. Saya juga menyarankan untuk menguraikan formatter json atau formatter protokol acara untuk hasil pengujian dan menggunakan lampiran jika Anda perlu menambahkan sesuatu.

Gunakan nama Fitur dan Skenario untuk menghasilkan nama sesi di Browserstack

Anda dapat menggunakan garis + URI

Parse tag untuk mengidentifikasi dan mengatur skenario resolusi browser tertentu

Anda dapat menggunakan langkah untuk ini.

Dari semua contoh ini, saya belum menemukan kasus penggunaan yang meyakinkan saya bahwa kita harus menambahkan kembali tag atau nama ke hook. Memiliki tag dan nama tampaknya telah membuat hal-hal tertentu lebih mudah dilakukan, tetapi saya pikir ada cara lain untuk mencapainya yang lebih masuk akal bagi saya

@charlierudolph terima kasih atas jawabannya. Untuk mockserver saya sudah mengobrol cepat dengan beberapa rekan kerja dan menggunakan "latar belakang" bersama sedang dipertimbangkan untuk solusi, jadi ya Anda bisa melewati salah satu daftar itu.

@charlierudolph Terima kasih atas jawabannya.

Meskipun saran Anda untuk menggunakan Langkah-langkah dan keluaran penguraian dapat dibuat untuk berfungsi, itu jauh lebih rendah daripada versi sebelumnya di mana panggilan balik memiliki akses ke Status pengujian.

0) Tidak konsisten dengan pola Pengamat. Panggilan balik harus diberikan data yang mereka butuhkan untuk perilaku yang mereka dukung

1) Menginduksi kerapuhan yang ekstrim . Tes harus dapat diandalkan atau tidak akan dipercaya. Nomor baris dan nama file berubah. Cukup menambahkan atau menghapus carriage return akan merusak tes.

2) Menggunakan Langkah untuk mengubah Status melanggar KERING. Pertimbangkan kasus penambahan pengujian A/B yang sering ditandai dengan Tag. Kecuali Anda menambahkan ekstensi baris perintah untuk menjalankan pengujian berdasarkan Langkah-langkah yang disertakan, pengujian akan memerlukan KEDUA Tag dan Langkah-langkah pendukungnya yang mengubah status.

3) Mengharuskan pengembang untuk melakukan pekerjaan ekstra. Mengurai keluaran untuk menemukan Status tidak perlu, membosankan, rawan kesalahan, mengikat tes ke format keluaran (Kopling buruk), dan melanggar KERING.

4) Tidak konsisten dengan Mentimun. Menambahkan Langkah (bagian semantik dari tes) untuk mengubah status Fitur bertentangan dengan maksud Mentimun untuk mengisolasi penulis tes. Jika perilaku tidak berubah, tes tidak akan berubah.

5) Tidak bersifat deklaratif. Tag adalah metadata TENTANG pengujian, secara semantik konsisten menggunakannya untuk mengubah status di mana pengujian akan dijalankan. Sedangkan Langkah-langkah tertanam dalam tes. Anda mengidentifikasi serangkaian tes berdasarkan Tag mereka … bukan Langkah yang mereka gunakan.

Oh, dan saya sebenarnya bukan "Melewati" tes, saya menggunakan callback( null, 'pending' ) untuk menghindari menjalankan tes. Fitur 'lewati' yang baru adalah solusi yang unggul.

@charlierudolph , saya berpikir, solusi lain ...
saat membuat objek Dunia, berikan referensi ke objek Skenario yang digunakan untuk pengujian.

Karena Dunia tersedia sebagai "ini" untuk semua panggilan balik, itu akan mencapai paritas penuh dengan V2 (asalkan panggilan balik AfterAll diberikan Hasil)

@leggebroten

1. Saya tidak pernah mendengar pola pengamat menjadi tujuan desain mentimun.
2. Nama skenario juga rapuh karena perubahan karakter tunggal juga mengubahnya. Saya setuju file / nomor baris istirahat ketika mengambil apa yang terasa seperti tindakan yang tidak terkait. Saya menyarankan penggunaan dalam pelaporan hasil dan bukan dalam menjalankan tes dan dengan demikian bagian rapuh tidak memiliki banyak efek negatif.
3. Using Steps to alter State violates DRY Saya tidak mengerti ini. Tag digunakan untuk memilih fitur dan langkah digunakan untuk penyiapan/tindakan/harapan. Ini adalah tujuan yang berbeda. Kami memiliki dukungan minimal untuk menggunakan tag untuk penyiapan dengan kait yang ditandai tetapi tidak dibuat untuk menangani kompleksitas.
4. Saya hanya menyarankan keluaran formatter parsing untuk pelaporan. Itu seharusnya tidak terlibat dalam menjalankan tes.
5. Adding Steps (a semantic part of the test) to alter the Feature's state is counter to intent of Cucumber of isolating test writer Saya juga tidak mengerti ini. Jika Anda tidak dapat menggunakan langkah-langkah untuk melakukan tindakan dan menetapkan status, bagaimana Anda menjalankan pengujian?
6. Tags are metadata ABOUT the test, it is semantically consistent to use them to alter the state in which the test will run . Saya tidak setuju tentang itu menjadi konsisten. Tag bagi saya hanya untuk mengidentifikasi tes. Ada dukungan untuk perubahan status yang minimal tetapi tidak untuk perubahan status yang kompleks dengan parameter.

Tidak ada lagi objek skenario dalam sistem. Saya tidak berpikir paritas dengan v2 harus menjadi tujuan. Saya senang percakapan ini muncul dan saya sedang mencari solusi lain tetapi saya tidak ingin kembali ke apa yang kami miliki sebelumnya karena saya percaya itu membuat pengguna lebih bergantung pada implementasi mentimun dan bukan pada antarmukanya.

@charlierudolph ,

Terima kasih telah meluangkan waktu untuk membahas masalah ini. Saya sangat menghargai pekerjaan yang telah Anda lakukan untuk memberi kami Cucumber-js. Tapi seperti berdiri saya tidak bisa meng-upgrade ke V3.

Saya tidak bermaksud untuk menjadi agresif. Saya hanya khawatir dan itu mungkin muncul dalam tanggapan saya.

Hanya menggunakan antarmuka Acara yang didokumentasikan dari versi sebelumnya, saya telah membangun kerangka kerja yang secara dramatis mengurangi waktu pengujian keseluruhan dengan memungkinkan Fitur dijalankan secara bersamaan di atas matriks pengujian besar yang dapat dikonfigurasi dengan menyertakan Sistem/Versi Operasi, Peramban/Versi, Desktop/ Seluler, dan Mengoptimalkan pengujian A/B.

Saya TIDAK BISA menggunakan Langkah. Sudah terlambat. Jenis perangkat, OS/versi dan browser/versi HARUS ditentukan sebelum tes dimulai atau setiap Skenario akan dipaksa untuk memiliki Langkah "pengaturan OS" dan Langkah "pengaturan Browser". Ini bertentangan langsung dengan tujuan Mentimun.

Atau, seperti yang saya sebutkan sebelumnya, Anda dapat memberikan informasi Skenario (URI Fitur, nama, baris, dan Tag) ke konstruktor Dunia. Ini secara semantik konsisten dengan maksud objek Dunia dan lebih sederhana untuk merangkum dan memperluas. Ini tidak hanya akan menghilangkan sebagian besar Penangan Acara saya, tetapi karena "ini" Handler adalah objek Dunia, itu adalah Negara yang konsisten dengan Pola Pengamat.

1. Saya tidak mengatakan bahwa Pola Pengamat adalah tujuan desain untuk Mentimun. Hanya bahwa Hooks and Events adalah Pengamat dan bahwa, dengan demikian, mereka harus diberi status yang mereka butuhkan untuk melakukan pekerjaan mereka. Pola ini memungkinkan pemisahan antara implementasi pemanggil dan event handler.

2. Saya tidak memiliki ketergantungan pada nama sebenarnya. Tetapi karena mereka unik, mereka adalah sarana untuk membangun nama sesi bermakna pengguna terkait di Browserstack.

3. Memiliki akses ke kumpulan Tag selama Sebelumnya, memungkinkan saya untuk membangun konstruksi yang dapat digunakan kembali untuk mengubah Status (seperti mengatur parameter URL Optimizely) tanpa mengubah pengujian (menambahkan Langkah). Ini berarti ada korelasi 1-1 antara tes yang ingin saya jalankan (Tag) dan penyiapannya. KERING.

4. Anda telah menyatakan keprihatinan bahwa pengembang menjadi tergantung pada implementasi, namun solusi Anda untuk menghapus Status Pengamat yang diperlukan adalah membuat pengembang bergantung pada implementasi lain (format file)? Bagaimana memaksa pengguna untuk melakukan pekerjaan penguraian file yang lebih membosankan, lambat, dan rawan kesalahan lebih baik daripada mengakses properti Negara?

5. Jelas Langkah-langkahnya adalah mengatur Status uji. Tetapi salah satu tujuan desain Mentimun adalah bahwa orang yang menulis Langkah-langkahnya harus diisolasi dari implementasi yang mendasarinya. EG menguji perilaku semantik tanpa terjebak dalam detail yang mendasarinya. Menambahkan Langkah untuk mengubah parameter kueri, dan mendefinisikan perangkat/browser/os, tampaknya bertentangan dengan tujuan ini.

6. Untuk Anda, Tag hanya tentang mengidentifikasi tes. Tapi Cucumber Wiki memiliki banyak kegunaan untuk tag.

7. Pengorganisasian dan pengelompokan
8. Filter (menjalankan set melalui baris perintah)
9. Tautan ke dokumen terkait (seperti tanda Optimizely)
10. Menunjukkan di mana dalam proses fitur tersebut

Memiliki akses ke Tag selama panggilan balik Sebelum memungkinkan saya memastikan status yang sesuai berdasarkan konfigurasi browser yang digunakan untuk mendorong pengujian. Menggunakan Tag membuat Deklaratif itu. Menggunakan Langkah mengaburkan Intent

Panggilan, dan parameter pengendali Acara di antarmuka ADALAH versi sebelumnya. Jika pengembang menggabungkan kode mereka dengan implementasi Anda yang bocor, berikan Proxy "Skenario" hanya-baca ke event handler.

@charlierudolph terima kasih atas balasan Anda

Nama skenario juga rapuh karena perubahan karakter tunggal juga mengubahnya. Saya setuju file / nomor baris istirahat ketika mengambil apa yang terasa seperti tindakan yang tidak terkait. Saya menyarankan penggunaan dalam pelaporan hasil dan bukan dalam menjalankan tes dan dengan demikian bagian rapuh tidak memiliki banyak efek negatif.

Benar, nama skenario juga rapuh, tetapi ini adalah cara yang jauh lebih rapuh untuk merujuk skenario daripada merujuknya dengan file dan baris. Kami menggunakan nama skenario dalam logging setiap hari untuk menganalisis kegagalan dalam proses dan melihat apa yang salah. Jika logging hanya menampilkan file dan nomor baris, itu akan menyebabkan terlalu banyak overhead untuk melacak kembali skenario. Selain itu, jika seseorang membuat perubahan pada file fitur atau memindahkan skenario ke tempat lain sementara itu, ini akan menjadi lebih rumit.

Jika logging hanya menampilkan file dan nomor baris, itu akan menyebabkan terlalu banyak overhead untuk melacak kembali skenario.

Bagaimana itu lebih di atas kepala? Anda tahu file dan nomor baris dan bisa langsung ke sana. Jika Anda memiliki nama skenario, Anda harus mencari string itu untuk dibawa ke file dan baris itu.

Bagaimana itu lebih di atas kepala? Anda tahu file dan nomor baris dan bisa langsung ke sana. Jika Anda memiliki nama skenario, Anda harus mencari string itu untuk dibawa ke file dan baris itu.

Seperti yang saya katakan, jika file fitur berubah sementara dan skenario tidak diposisikan pada baris itu lagi. Terutama ketika saya melihat-lihat log dari uji coba yang lebih lama (misalnya 1 minggu yang lalu). Dalam hal ini saya harus melalui git dan melihat skenario mana yang ada di baris itu pada waktu tertentu.

FWIW, mentimun-ruby memiliki dua poin ekstensi yang menurut saya memenuhi prinsip "hal yang mudah seharusnya mudah, hal yang sulit harus mungkin" dan mungkin ide yang dapat membantu kasus penggunaan ini.

Pertama-tama, kami meneruskan instance RunningTestCase ke setiap hook. Ini adalah objek nilai abadi yang berisi semua informasi tentang sumber Gherkin (skenario / garis besar / tag dll) ditambah status hasil skenario saat ini. Menjadi tidak berubah berarti kami terlindungi dari keharusan mempertimbangkan kasus di mana pengguna mungkin mencoba dan mengubah sesuatu pada kami, tetapi sama-sama memberi mereka transparansi tentang keadaan permainan saat ini.

Kedua, kami memiliki filter . Filter memungkinkan Anda untuk memanipulasi aliran kasus uji sebelum dieksekusi. Kami menggunakan filter untuk, misalnya, menghapus kasus pengujian dari aliran yang tidak cocok dengan pola tag yang ditentukan pada CLI. Filter adalah fitur power-user.

HTH

Saya baru menyadari bahwa dokumentasi di balik tautan untuk filter itu mengerikan! Maaf. Tidak ada waktu untuk memperbaikinya sekarang, tetapi ada beberapa contoh lagi di sini: http://www.rubydoc.info/github/cucumber/cucumber-ruby/Cucumber/Filters

Hai @charlierudolph ,

Maaf sudah lama sejak saya menindaklanjuti percakapan ini. Bisakah Anda menguraikan pernyataan Anda:

"Apakah skenario yang dijalankan melibatkan jenis profil itu? Mungkin Anda dapat meminta skenario menyimpan jenis profil apa yang berinteraksi dengan dunia dan kemudian Anda memiliki satu tag yang jelas yang meminta penghapusan profil yang disimpan?"

Saya tidak yakin saya mengikuti.

Dan saya mengerti mungkin ada cara lain untuk mendapatkan solusi yang sama tanpa hasil tes yang lama. Tetapi dari apa yang saya lihat sejauh ini dalam percakapan ini adalah bahwa semua alternatif tampak lebih kompleks daripada yang seharusnya. Hasil tes lama memiliki banyak data deskriptif tentang skenario yang akan dijalankan dan itu adalah satu-satunya cara untuk memiliki kait "berparameter". Busur derajat seperti yang saya lihat dan coba saat ini tidak mendukung menjalankan fitur dari nomor baris skenario. Jadi hasil testCase baru tidak memiliki banyak manfaat selain status.

Saya ingin melihat testCase cocok dengan hasil yang dikembalikan saat menggunakan getTestCasesFromFileSystem dengan PickleFilter. Saya telah menggunakan ini untuk melakukan beberapa pekerjaan paralel yang menarik untuk mendukung pemfilteran skenario dengan tag untuk diteruskan ke busur derajat sebagai pecahan. Informasi yang dikembalikan dari hasil itu jauh lebih berguna dan saya pikir akan sangat berguna untuk dimiliki dalam hasil testCase.

Contoh hasil dari PickFilter:

{ pickle: 
     { tags: [Object],
       name: 'Github test with page object',
       language: 'en',
       locations: [Object],
       steps: [Object] },
    uri: 'test/features/examples/github-example.feature' }

Saya tidak mengatakan itu harus sama persis, tetapi saya melihat banyak hal dalam hasil ini yang tampaknya akan diuntungkan oleh orang lain di sini dan saya.

Jika Anda menarik dalam contoh saya, saya menggunakannya di sini: https://github.com/gd46/dibellag-automation-framework/blob/master/configuration.js#L91

@charlierudolph Apakah ini tempat testCase diatur?

https://github.com/cucumber/cucumber-js/blob/fbff6b0fae54d2e341ee247addc60a9f05753f1d/src/formatter/helpers/event_data_collector.js#L22

Dari apa yang saya tahu ada referensi untuk acar di sepanjang sisi testCase. Jadi mengapa tidak mengembalikan beberapa bit lagi dari hasil acar ke hasil testCase?

@gd46 oke, mari tambahkan pickle ke objek yang diteruskan ke kait menggantikan sourceLocation. Itu perlu diperbarui dalam fungsi ini: https://github.com/cucumber/cucumber-js/blob/master/src/runtime/test_case_runner.js#L153

Hai @charlierudolph , saya baru saja melihat komentar Anda. Itu bagus! Saya akan mencoba untuk melihat ini segera. Saya akan dengan senang hati memberikan kontribusi.

@charlierudolph Hanya ingin mengklarifikasi perubahan. Apakah kami setuju dengan perbedaan bahwa acar berisi uri tanpa nomor baris langsung di atasnya seperti yang dilakukan sourceLocation. Dan jika siapa pun yang ingin mengonsumsi uri dengan nomor baris, mereka dapat menggunakan nomor baris yang dikembalikan dari objek acar? Saya tidak melihat masalah dengan ini hanya ingin mengonfirmasi.

Saya kira mari kita biarkan objek lokasi sumber apa adanya (alih-alih menghapusnya) dan menambahkan objek acar.

Ok itu bekerja untuk saya juga. Jadi saya baru berkontribusi pada mentimun, saya masih mencoba memahami strukturnya.

Seperti yang telah Anda tunjukkan pada baris yang perlu diperbarui, saya yakin kita bisa menambahkan sesuatu seperti ini di sebelah sourceLocation:

pickle: this.testCase.pickle

Kemudian siapa saja yang ingin mengkonsumsinya di hook dapat mengaksesnya sebagai berikut:

testCase.pickle.tags
testCase.pickle.name
etc. 

Saya telah melakukan pembaruan tetapi saya tidak 100% yakin bagaimana memperbarui semua tes terkait. Apakah Anda dapat memberikan beberapa panduan?

Saya dapat menguji perubahan dengan menautkan garpu saya dengan perubahan ke salah satu proyek lokal saya. Hasil testCase lengkap akan terlihat seperti ini:

{
  "sourceLocation": {
    "uri": "test\/features\/examples\/example.feature",
    "line": 4
  },
  "pickle": {
    "tags": [
      {
        "name": "@example",
        "location": {
          "line": 3,
          "column": 3
        }
      }
    ],
    "name": "Custom Transform should take belly and capitalize it",
    "language": "en",
    "locations": [
      {
        "line": 4,
        "column": 3
      }
    ],
    "steps": [
      {
        "text": "I have cucumbers in my belly",
        "arguments": [

        ],
        "locations": [
          {
            "line": 5,
            "column": 10
          }
        ]
      }
    ]
  },
  "result": {
    "duration": 7,
    "status": "passed"
  }
}

Setelah melakukan beberapa pengujian lagi, saya perhatikan bahwa acar tidak mengandung uri pada saat kami mengaksesnya di test_case_runner. Jadi saya pikir tidak apa-apa untuk menjaga lokasi sumber apa adanya.

Inilah yang PickleFilter mengembalikan acar sebagai:

{
    "pickle": {
      "tags": [
        {
          "name": "@example",
          "location": {
            "line": 3,
            "column": 3
          }
        }
      ],
      "name": "Custom Transform should take belly and capitalize it",
      "language": "en",
      "locations": [
        {
          "line": 4,
          "column": 3
        }
      ],
      "steps": [
        {
          "text": "I have cucumbers in my belly",
          "arguments": [

          ],
          "locations": [
            {
              "line": 5,
              "column": 10
            }
          ]
        }
      ]
    },
    "uri": "test\/features\/examples\/example.feature"
  }

Jadi semuanya akan sama minus acar yang tidak mengandung uri.

Membuka PR untuk menyoroti perubahan sejauh ini. Masih perlu memperbarui tes.

Bekerja pada memperbarui tes. Saya memiliki pengaturan hal ini untuk mengubah versi Java lokal saya dan menyadari itulah mengapa saya tidak dapat menjalankan beberapa tes fitur:/.

Utas ini telah dikunci secara otomatis karena tidak ada aktivitas terbaru setelah ditutup. Silakan buka edisi baru untuk bug terkait.