booksRSpecとはBDDで使う素晴らしいツールです。developmentの略で方向性を人の読める仕様に沿って開発を行う開発方法論です。できるかを説明したRSpecの書き込みを探せますが、RSpecで良いテストの作り方を説明した書き込みはなかなか探せません。Specsは大抵のガイドラインの書いてない部分を集めようとしました。これは開発者達の経験を通して学んだ方法です。メソッドの説明をする作成中のメソッドを明らかにしましょう。Ruby文書の規約ではクラスメソッドの名前には.(もしくは::)をインスタンスメソッドの名前には#を使っています。→TweetContextsを使うContextsはテストを明らかにし、まとめる素晴らしい方法です。長い目で見ると、この方法はテストを読みやすくします。}endContextsでは"when"もしくは"with"で説明し始めましょう。→Tweet説明を短くspecの説明は40文字を超えないようにしましょう。超えた場合はcontextを分けてください。}と書いてステイタスの説明を削除しました。filenameでテストを実行すると相変わらず読める出力を取得できます。→Tweet単一条件テスト'単一条件'は'各テストは一つだけ確認すべき'という表現でより広く知られています。これはエラーを探しやすくし、失敗するテストをすぐ見つけるようにし、コードを読みやすくします。独立したユニットでは、各例はただ一つの振る舞いだけテストするのが望ましいです。例の中で多数のテストが有るのは幾つかの振る舞いに分離する必要があることを示しています。分離できないテストで(例えばDBや外部システムとの連動、前後があるテストの場合)分離するだけでは同じセットアップを何回も行い、テストが重くなる現象が現れます。いった重いテストは分けなくても良いでしょう。→Tweet可能な限り全部をテストテストはやった方がいいですが、全ケースをテストしないと、有用とはいえません。有効な場合と無効な場合を全部テストしましょう。こんなアクションが有るとしましょう。@consumption.destroyend普段よく見るエラーで、モデルがうまく削除できたかだけテストしています。少なくとも二つのエッジケースが存在します:モデルを探せなかった時と権限がない時です。すべての一般的に可能な入力を考えてテストしましょう。→TweetExpect対Should新しいプロジェクトではexpectだけ使いましょう。respond_with_content_type(:json)end全体で新しい文法だけ許容し、Rspec2の文法を使えなくなる様に設定できます。expectation文法に対するもっと詳しい情報はこことここをご覧ください。→TweetSubjectを使うもしも、同じsubjectに対して複数のテストをしていたら、subject{}を使ってDRYしましょう。}RSpecでは名前付きのsubjectも使えます。subjectに関してもっと学ぶ。→Tweetletとlet!を使う変数に値を入れる必要がある時はbeforeブロックの代わりにletを使いましょう。loadしてspecテストが終わるまでキャッシュとして使えます。このstackoverflowの答にletに関しての詳しい説明が有ります。endendブロックが定義した時に変数を定義したい時はlet!を使いましょう。これはDBのクエリーやスコープのテストで有用です。これはletの実体の説明です。→TweetMockを使うか使わないかまだ議論中のものです。出来るだけ(過度に)mockを使わずに実際の振る舞いをテストしましょう。実際のケースをテストするのはロジックを変更する際に有用です。}endmockはspecを早くしますが正しく使うのが難しいです。mockをうまく使うにはもっとmockを理解する必要があります。この書き込みをご覧ください。→Tweet必要なデータだけ作る中小規模のプロジェクトの経験しかないと、テストスイートは重くなりがちです。必要以上のデータをロードしないようにしましょう。多数のデータが必要だと考えるならば、何かが間違っている可能性があります。→Tweetfixtureの代わりにfactoryを使うこれは古い話ですが、話しておく価値があります。fixtureは使わないでください。fixtureは操作が難しいからです。代わりにfactoryを使いましょう。factoryを使うと新しいデータを生成する際のコードの量を減らせます。:user注意!この文書でのユニットテストはfixtureもfactoryも使っておりません。複雑なfixtureやfactoryを作る時間を節約すると、ライブラリにロジックを追加する時間を稼げます。この書き込みを読んでみましょう。Girlをもっと学ぶ。→Tweet読みやすいmatcherを使う読みやすいmatcherを使いましょう。matcherを二回以上確認しましょう。Examplesテストを作るのは素晴らしいです。毎日少しづつ自信がつきます。結局色んな所にコードの重複が発生します。exampleを使ってテストをDRYしましょう。exampleは対体コントローラで使われます。モデルはお互いかなり異なるため、(普通は)多くのロジックを共有しません。examplesに対してもっと学ぶ。→Tweet見えるものをテストモデルとアプリの振る舞いを深くテストしましょう(結合テスト)。コントローラをテストする為にいらない複雑さを入れないようにしましょう。私は自分のアプリケーションをテストする時、最初はコントローラをテストしていましたが、今は行いません。今はRSpecとCapybaraの統合テストしか作りません。言うとほんとに目に見えるものをテストするべきだと信じているし、コントローラをテストするのは不要な段階だと思っているからです。examplesに纏まって、きれいで読みやすいテストを作るようになります。コミュニティーで議論中の話で、両方の側その考えを支える良い根拠が有ります。コントローラのテストを支持する側は統合テストは遅くてすべての機能をカバー出来ないと主張します。大体簡単にすべての機能をカバー出るし(でしょ?)Guardみたいな自動化ツールを利用して一ファイルだけテストするのも可能です。すれば大きな流れを逆らわない範囲内で必要なspecだけテストできます。→Tweetshouldを使わないテストの説明を書くときにshould使わないようにしましょう。現在時制に第三者観点から書きましょう。新しいexpectationを使うともっと良いです。equal(valid.occur_at)endshouldを使わないように制限できるshould_notをご覧ください。should_cleanもご覧ください。変更がある度に全テストをまわすのは厄介です。それは時間もかかりますし、流れをわずわらせます。Guardを使うと更新された使用、モデル、コントローラ、ファイルだけに対してテストをまわせるように自動化できます。guardこの例は基本的なリロードルールがあるGuardfileです。}endGuardは良いツールですが、求めるすべてを満足させません。環境によってはTDDで働きながらキー設定で自分が望むタイミングで実行するのが良い時もあります。pushの前だけ全体テストをまわしましょう。ここに参考になるvimの設定があります。→Tweetsporkを使ったテスト高速化Railsでテストを実行するには全体Railsのロードが必要です。これは時間がかかり仕事のじゃまになり得ます。Zeus、Spin、Sporkなどを利用すればこの問題は解決できます。factoryと変更が頻繁なほぼすべてのコードをプリロードします。helperとGuardfile設定があります。この設定を使用すればプリロードされるファイル(initializerとか)が更新されたときのみアプリ全体をリロードして、単一テストをとても早く実行できます。Sporkを使う際の欠点は、コードに積極的にモンキーパッチをあてているため、ファイルがリロードされない原因を理解するのに時間を無駄使いする可能性があることです。Spinもしくは他の解決策があったら教えてください。.Zeusを使うためのGuardfile設定ファイルはここに有ります。start`をする必要があります。全てに置いてZeusはSporkより比較的に安全な方法を使います。短所は使用要件がかなり厳しいことです。FSEventsもしくはinotifyが使えるOSを必要とします。多くの人達がSporkから他の解決策に移しました。この解決策達はもっと良い設計でもっと良い答えが出せますし、意識的に必要なものだけロードするようにしています。詳しいことは関連議論をご覧ください。requestをmockするテストする時、外部サービスに依存する必要がある場合がまれにあります。こんな場合実際サービスに依存させなくwebmockなどを使ってstubするのが望ましいです。endendwebmockとVCRに対してもっと学ぶ。二つを一緒に使う方法を説明した良いプレゼンもあります。→Tweet有用なformatterformatterを使うとテストに関する有用な情報を得られます。個人的にはfuubarが大変良かったです。実行するにはgemを設置しGuardfileにfuubarを基本formatterとして設定する必要があります。Fuubar--colorfuubarに対してもっと学ぶ。Ruby.guard-rspecに対してもっと学ぶ。