そのほかに知っておくと便利な情報として、仕様を「ペンディング」状態にしておく、というものがある。

easybのDSLにおいて、仕様を検証するコードはgiven、when、thenといったメソッドに渡すクロージャとして記述するわけだが、実はこのクロージャは省略することができる。省略すると、以下のように「シナリオの概要だけを示したもの」となる。

scenario "「/」から始まる完全なファイルパスを解析する", {
    given "完全なファイルパスを表す文字列"
    when "完全なファイルパスを渡し、FilePathのインスタンスを生成する"
    then "ディレクトリのパスは「/a/b/」になるはず"
    and "ファイル名は「c.txt」になるはず"
}
scenario "「/」で終わるディレクトリパスを解析する", {
    given "「/」で終わるディレクトリパス(「/a/b」)から生成したFilePathのインスタンス"
    then "ディレクトリのパスは「/a/b/」になるはず"
    and "ファイル名は空文字になるはず"
}
scenario "ファイル名のみからなるパスを解析する", {
    given "ディレクトリパスを含まないパス(「c.txt」)から生成したFilePathのインスタンス"
    then "ディレクトリのパスは空文字になるはず"
    and "ファイル名は「c.txt」になるはず"
}
scenario "ファイルパスとしてnullを渡すと、例外が発生する", {
    given "nullをファイルパスとして渡す"
    then "IllegalArgumentExceptionが発生する"
}

この状態でも実行することができ、検証は成功する。こうした、シナリオの中身を書かずにいることを「ペンディング」と呼び、仕様は決まっているものの検証コードをまだ書いていない状態、としておくことができる。非常に可読性が高く、これ自体が仕様書として通用するレベルだと言っても過言ではない。仕様が決まったら、いったんすべてペンディングの状態でシナリオを記述し、そこから実装を行っていく、というフローがお薦めだ。