ジェストゲージ、ゲージのような自然言語で受け入れテストを書く
6028 ワード
TLドクター
私は、あなたが受験テスト駆動開発を実践することができるゲージに類似した自然言語で受け入れテストを書くことができるJest拡張をリリースしましたATDD
https://github.com/tnzk/jest-gauge
受入れテスト駆動開発（ATDD）とは何か
アクセプタンステスト駆動開発は、TDDと呼ばれるテスト駆動開発から派生したソフトウェア開発方法論である.TDDは、クラスやモジュールを期待するものを記述することに焦点を当てたTDDとは対照的に、ATDDは、より大きな意味で、全体として対象システムの受け入れ基準を記述することを推奨します.
大まかに言えば、TDDとE 2 EテストをそれぞれATTDDでテストしている.
Behavior-Driven Development, BDD, is another methodology which also derives from TDD .BDDはTDDと同じフィードバックサイクルを共有しますが、クラスまたはモジュールの「振舞い」を定義することに集中します.さらに重要なことは、BDDに参加するには様々なステークホルダーに参加します.プログラマーがうまくやって仕事を得るための実践として設計され、進化しているTDDとは異なり、BDDは「3つのアミーゴス」によって、どのような価値が顧客に届けるべきかを定義するためにユーザーストーリーを記述することに重点を置きます.
自分自身によるユーザーストーリーは、彼らが自然言語でちょうど若干の明白な文である時から、ソフトウェアテストのフィードバックサイクルをドライブすることができません.しかしながら、テストコードの1つとして期待された振舞いを直接的に表現することは、非プログラマがセッションに参加するのを防ぎます.
このジレンマを克服するために、キュウリ(よく知られているBDDフレームワーク)はGARKINと呼ばれるDSLを提供します.Gharkinのように何かを書くことができます“顧客として、銀行のテラーの行に立って避けるために、私はATM経由で現金を引き出すには、”よく知られているユーザーストーリーのテンプレートに似ています.これは、コード化しないステークホルダーに理解できます.
“Discovery workshop”は、彼らは、ビジネスの所有者の視点から製品への「受諾基準」、すなわち言い換えれば、ドメイン定義とほとんど同一です.ATDDに対する動機は、これらのアクセプタンス基準をAs Daniel North explained was inspired by Ubiquitous Language by Eric Evansで定義することによって、ソフトウェア開発をどのように推進するかという問題である.
ソフトウェアの実行可能仕様
なぜゲージ？
上記の説明を通して、BDDとATDDはそれほど大きくは見えないかもしれません.もしそうなら、我々はマイナーなミスマッチを脇にできる限り、我々は、キュウリをATDDを駆動するために使用することはできませんか?
Dealbreakerは、Gerkinが近い観察で自然言語でないという事実です、しかし、ゆるく定義された正式な言語.自然言語で書かれているように完成した例として、実際に書かれているように見えますが、書くことになると、コード化しないステークホルダーはそれを書くのが非常に難しいことを発見しました(プログラマももちろん、私を含むプログラマは、プログラマがいなくても簡単にRSspecや何かを書くことができますが、実際にはそうではありません.
あなたが行動定義を書くgherkinの構文は、実際には、自然言語ではなく、わずかに正式に制約されます.
ゲージでは、自然言語で文字通り書くことができます.仕様ファイル自体がMarkdownのサブセットとして定義される間、内部の文はちょうど人間の言語の線です.
# Top page Specification
You can explain freely the background or motivation of the specification, since paragraphs here will be ignored as just comments.
## Scenario: a user can open a site and see the top page.
- Open "https://duckduckgo.com/".
- It shows a picture of a cute Cucumber-looking bird to the user.
テストを実行するには、ゲージは、指定された行に対応するためのタイトルによる実装を正確に一致させます.あなたが好きなようにいくつかの堅牢さにそれを与えるためにテンプレート変数を挿入することができますが、順番にそれは文章を形式的な言語のようになります.Gerkinとは異なり、これらの変数やその他の同様のメカニズムを使用したり、使用したりすることで、言語の厳密性を微調整することができます.
私はゲージに興味があるので、それは自由形式の自然言語で仕様と受諾基準を書くことができます.
なぜ冗談のゲージ？
ゲージは私に少し独断的に思えました、そして、それが既存の製品に統合するために重い持ち上げを必要とすると感じました.「ねえ、みんな、ゲージにテストフレームワークを切り替える必要があります!」JESTでのユニット/E 2 Eテストに慣れていたチームメンバーに.
私は、私は本格的なATDDをナビゲートするために将来的にゲージを必要とすると仮定しますが、この時の私の主な動機は、“ATDDは良いかどうかよりも狭い何か?”「ゲージのような自然言語の仕様は、開発者と非開発者の間のコミュニケーションを導く触媒であるでしょうか?」
それで、私はATDDを簡単に試すためにJESTで既存のUnit/E 2 Eテストでチームのためにツールを構築し始めました.
many programmers share
インストールと使用のために、
を参照してください.
JEST拡張モジュールであるため、jest.config.jsに設定を追加することで試してみることができます.上記の仕様については、次のようなテストレポートを示します.
$ npx jest --config=jest.config.gauge.js specs/
PASS examples/welcome.spec
Top page Specification
Scenario: a user can open a site and see the top page.
✓ Open "https://duckduckgo.com/"
✓ It shows a picture of a cute Cucumber-looking bird to the user.
Test Suites: 1 passed, 1 total
Tests: 2 passed, 2 total
Snapshots: 0 total
Time: 0.913 s
それはゲージの機能の大部分をサポートしていますが、もちろんまだサポートされていない多くのことがあります.何がサポートされ、何がhttps://github.com/tnzk/jest-gaugeではないかを見つけることができます.
リードミー
動機
日本でコーディングブートキャンプをしています.我々は構築し、ゼロからの内部使用のための学習管理システムを維持しています.私たちは、非技術スタッフとして働いているプロジェクトのステークホルダーを持っています、そして、彼らは大きくて複雑なExcelスプレッドシートとして、ブートキャンプで教育活動を運営するために何が重要であるかについて、非常に生で事実上のニーズを持ちます!それは私がそれらを整理し、作業ソフトウェアとして出荷を維持する方法をさまよっていた.
私はステークホルダーを「我々はコーディング・ブートキャンプだ」と納得させようとしたので、リスクを取り、ソフトウェア開発方法論に新しいことを試みるべきです.私は、これがビジネスの他のドメインで受け入れられる大きい質問の種類であるということを知っていました.開発者もこれに驚いている.それで、私は同僚にこれを受け入れるために、暖かい感謝を言わなければなりません.
少し接線的で、それは唯一のストレッチではなかった.我々は、講義とテクニカルサポートセッションが行われるLMSにWebBTCとゼロからビデオチャット機能を構築しました.下記のスクリーンショットは私たちです.我々がアゴラとズームAPIのような有名な製品に頼らないので、接続性を安定させるために、それは多くの努力をします、そして、もちろん、我々は多くの洞察を学んで、チーム統一を増やしました.
TODO section in README
それで、ゲージ自体を結論した後に、ゲージ自体が我々のチームのためでないと結論した後に、JESTゲージを造ることに決めました.そして、私たちのCIは、毎日私たちの母国語で書かれた受け入れテストを実行します.
はい、これは私たちの誇る生産事例です.
我々は大きなcoと上記の背景ではないので、冗談を脇に、我々はリスクを受け入れる.ラフなエッジがたくさんありますので、ご自身の責任でご使用ください.
結論
上記のこれらの経験、およびAtddの
のような本は、開発者や他の利害関係者が行動説明やユビキタス言語で、10年前にコミュニケーションを通じてコミュニケーションをとるのは時期尚早かもしれない、という信念を持っている.
コードプラットフォームのような技術と物事の重要性の増加は、これを変えるかもしれません.我々は、議論することができて、製品が何であるかを共有することができて、ゲージまたはキュウリのような半形式の言語でなければならないかもしれません.
コーディング・ブートキャンプを実行する会社のメンバーは、おそらく必然的に、コンピュータとソフトウェアの比較的良い理解をしているように見えます.これはATDDを比較的少ない摩擦で採用した理由かもしれない.私たちは今ここでJestゲージを使用してATDDを練習し、その後のソフトウェアとの関連性の低い他の分野への洞察を転送します.
しかし、これはちょうど試みです.たぶん、それは動作します.あなたがジェストゲージを試してみて、いくつかの洞察を得た場合は、私とそれを共有してください.もちろん、どんな貢献も暖かく歓迎されます.
Reference
この問題について(ジェストゲージ、ゲージのような自然言語で受け入れテストを書く), 我々は、より多くの情報をここで見つけました
https://dev.to/tnzk/jest-gauge-a-jest-extension-to-write-acceptance-tests-in-natural-languages-similar-to-gauge-lie
テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol
アクセプタンステスト駆動開発は、TDDと呼ばれるテスト駆動開発から派生したソフトウェア開発方法論である.TDDは、クラスやモジュールを期待するものを記述することに焦点を当てたTDDとは対照的に、ATDDは、より大きな意味で、全体として対象システムの受け入れ基準を記述することを推奨します.
大まかに言えば、TDDとE 2 EテストをそれぞれATTDDでテストしている.
Behavior-Driven Development, BDD, is another methodology which also derives from TDD .BDDはTDDと同じフィードバックサイクルを共有しますが、クラスまたはモジュールの「振舞い」を定義することに集中します.さらに重要なことは、BDDに参加するには様々なステークホルダーに参加します.プログラマーがうまくやって仕事を得るための実践として設計され、進化しているTDDとは異なり、BDDは「3つのアミーゴス」によって、どのような価値が顧客に届けるべきかを定義するためにユーザーストーリーを記述することに重点を置きます.
自分自身によるユーザーストーリーは、彼らが自然言語でちょうど若干の明白な文である時から、ソフトウェアテストのフィードバックサイクルをドライブすることができません.しかしながら、テストコードの1つとして期待された振舞いを直接的に表現することは、非プログラマがセッションに参加するのを防ぎます.
このジレンマを克服するために、キュウリ(よく知られているBDDフレームワーク)はGARKINと呼ばれるDSLを提供します.Gharkinのように何かを書くことができます“顧客として、銀行のテラーの行に立って避けるために、私はATM経由で現金を引き出すには、”よく知られているユーザーストーリーのテンプレートに似ています.これは、コード化しないステークホルダーに理解できます.
“Discovery workshop”は、彼らは、ビジネスの所有者の視点から製品への「受諾基準」、すなわち言い換えれば、ドメイン定義とほとんど同一です.ATDDに対する動機は、これらのアクセプタンス基準をAs Daniel North explained was inspired by Ubiquitous Language by Eric Evansで定義することによって、ソフトウェア開発をどのように推進するかという問題である.
ソフトウェアの実行可能仕様
なぜゲージ？
上記の説明を通して、BDDとATDDはそれほど大きくは見えないかもしれません.もしそうなら、我々はマイナーなミスマッチを脇にできる限り、我々は、キュウリをATDDを駆動するために使用することはできませんか?
Dealbreakerは、Gerkinが近い観察で自然言語でないという事実です、しかし、ゆるく定義された正式な言語.自然言語で書かれているように完成した例として、実際に書かれているように見えますが、書くことになると、コード化しないステークホルダーはそれを書くのが非常に難しいことを発見しました(プログラマももちろん、私を含むプログラマは、プログラマがいなくても簡単にRSspecや何かを書くことができますが、実際にはそうではありません.
あなたが行動定義を書くgherkinの構文は、実際には、自然言語ではなく、わずかに正式に制約されます.
ゲージでは、自然言語で文字通り書くことができます.仕様ファイル自体がMarkdownのサブセットとして定義される間、内部の文はちょうど人間の言語の線です.
# Top page Specification
You can explain freely the background or motivation of the specification, since paragraphs here will be ignored as just comments.
## Scenario: a user can open a site and see the top page.
- Open "https://duckduckgo.com/".
- It shows a picture of a cute Cucumber-looking bird to the user.
テストを実行するには、ゲージは、指定された行に対応するためのタイトルによる実装を正確に一致させます.あなたが好きなようにいくつかの堅牢さにそれを与えるためにテンプレート変数を挿入することができますが、順番にそれは文章を形式的な言語のようになります.Gerkinとは異なり、これらの変数やその他の同様のメカニズムを使用したり、使用したりすることで、言語の厳密性を微調整することができます.
私はゲージに興味があるので、それは自由形式の自然言語で仕様と受諾基準を書くことができます.
なぜ冗談のゲージ？
ゲージは私に少し独断的に思えました、そして、それが既存の製品に統合するために重い持ち上げを必要とすると感じました.「ねえ、みんな、ゲージにテストフレームワークを切り替える必要があります!」JESTでのユニット/E 2 Eテストに慣れていたチームメンバーに.
私は、私は本格的なATDDをナビゲートするために将来的にゲージを必要とすると仮定しますが、この時の私の主な動機は、“ATDDは良いかどうかよりも狭い何か?”「ゲージのような自然言語の仕様は、開発者と非開発者の間のコミュニケーションを導く触媒であるでしょうか?」
それで、私はATDDを簡単に試すためにJESTで既存のUnit/E 2 Eテストでチームのためにツールを構築し始めました.
many programmers share
インストールと使用のために、
を参照してください.
JEST拡張モジュールであるため、jest.config.jsに設定を追加することで試してみることができます.上記の仕様については、次のようなテストレポートを示します.
$ npx jest --config=jest.config.gauge.js specs/
PASS examples/welcome.spec
Top page Specification
Scenario: a user can open a site and see the top page.
✓ Open "https://duckduckgo.com/"
✓ It shows a picture of a cute Cucumber-looking bird to the user.
Test Suites: 1 passed, 1 total
Tests: 2 passed, 2 total
Snapshots: 0 total
Time: 0.913 s
それはゲージの機能の大部分をサポートしていますが、もちろんまだサポートされていない多くのことがあります.何がサポートされ、何がhttps://github.com/tnzk/jest-gaugeではないかを見つけることができます.
リードミー
動機
日本でコーディングブートキャンプをしています.我々は構築し、ゼロからの内部使用のための学習管理システムを維持しています.私たちは、非技術スタッフとして働いているプロジェクトのステークホルダーを持っています、そして、彼らは大きくて複雑なExcelスプレッドシートとして、ブートキャンプで教育活動を運営するために何が重要であるかについて、非常に生で事実上のニーズを持ちます!それは私がそれらを整理し、作業ソフトウェアとして出荷を維持する方法をさまよっていた.
私はステークホルダーを「我々はコーディング・ブートキャンプだ」と納得させようとしたので、リスクを取り、ソフトウェア開発方法論に新しいことを試みるべきです.私は、これがビジネスの他のドメインで受け入れられる大きい質問の種類であるということを知っていました.開発者もこれに驚いている.それで、私は同僚にこれを受け入れるために、暖かい感謝を言わなければなりません.
少し接線的で、それは唯一のストレッチではなかった.我々は、講義とテクニカルサポートセッションが行われるLMSにWebBTCとゼロからビデオチャット機能を構築しました.下記のスクリーンショットは私たちです.我々がアゴラとズームAPIのような有名な製品に頼らないので、接続性を安定させるために、それは多くの努力をします、そして、もちろん、我々は多くの洞察を学んで、チーム統一を増やしました.
TODO section in README
それで、ゲージ自体を結論した後に、ゲージ自体が我々のチームのためでないと結論した後に、JESTゲージを造ることに決めました.そして、私たちのCIは、毎日私たちの母国語で書かれた受け入れテストを実行します.
はい、これは私たちの誇る生産事例です.
我々は大きなcoと上記の背景ではないので、冗談を脇に、我々はリスクを受け入れる.ラフなエッジがたくさんありますので、ご自身の責任でご使用ください.
結論
上記のこれらの経験、およびAtddののような本は、開発者や他の利害関係者が行動説明やユビキタス言語で、10年前にコミュニケーションを通じてコミュニケーションをとるのは時期尚早かもしれない、という信念を持っている.
コードプラットフォームのような技術と物事の重要性の増加は、これを変えるかもしれません.我々は、議論することができて、製品が何であるかを共有することができて、ゲージまたはキュウリのような半形式の言語でなければならないかもしれません.
コーディング・ブートキャンプを実行する会社のメンバーは、おそらく必然的に、コンピュータとソフトウェアの比較的良い理解をしているように見えます.これはATDDを比較的少ない摩擦で採用した理由かもしれない.私たちは今ここでJestゲージを使用してATDDを練習し、その後のソフトウェアとの関連性の低い他の分野への洞察を転送します.
しかし、これはちょうど試みです.たぶん、それは動作します.あなたがジェストゲージを試してみて、いくつかの洞察を得た場合は、私とそれを共有してください.もちろん、どんな貢献も暖かく歓迎されます.
Reference
この問題について(ジェストゲージ、ゲージのような自然言語で受け入れテストを書く), 我々は、より多くの情報をここで見つけました
https://dev.to/tnzk/jest-gauge-a-jest-extension-to-write-acceptance-tests-in-natural-languages-similar-to-gauge-lie
テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol
# Top page Specification
You can explain freely the background or motivation of the specification, since paragraphs here will be ignored as just comments.
## Scenario: a user can open a site and see the top page.
- Open "https://duckduckgo.com/".
- It shows a picture of a cute Cucumber-looking bird to the user.
ゲージは私に少し独断的に思えました、そして、それが既存の製品に統合するために重い持ち上げを必要とすると感じました.「ねえ、みんな、ゲージにテストフレームワークを切り替える必要があります!」JESTでのユニット/E 2 Eテストに慣れていたチームメンバーに.
私は、私は本格的なATDDをナビゲートするために将来的にゲージを必要とすると仮定しますが、この時の私の主な動機は、“ATDDは良いかどうかよりも狭い何か?”「ゲージのような自然言語の仕様は、開発者と非開発者の間のコミュニケーションを導く触媒であるでしょうか?」
それで、私はATDDを簡単に試すためにJESTで既存のUnit/E 2 Eテストでチームのためにツールを構築し始めました.
many programmers share
インストールと使用のために、 を参照してください.
JEST拡張モジュールであるため、
jest.config.jsに設定を追加することで試してみることができます.上記の仕様については、次のようなテストレポートを示します.$ npx jest --config=jest.config.gauge.js specs/
PASS examples/welcome.spec
Top page Specification
Scenario: a user can open a site and see the top page.
✓ Open "https://duckduckgo.com/"
✓ It shows a picture of a cute Cucumber-looking bird to the user.
Test Suites: 1 passed, 1 total
Tests: 2 passed, 2 total
Snapshots: 0 total
Time: 0.913 s
リードミー
動機
日本でコーディングブートキャンプをしています.我々は構築し、ゼロからの内部使用のための学習管理システムを維持しています.私たちは、非技術スタッフとして働いているプロジェクトのステークホルダーを持っています、そして、彼らは大きくて複雑なExcelスプレッドシートとして、ブートキャンプで教育活動を運営するために何が重要であるかについて、非常に生で事実上のニーズを持ちます!それは私がそれらを整理し、作業ソフトウェアとして出荷を維持する方法をさまよっていた.
私はステークホルダーを「我々はコーディング・ブートキャンプだ」と納得させようとしたので、リスクを取り、ソフトウェア開発方法論に新しいことを試みるべきです.私は、これがビジネスの他のドメインで受け入れられる大きい質問の種類であるということを知っていました.開発者もこれに驚いている.それで、私は同僚にこれを受け入れるために、暖かい感謝を言わなければなりません.
少し接線的で、それは唯一のストレッチではなかった.我々は、講義とテクニカルサポートセッションが行われるLMSにWebBTCとゼロからビデオチャット機能を構築しました.下記のスクリーンショットは私たちです.我々がアゴラとズームAPIのような有名な製品に頼らないので、接続性を安定させるために、それは多くの努力をします、そして、もちろん、我々は多くの洞察を学んで、チーム統一を増やしました.
TODO section in README
それで、ゲージ自体を結論した後に、ゲージ自体が我々のチームのためでないと結論した後に、JESTゲージを造ることに決めました.そして、私たちのCIは、毎日私たちの母国語で書かれた受け入れテストを実行します.
はい、これは私たちの誇る生産事例です.
我々は大きなcoと上記の背景ではないので、冗談を脇に、我々はリスクを受け入れる.ラフなエッジがたくさんありますので、ご自身の責任でご使用ください.
結論
上記のこれらの経験、およびAtddののような本は、開発者や他の利害関係者が行動説明やユビキタス言語で、10年前にコミュニケーションを通じてコミュニケーションをとるのは時期尚早かもしれない、という信念を持っている.
コードプラットフォームのような技術と物事の重要性の増加は、これを変えるかもしれません.我々は、議論することができて、製品が何であるかを共有することができて、ゲージまたはキュウリのような半形式の言語でなければならないかもしれません.
コーディング・ブートキャンプを実行する会社のメンバーは、おそらく必然的に、コンピュータとソフトウェアの比較的良い理解をしているように見えます.これはATDDを比較的少ない摩擦で採用した理由かもしれない.私たちは今ここでJestゲージを使用してATDDを練習し、その後のソフトウェアとの関連性の低い他の分野への洞察を転送します.
しかし、これはちょうど試みです.たぶん、それは動作します.あなたがジェストゲージを試してみて、いくつかの洞察を得た場合は、私とそれを共有してください.もちろん、どんな貢献も暖かく歓迎されます.
Reference
この問題について(ジェストゲージ、ゲージのような自然言語で受け入れテストを書く), 我々は、より多くの情報をここで見つけました
https://dev.to/tnzk/jest-gauge-a-jest-extension-to-write-acceptance-tests-in-natural-languages-similar-to-gauge-lie
テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol
上記のこれらの経験、およびAtddの
のような本は、開発者や他の利害関係者が行動説明やユビキタス言語で、10年前にコミュニケーションを通じてコミュニケーションをとるのは時期尚早かもしれない、という信念を持っている.コードプラットフォームのような技術と物事の重要性の増加は、これを変えるかもしれません.我々は、議論することができて、製品が何であるかを共有することができて、ゲージまたはキュウリのような半形式の言語でなければならないかもしれません.
コーディング・ブートキャンプを実行する会社のメンバーは、おそらく必然的に、コンピュータとソフトウェアの比較的良い理解をしているように見えます.これはATDDを比較的少ない摩擦で採用した理由かもしれない.私たちは今ここでJestゲージを使用してATDDを練習し、その後のソフトウェアとの関連性の低い他の分野への洞察を転送します.
しかし、これはちょうど試みです.たぶん、それは動作します.あなたがジェストゲージを試してみて、いくつかの洞察を得た場合は、私とそれを共有してください.もちろん、どんな貢献も暖かく歓迎されます.
Reference
この問題について(ジェストゲージ、ゲージのような自然言語で受け入れテストを書く), 我々は、より多くの情報をここで見つけました https://dev.to/tnzk/jest-gauge-a-jest-extension-to-write-acceptance-tests-in-natural-languages-similar-to-gauge-lieテキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol