するためだけのものではなく、テストの前提条件と、テストで確認したいこととを、明確に分けることができる。});});このことはテストで確認したいことがひとつだけの場合にも有効である。テストの構造化テストの前提条件と確認したいこととを明確に分けることができると、テストが構造化されて、スペック(仕様)のアウトラインが把握しやすくなる。});});テスト結果をドキュメント形式で出力している場合にも、アウトラインの把握のしやすさは顕著になる。引数として渡される...反対に、テストが構造化されていないと、確認したいことの記述が長くなって読みづらい。引数として渡される...差分を際立たせる対比させるような前提条件があった場合には、差分を際立たせるようにすると読みやすくなる。差分が際立っていない例から。});});書きやすくするためのヒント読みやすさを損なわないようにしつつ、書きやすくするためのヒントについても触れておく。書くべき?下記のコメントした箇所のように、テストの前提条件とも確認したい内容とも解釈できるものがある。中に含めるようにしている。保たなくてもよいと考えている。例を示すために「差分を際立たせる」の箇所で用いた例を再掲する。メソッドをより広い範囲で再利用しようとすると、より多くのユースケースに応えるために引数は多くなり、メソッドの行数も増える。いうメソッドが用意されていて、私の場合は実装前にこれを使って仕様を書き出してしまうことが多い。total...このように進めると、実装の途中で「あれ?いまどこを実装しているんだっけ?」と迷子にならなくて済むという効用があるのでオススメ。メソッドも用意されていて、テスト全体の実行時間を短くするのに役立つ。実行されるタイミングについては注意が必要。byなお、今回の内容は下記の本に強く影響を受けている。前に読み直す機会があって、あらためて良い本だと感銘を受けた。はたらくフロントエンドエンジニア。公式ドキュメントの翻訳者、メンテナ。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。