TDD を使用してソフトウェアを適切に開発する方法を学ぶことに本当にイライラしています。人それぞれ、やり方も順番も違うようです。この時点で、すべての考慮事項が何であるかを知りたいのですが? これが私が思いついたものです。rspecとカピバラを使用する必要があります。そうは言っても、適切に構築およびテストされたアプリケーションを作成するために、作成する必要があるさまざまな種類のテストはすべて何ですか。テスト対象のアプリケーションの領域、テストに必要なフレームワーク、および依存関係を含むリストを探しています。
たとえば、モデルの単体テストから始めるように勧められているようですが、TDD のチュートリアルを見ると、統合テストしか書いていないようです。何か不足していますか？
さて、「どのように TDD を行うか」というテーマは、「どのように適切にテストするか」というテーマと同じくらい広く公開されています。Ruby では、より具体的には Rails では、rspec を最初に使用するツールにする必要がありますが、それで終わりではありません。RSpec を使用すると、コンポーネントの単体テストを記述して、それらを個別にテストできます。Rails のコンテキストでは、次のことを意味します。
これは非常に優れたツールであり、レールに限定されたものではなく、他のフレームワークのテストにも使用されます。
RSpec を使い終わったら、cucumber にジャンプする必要があります。Cucumber (http://cukes.info/) は、統合テストを作成するために (Rails 環境で) 最もよく使用されるツールです。その後、キュウリにカピバラを統合できます。
cucumber を使い終わったら、アプリケーション バックエンドとその HTML 出力 (の一部) のテストが完了します。そのときは、JavaScript コードもテストする必要があります。どうやってするか？まず、単体テストを行う必要があります。Jasmine (http://pivotal.github.com/jasmine/) は、この作業に使用できるツールの 1 つです。
次に、構造への統合をテストする必要があります。どうやってするか？キュウリに戻ってセレン (http://seleniumhq.org/) をキュウリ フレームワークに統合すると、ブラウザで「ライブ」で統合をテストし、JavaScript マジックとテストにアクセスできるようになります。その場で。
したがって、これらの手順を完了すると、適切に統合されたテスト環境を作成するために必要な手順のほとんどをカバーしたことになります。終わりましたか？あまり。また、カバレッジ ツール (利用可能なもの: https://github.com/colszowka/simplecov ) を設定して、コードが十分にテストされているかどうか、未解決の問題が残っていないかどうかを確認する必要があります。
これらの不機嫌な手順を完了した後、最後に 1 つのことも行う必要があります。これは、開発をすべて 1 人で行うのではなく、チームが十分に大きく、単独では管理できない場合に備えて: テスト サーバーを設定します。前のすべてのステップを定期的に実行し、その結果に関する通知を配信する以外に何もしません。
したがって、これらすべてが、関心のある開発者にとって優れた TDD 環境を設定します。Ruby/Rails コミュニティでさまざまな種類のテストに最も使用されているフレームワークのみを挙げましたが、それはあなたの仕事に適した、またはより適したフレームワークが他にないという意味ではありません。適切にテストする方法はまだ教えられていません。そのためには、より多くの理論が関係しており、多くのサブディベートがあります。
何か忘れた場合は、下のコメントに書き込んでください。
それに加えて、適切にテストする方法にアプローチする必要があります。つまり、宣言的アプローチと命令的アプローチのどちらを採用しますか?
簡単に始めて、必要に応じてツールやテクニックを追加してください。すべてのアプリは異なるため、アプリの TDD には多くの方法があります。これを行う 1 つの方法は、Rspec と Capybara (または Cucumber と Capybara) を使用したエンド ツー エンドのテストから始めて、必要に応じてさらに細かいテストを追加することです。
Capybara のテストに合格するのに数分以上かかる場合は、よりきめ細かいテストが必要です。
また、アプリケーションのドメインが自明でない場合は、最初にドメインのテストを開始する方が効果的かもしれません。
場合によります！さまざまなアプローチを試して、何が効果的かを確認してください。
TDD を使用した実世界のアプリケーションのエンド ツー エンドの開発は、実際には十分に文書化されていないアクティビティです。確かに、教科書の例、カタ、理論的な記事がほとんど出回っています。ただし、いくつかの書籍では、TDD - GOOS (強くお勧めします) に対してより包括的で実用的なアプローチをとっています。
GOOS で説明されているアプローチは、エンド ツー エンドの受け入れテスト (統合テスト、場合によっては RSpec テストに相当する可能性があります) を記述することから始まりますが、そのループ内で、下位レベルの設計に必要な数の TDD 単体テストをコーディングします。オブジェクト。それらを書くときは、基本的に、外側のレイヤー、内側のレイヤー、またはアプリケーションの最も便利な部分から、好きなところから始めることができます。依存関係をモックアウトしている限り、とにかく単体テストのままです。
Railsを学び始めたときも同じ質問をしました。テストを改善するためのツールや方法はたくさんありますが、それに多くの時間を費やした後、何かをしなければならないか、またはそうではなく、問題があると思われるものを最初にテストしてから、別の場所でテストしてください。まあ、時間が必要です。
それは私の見解です。