...docsに完全なリストがあります。sandbox.サマリBDDでは、仕様が最初で実装はそれに従います。最終的に仕様とコードを持つ事になります。コードが正しく動作するこをと保証します。タイトルはその関数がすることを示します。テストは実際には関数がどのように使われるのかを見せる、動作するサンプルです。仕様があると、安全に改善、変更、スクラッチで関数の書き直しですらもでき、それがまだ正しく動くことを確認することができます。関数が多くの場所で使われる場合、大規模なプロジェクトではそれが特に重要になります。このような関数を変更するとき、それを使う全ての箇所で正しく動作するかを手動で確認する方法はありません。テストがない場合、2つの道があります:たとえ何が起ころうと関係なく、変更(修正)を行います。我々のユーザはバグを見つけ、それを報告します。これが許されるのであれば。エラーへの罰が厳しい場合、人々はこのような関数を変更することを恐れるようになります。関数は古くなり、クモの巣が生い茂り誰もその中に入りたくなくなります。それは良いことではありません。自動テストコードはその反対です!もしプロジェクトがテストでカバーされていれば、このような問題はありません。私たちはテストを走らせ、あっという間に多くの確認結果を知ることができます。テストされたコードは、より良いアーキテクチャを持っています。変更や改善が容易だからですが、それだけではありません。テストを書くためには、すべての関数が明確に記述されたタスク、よく定義された入力と出力を持つようにコードを編成する必要があります。それは最初からよいアーキテクチャであることを意味します。実際にはそう簡単なことではありません。どのような挙動をするべきかまだ明確でない場合、実際のコードの前に仕様を書くのが難しいときもあります。一般的には、テストを書くことは開発を速く、より安定させます。構文上、テストは正しいものであり、合格となります。解答このテストは、テストを書く時に開発者が出会うテンプレートの1つです。3つですが、3つのアサートを持つ1つの関数として並べられています。この方法で書くほうが簡単な場合もありますが、エラーが起きた時、何が間違っていたのかが明らかではありません。複雑な実行フローの中でエラーが起きた場合、その時のデータを把握する必要があります。しなければならなくなります。ブロックに崩す方がはるかに良いです。ブロックのグループに置き換えました。今何かが失敗した場合、データが何であるかが明確に分かります。書くことで、単一のテストに分離し、スタンドアローンモードで実行することができます。});});前のレッスン次のレッスンシェアチュートリアルマップコメントコメントをする前に読んでください...自由に記事への追加や質問を投稿をしたり、それらに回答してください。タグを使ってください。codepen...)。記事の中で理解できないことがあれば、詳しく説明してください。Kantorプロジェクトについてコンタクト。