Cucumber-js: Bagaimana saya bisa menentukan file definisi langkah untuk setiap file fitur?

Dibuat pada 2 Feb 2017  ·  18Komentar  ·  Sumber: cucumber/cucumber-js

Tujuanku

Saya mencoba membuat struktur fitur dan definisi langkah yang dapat diskalakan untuk aplikasi besar dan bidikan pertama saya mencoba menautkan file step_definition ke fitur sehingga saya dapat menggunakan pola langkah yang sama untuk definisi langkah yang berbeda.

Kode saya

Saya menunjukkan contoh saya saat ini:

Struktur folder saya:

/features/sample.feature
/features/example.feature
/features/step_definitions/sample_steps.js
/features/step_definitions/example_steps.js
/features/step_definitions/common/common_steps.js

Di sample.feature saya, saya memiliki:

  Scenario: Launching Cucumber
  Given I have some step definitions
   When I check some step definition with parameter "any"
   Then I should see all green "sample"

Di example.feature saya, saya punya:

  Scenario: Launching Cucumber
  Given I have some step definitions
   When I check some step definition with parameter "any"
   Then I should see all green "example"

Langkah Given dan When didefinisikan pada file /common/common_steps.js dan berfungsi dengan baik.

Langkah Then didefinisikan baik untuk sample_steps.js dan example_steps.js tetapi berbeda.

Di sample_steps.js saya, saya punya:

Then('I should see all green {stringInDoubleQuotes}', (arg) => {
   if (arg !== 'sample') {
     throw 'I should see all green when the argument is "sample"';
   }
   return;
 });

Dan, akhirnya, di example_steps.js saya, saya memiliki:

Then('I should see all green {stringInDoubleQuotes}', (arg) => {
   if (arg !== 'example') {
     throw 'I should see all green when the argument is "example"';
   }
   return;
 });

Kesalahan

Tujuan utama saya adalah memiliki semua hijau di sini, tetapi tentu saja, itu tidak berfungsi dan saya mendapatkan kesalahan ini:

Multiple step definitions match:
   I should see all green {stringInDoubleQuotes} - features\step_definitions\example_steps.js:6
   I should see all green {stringInDoubleQuotes} - features\step_definitions\sample_steps.js:6

Mentimun-JVM

Saya tahu bahwa dalam mentimun-jvm kita dapat menentukan atribut glue yang menautkan fitur dan step_definitions dan itulah yang saya cari, tetapi dalam mentimun-js. Contoh di Jawa:

@RunWith(Cucumber.class)
@Cucumber.Options( glue = { "com.app.stepdefinitions.common", "com.app.stepdefinitions.sample" } )
public class SampleFeature{
}

@RunWith(Cucumber.class)
@Cucumber.Options( glue = { "com.app.stepdefinitions.common", "com.app.stepdefinitions.example" } )
public class ExampleFeature{
}

Akhirnya

Bagaimana saya bisa mencapai hal yang sama dengan mentimun-jvm menggunakan mentimun-js?

Komentar yang paling membantu

Pelingkupan IMO pasti dibutuhkan. Seiring pertumbuhan aplikasi Anda, jumlah fitur bertambah dan Anda akan berakhir dengan deskripsi yang bertentangan dalam konteks yang berbeda.

Di perusahaan saya, produk kami memiliki ratusan fitur dan QA memiliki kasus uji dalam kisaran 100k.
Jika kita menggunakan cucumber kita pasti akan mengalami masalah ini.

Ya, saya pikir Anda harus mempertimbangkan konteks alih-alih pelingkupan.
Anda dapat memiliki sebagian besar, jika tidak semua, definisi langkah Anda dalam konteks default (atau tanpa konteks), tetapi harus ada cara untuk menentukan konteks tanpa memerlukan DSL khusus.

BA dan QA-lah yang seharusnya menulis tes ini dan setiap DSL khusus terikat untuk menciptakan kebingungan dan penolakan.

Fitur/Skenario sudah menyediakan konteks menurut definisi, itu sebabnya sintaks Gherkin memiliki lekukan.

Menambahkan tag dan DSL khusus adalah solusi dari batasan implementasi (yaitu peretasan, IMO) alih-alih solusi.

Mungkin Anda dapat mempertimbangkan ini sambil mempertimbangkan https://github.com/cucumber/cucumber-js/issues/745 ?

Bagaimana dengan memperluas Scenario dari defineStep dan meneruskan {Given, When, Then} ke dalam panggilan balik?

yaitu:

import {defineSupportCode} from 'cucumber'

defineSupportCode(({ Scenario, Given, When, Then }) => {
  Given(...)
  When(...)
  Then(...)
  Scenario('<match scenario description>', ({ Given, When, Then}) => {
    Given('<take precedent of non-contexted>', ...)
    ...
  })
})

Semua 18 komentar

Saya mencoba membuat struktur fitur dan definisi langkah yang dapat diskalakan untuk aplikasi besar dan bidikan pertama saya mencoba menautkan file step_definition ke fitur sehingga saya dapat menggunakan pola langkah yang sama untuk definisi langkah yang berbeda.

Sangat menarik. mentimun-js tidak memiliki bawaan seperti contoh mentimun-java yang Anda berikan. Ide yang saya suka untuk hal semacam ini, mendorong peralihan logika ini ke pengaturan dunia atau instance Anda. Either way Anda berakhir dengan hanya satu definisi langkah. Anda dapat memiliki beberapa definisi dunia yang dapat Anda alihkan saat menentukan kode dukungan atau memiliki satu instans dunia yang menampilkan metode berbeda berdasarkan konteks. Saat ini kami tidak mengekspos file skenario saat ini untuk menjalankan langkah-langkah tetapi Anda dapat menggunakan tag untuk menentukan konteks Anda.

Kami sebenarnya memiliki kebutuhan yang sama untuk ini. Kami menggunakan nightwatch-cucumber untuk menjalankan tes selenium dan satu-satunya solusi kami untuk saat ini adalah menambahkan awalan ke setiap langkah:

Given [comp1] I click on "Open dialog"

vs

Given [comp2] I click on "Open dialog"

Ini membantu kami menghindari definisi langkah yang ambigu, tetapi mengarah ke file fitur yang benar-benar tidak dapat dibaca.
Saya mencoba mengutak-atik sumber mentimun.js, tetapi tidak menemukan petunjuk bagus untuk menambahkan dukungan untuk fitur ini.

Bisakah ini diwujudkan dengan beberapa kait atau Dunia alternatif?

@leipert antarmuka pengguna apa yang Anda bayangkan? Saya percaya logika ini harus hidup di dunia atau mendukung banyak objek dunia. Kemudian definisi langkah hanya berurusan dengan penguraian kecocokan ketimun dan meneruskannya ke fungsi dunia yang tepat. Kita dapat menambahkan opsi CLI untuk memilih objek dunia mana yang akan digunakan.

Untuk saat ini jika Anda ingin memiliki beberapa definisi dunia/langkah, Anda dapat mencapainya dengan meletakkan kode Anda di folder terpisah dan hanya membutuhkan satu dari mereka per proses (menggunakan opsi --require CLI).

Nah, "buku mentimun" secara khusus melarang cara merancang langkah-langkah ini. Langkah dibagi antara skenario dengan desain, kalimat yang sama harus memiliki makna yang konsisten terlepas dari fitur yang menggunakannya. Setelah Anda memperkenalkan cakupan langkah, sangat mudah untuk membuat jebakan bahasa.

Sejauh ini hanya tag yang mendekati tujuan Anda di cucuber.js. Tetapi hanya kait yang dapat mendeklarasikan bahwa mereka khusus untuk tag. Jika Anda yakin itu cara yang tepat untuk orang-orang Anda, Anda dapat membuat DSL, mungkin sederhana seperti [nama fitur] dalam pola langkah.

Terima kasih, @pinxue . Respon yang sangat berguna. Namun, saya tidak dapat memahaminya:

Nah, "buku mentimun" secara khusus melarang cara merancang langkah-langkah ini.

Frasa tindakan yang sama dapat memiliki arti yang berbeda dalam konteks yang berbeda. Tapi tidak apa-apa. Ada baiknya mengetahui opsi yang saya miliki, Sebenarnya, kami sudah berjalan di DSL internal untuk mencapainya,

Terima kasih banyak.

Terima kasih atas jawaban Anda @pinxue dan @robsonrosa.
Inilah alasan saya untuk definisi langkah cakupan:

  1. _Variabel global buruk dan tidak berskala_:
    Kami hanya memiliki sekitar 15 file file fitur dengan masing-masing 10 skenario, dan sudah sulit untuk menyusun semua definisi langkah dan file fitur. Untuk aplikasi besar (misalnya 100 file fitur dengan 10 skenario dengan rata-rata 5 Langkah) memiliki semua langkah yang ditentukan secara global tampaknya gila, karena sangat sulit untuk melacak file fitur mana yang menggunakan langkah mana.
  2. _Pengembang tidak memiliki kendali atas kata-kata dalam file fitur_:
    Dalam kasus penggunaan kami, "manajemen" kami menulis file fitur, sulit untuk menjualnya: Kami melakukan BDD yang luar biasa, tetapi Anda harus membatasi diri pada DSL khusus yang canggung.
  3. _Jika mentimun-jvm memiliki opsi, mengapa mentimun-js tidak ?_
    Ini mungkin argumen yang buruk

Saya melihat pendekatan berikut untuk memecahkan masalah bagi kami:

  1. Buat DSL khusus dengan awalan dalam definisi langkah
    Kekurangan: Tidak enak untuk diajak bekerja sama.
    Kelebihan: tidak perlu mengubah mentimun.js
  2. Buat glue untuk mentimun.js
    Kontra: Mungkin bertentangan dengan gagasan "Buku Mentimun".
    Kelebihan: Fitur paritas dengan cucumber.js
  3. Ubah cara kami menjalankan tes
    Kekurangan: Fitur ini akan tersedia untuk lebih sedikit orang.
    Kelebihan: tidak perlu mengubah mentimun.js

Karena itu, kami mungkin akan menggunakan 3., jika pengelola mentimun.js menganggap definisi langkah tercakup di luar cakupan (permainan kata-kata) untuk proyek ini.

@robsonrosa Saya akan tertarik dengan solusi Anda, setelah Anda memilikinya.

Pelingkupan IMO pasti dibutuhkan. Seiring pertumbuhan aplikasi Anda, jumlah fitur bertambah dan Anda akan berakhir dengan deskripsi yang bertentangan dalam konteks yang berbeda.

Di perusahaan saya, produk kami memiliki ratusan fitur dan QA memiliki kasus uji dalam kisaran 100k.
Jika kita menggunakan cucumber kita pasti akan mengalami masalah ini.

Ya, saya pikir Anda harus mempertimbangkan konteks alih-alih pelingkupan.
Anda dapat memiliki sebagian besar, jika tidak semua, definisi langkah Anda dalam konteks default (atau tanpa konteks), tetapi harus ada cara untuk menentukan konteks tanpa memerlukan DSL khusus.

BA dan QA-lah yang seharusnya menulis tes ini dan setiap DSL khusus terikat untuk menciptakan kebingungan dan penolakan.

Fitur/Skenario sudah menyediakan konteks menurut definisi, itu sebabnya sintaks Gherkin memiliki lekukan.

Menambahkan tag dan DSL khusus adalah solusi dari batasan implementasi (yaitu peretasan, IMO) alih-alih solusi.

Mungkin Anda dapat mempertimbangkan ini sambil mempertimbangkan https://github.com/cucumber/cucumber-js/issues/745 ?

Bagaimana dengan memperluas Scenario dari defineStep dan meneruskan {Given, When, Then} ke dalam panggilan balik?

yaitu:

import {defineSupportCode} from 'cucumber'

defineSupportCode(({ Scenario, Given, When, Then }) => {
  Given(...)
  When(...)
  Then(...)
  Scenario('<match scenario description>', ({ Given, When, Then}) => {
    Given('<take precedent of non-contexted>', ...)
    ...
  })
})

Saya belajar BDD dari http://fitnesse.org/ jadi saya mungkin melihat BDD secara berbeda dari komunitas mentimun.

Halaman @richardlawrence

Ini adalah area di mana Mentimun sangat berpendirian. Itu dibangun di sekitar keyakinan bahwa tim harus menumbuhkan bahasa yang ada di mana-mana, di mana kata dan frasa berarti satu hal dalam konteks aplikasi dan digunakan secara konsisten. Menjaga langkah defs global mempertahankan tekanan positif untuk menghindari ambiguitas.

Dalam kasus yang jarang terjadi di mana aplikasi memiliki beberapa konteks terbatas yang berbeda (dalam istilah DDD), Anda cukup membagi suite Mentimun Anda di sepanjang baris yang sama dengan aplikasi Anda dibagi untuk mencerminkan batas itu, dan langkah def akan menjadi global dalam setiap konteks yang dibatasi.

Artikel tentang bekerja dengan Mentimun dan membuat batasan. Ini mengimplementasikan beberapa ide di halaman ini tetapi tidak menyajikan solusi hebat apa pun karena @richardlawrence telah menyebutkan bahwa Anda tidak dapat mengonfigurasi Mentimun untuk fokus pada satu kelas tertentu untuk definisi langkah. http://confessionsofanagilecoach.blogspot.com/2017/05/teaching-cucumbers-about-boundaries.html

Seperti yang dikatakan @leipert , variabel global buruk. Saya pikir kita di dunia CucumberJVM hanya mendapatkan setengah dari cerita. Mentimun (non JVM) menggunakan konsep Dunia rapi yang merupakan ruang memori global selama Skenario . Setelah Skenario dijalankan, itu dihancurkan. Ini terasa seperti solusi yang bagus. Tapi... Saya tidak melihat implementasi yang baik dari pola ini di CucumberJVM. Jadi jika Mentimun memaksa kita untuk memiliki namespace datar/global untuk definisi langkah, dan CucumberJVM memiliki pola desain yang jelas untuk menerapkan pola Dunia, maka saya sedikit lebih bahagia. Hingga saat ini, CucumberJVM + Pola dunia == solusi yang terlalu rumit. Sejauh ini, semua yang saya lihat lebih rumit daripada sekadar membiarkan saya mengontrol fungsi langkah mana yang sesuai dengan file fitur mana. Sejauh ini alternatif yang saya lihat tidak memberi saya apa pun yang lebih berharga untuk semua upaya/kompleksitas. Jenis Mentimun lainnya memiliki solusi Dunia yang lebih baik.

Pada akhirnya, bahkan dengan pola Dunia saya masih tidak senang karena saya tahu akan ada kehilangan informasi saat beralih dari file fitur ke langkah. Jika saya berusaha keras: meletakkan file fitur saya di organisasi yang baik, membuat nama file fitur yang bagus, mendeklarasikan fitur saya dengan cara yang cerdas, menamai skenario saya dengan cara yang cerdas--semua konteks dibuang ke luar jendela dan saya dipaksa untuk bekerja dengan namespace definisi langkah global.

Saya hanya bisa berpikir untuk menjaga hubungan di luar validasi sistem dan cukup menambahkan wildcard di jalur untuk pengujian, dan membuatnya berfungsi, bahkan jika perlu memodifikasi beberapa kerangka kerja sumber terbuka. mungkin mencobanya saat proyek kami berkembang.

Saya memahami tujuan Anda, tetapi saya tidak akan merekomendasikannya.
Saya juga merekomendasikan memiliki file .feature eksplisit, dengan pernyataan latar belakang atau langkah tambahan yang diberikan yang membuat ini eksplisit.

Atau Anda dapat membuat dua file konfigurasi yang berbeda.
Satu untuk sampel dan satu lagi untuk contoh.
Kemudian Anda bisa menunjuk ke folder langkah yang berbeda.

@robsonrosa @leipert Saya berbagi pendapat Anda
Hampir dua tahun setelah posting asli...
Apakah Anda mendapatkan kemajuan dengan itu? Ada solusi?

@cristianmercado19 Maaf, tidak. Saya tidak menggunakan mentimun js lagi.

Ups... Saya suka cara menulis file fitur yang sepenuhnya terisolasi dari implementasi langkah.
Saya telah mencoba mencapai tujuan yang sama dengan _mocha_ tetapi saya tidak puas.
Jika Anda mendapatkan alternatif lain yang sesuai dengan tujuan saya, dengan senang hati akan mencobanya.
Hargai bantuan Anda @leipert .

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

Apakah halaman ini membantu?
0 / 5 - 0 peringkat