1
キュウリBDDフレームワークのドキュメントでは、Gherkin言語から分離することを意図していたため、将来的に別の読者にやさしい言葉、つまりMarkdownをサポートする可能性があると述べています。 Gherkinはよく考えられたBDD言語ですが、別々に作成され、別々に管理された、正規表現に基づいたステップ定義としての単体テストの実装は、私に偏っています。 BDDのマークダウンに基づいたプロジェクトの立ち上げに成功したことはありますか？私は、モック、アサーションライブラリなどを設定するために、現実のテストを現場の背後で働く、思慮深いプロジェクト指向のユーティリティライブラリで記述するためのコード構文書式の使用を夢見ています。Markdownとのユニットテストおよび/または統合テストを書くツール、パッケージ、またはフレームワークはありますか？
Markdownの作成者は、仕様書が書かれているMarkdownと完全に反対であることを明示しています。 [ルール]（http://daringfireball.net/projects/markdown/syntax）はあなたが手にする最も近いものですが、[Babelmark 2 FAQ]（http://johnmacfarlane.net/babelmark2/faq.html）を読むことをお勧めします。 ）いくつかの人々はそれを持っている問題の素敵な要約のために。 – Waylan
これらの人々のうちのいくつかは、[CommonMark]（http://commonmark.org/）を作成しました。これはMarkdownに似ていますが、多くの例と完全なテストを含む完全に洗練された仕様です。個人的には、古いMarkdownプランが好きですが、特定の実装（およびその実装の特定の動作）に結びついていない単体テストを見つけるのは難しいでしょう。しかし、[markdown-testsuite]（https://github.com/karlcow/markdown-testsuite）には（現在放棄されている）努力がありますが、参考になるかもしれません。 – Waylan
ありがとう@Waylan！私が夢見ている仕様は、ヘッダー/テーブルセル/太字/下線のコードブロックとキーワードを解釈して一連のテストを実行することで、Markdownのフォーク/ブランチ/スピリットとなるでしょう。これは、テストコードと機能仕様の分離を強制しないことで、ガーキンとキュウリの代替品となります。 –