BDDとDSL入門 https://www.jianshu.com/p/37946199ee02
1.お客様はテストに関心がない
. Test (Verification) . は、ソフトウェアが存在する場合にのみtestを行う. BDD specification . BDD Design . は、所望のbehaviourによって駆動する、機能ブロックを徐々に構築する. TestからBDへ: **test-centric** **specification-centric** . 2.お客様はspecificationを作成したくない
お客様は、自分の問題の解決策を作成する必要はありません. 認知差(cognitive diversity)異種(heterogeneous)人員が一緒に働いている. お客様のspecificationの完了を支援します. お客様は、解決すべき問題の情報を提供し、開発プロセスを指導するための具体的な事例を提供する必要がある. 3. DSL: Domain Specific Language.
はグループ内で重要な問題のコミュニケーション(BA,QA,DEV)を促進した. フィーチャー言語フィーチャー(language nature)は一貫した表現能力を備える. 制限された表現力(limited expressiveness)は、特定の領域に必要な特徴の最小セットのみをサポートする. 特定の分野(domain focus)に専念は明確な小さな分野の下でこそ意味がある. 分類外部DSL.は、通常、カスタム構文(またはXMLなど)を用いる、ホストアプリケーションはテキスト解析技術を用いて外部DSLスクリプトを解析する.例えば、正規表現、SQL、Awk. 内部DSL.共通言語の特定の用法、そのスクリプトは特定の風格を持つ合法的なプログラムである. 外部DSLとの違い:内部DSLは実行可能な言語で記述する、その言語で解析する. 例えばLisp,Rails. 言語ワークベンチ専用のIDEは、DSLを定義構築するために用いる. 抽象: DSL .抽象を確立する方法は、ライブラリまたはフレームワークである.フレームワークは、コマンド/クエリーAPI呼び出しにより操作する. DSLはプログラムのフロントエンドである、コマンド/クエリー式APIスタイルとは異なる操作方式を提供する. ライブラリはDSLの「意味モデル」となる. は、通常、DSL として現れる. APIとDSLの核心の違いは:DSL である. DSLの問題言語騒音DSLを学ぶのは下層モデルを学ぶよりも代価が小さいはずだ. 構築コスト.メンテナンス性は重要な考慮である. 言語収容所注目点を分離してDSLに明確な制限範囲を持たせる.外部から得るべきものを自ら構築する. DSLは「進化し、まだ終わっていない」ものである.抽象に合わないものに出会ったら、抽象を修正し、新しいものをより簡単に受け入れるようにしなければならない.