すべてをテストする必要がありますか？

Ruby on Railsで最初の実際のプロジェクトを開始し、TDDテストの作成を強制します。テストを書くことに本当の利点はないと思いますが、それは非常に重要だと思われるので、試してみます。

静的ページを含むアプリケーションのすべての部分をテストする必要がありますか？

TDDはテストではなく、設計に関するものです。テストを書くと、クラスがどのように機能するか、どのようなインターフェースが必要かを考えるようになります。テストは、後でリファクタリングしやすくする幸せな副作用です。

それで、それを念頭に置いて、静的ページの動作とインターフェイスは何ですか？

私の最初の応答は「なし」と「なし」です。

常に費用対効果の分析です。機能を壊すことの費用はいくらですか？コストが高い場合は、十分にテストしてください。コストが低い場合は、軽くテストするか、まったくテストしません。

市場投入までの時間を考慮するコストもあります。完全に機能する機能を遅らせるよりも、ほとんど機能する機能を提供する方が良いかもしれません。

一般的なIMOでこれらの質問に答えることはほとんど不可能です。

ある機能が最初に気付いたよりも重要であることが判明した場合、テストする能力を維持することがより重要だと思います。

私は「はい」と言います。最も単純な機能とコードさえもカバーするテストがある場合、新しいコードを追加してもインプレースコードが機能しなくなることはないと確信できます。同様に、発生したすべてのバグに対してテストを行うことで、回帰が忍び寄るのを防ぎます。

はい、すべてをテストする必要があります...

すべての自動テストを作成する必要はありません。静的ページについては、Selenium http://seleniumhq.org/を使用して、問題がないことを確認してください。

私の経験から、いくつかのフロントエンドのものはテストケースを書くことがほとんど不可能ですが、それが実際にMark 1眼球を使用してテストしたい理由です。

テストはコーディングと同じくらい重要です。「何かがうまくいかないことがあるなら、それはそうする」という言葉を聞かなければなりません。INMO、品質を向上させるために使用されるソフトウェアエンジニアリングの多くの技術のうち、テストは、問題を早期に発見するのに役立つ最も価値のあるものです。

すべてをテストすることはできませんが（特に小さなチームと大規模なシステムで）、テストを完全にスキップするわけではありません。テストする価値はありますか？See Wiki-SoftwareTestingのセクション「障害の早期発見」を参照してください。

TDDテストは、そのように書かれていれば、生きた仕様にもなります。テストメソッドの名前は、ビジネスユーザーにとって意味のあるものでなければなりません。

他の人が述べたように、Ruby on Railsのテストでは、（ほとんどの）他の言語よりもはるかに重要です。これは、コンパイラーがないためです。

以下のような言語のDelphi、C ++、VB.NETなどは、...言語をコンパイルされ、そしてあなたのコンパイラは、このようなメソッドの呼び出しでタイプミスとしてmistkesの多くをピックアップします。Ruby on Railsでは、特定のコード行が実行された場合、または視覚的な警告を表示するIDEを使用している場合、コードに誤字や誤りがあるかどうかのみがわかります。

すべての単一行のコードが重要である（そうでない場合は存在しない）ため、作成するすべてのメソッドをテストする必要があります。これは、いくつかの基本的なTBDDツールに従う場合に聞こえるよりもはるかに簡単です。

Ryan BatesのRails Cast on How I testは私にとって非常に貴重なものであり、正しく行われればTBDDのシンプルさを強調しました。

本当にTDD方法論を使用している場合は、最初にパスしようとしている単体テストがなければコードを作成しません。

私はTDDから始めないでください。一般的なアーキテクチャ戦略の学習により多くの時間を費やしたときに、情報に基づいた決定を下します。TDDでは、宿題をスキップできるとは思わないかもしれませんが、宿題をスキップすることはできません。

これが私の問題です。言うまでもなく、TDDを壊すことのないものに多くの時間を浪費しているように思えますが、依存関係の巨大なチェーンで予期していなかったことが破壊されると、感謝するでしょう。アプリを書く前にそのようなことを予測することは不可能だと指摘するとき、それが...私たちがテストする理由です、彼らはテストが便利であるにもかかわらず、実際には設計に関することであり、テストではないことを伝えます。

しかし、予測不可能なリンクされた依存関係の巨大なチェーンは、安っぽいデザインの産物ではありませんか？

それでどちらですか？

ここに考えがあります。Design Patternsのオブジェクト指向設計の次の2つの原則を考慮して、そもそも依存関係の巨大で複雑なチェーンを持たないようにしましょう。

「実装ではなく、インターフェースへのプログラム」

つまり、オブジェクトは、誰が呼び出しを行っているのか、どのように作成されたのかを気にしてはいけません。適切な引数が入力され、指示された他のオブジェクトから呼び出されるメソッドが期待どおりに動作することだけが必要です。ほとんどの場合、依存関係のチェーンは、1つのリンクポイント、呼び出し側のメソッド呼び出し、および引数がメソッドにドロップされる場所にある必要があります。ここで、ログに記録して検証し、問題が発生したときにデバッグに役立つメッセージを送信します。

そして：

「クラスの継承よりもオブジェクトの構成を優先する」

ダミーは誰ですか？複雑なカスケード継承スキームのクラスに何かをして、30のクラスのようにフリンジケースの破損を引き起こした人、またはそもそもそのアーキテクチャを思いついた開発者ですか？TDDを使用すると、ピサの斜塔の内部の問題の根底に到達するのに役立つ場合がありますが、そのコード災害のエンドポイントの1つを次回変更しようとするのはそれほど苦痛ではありませんか？

そして、それは私が私を悩ませることに到達する場所です。TDDは本当に設計に役立ちますか、それとも悪いアーキテクチャを可能にしますか？自己実現戦略になる可能性があるように思えます。チームが貧弱なアーキテクチャに対する責任を負う必要がなければならないほど、これらの詳細なテストコンポーネントはより役立つように見えますが、最終的にはアプリはますます大きくなるPITAになります（最初の段階ではアーキテクチャをあまり考慮していなかったと仮定します）場所）。そして、その結果を認めなかったのは人手によるものであり、時間の経過とともにアップグレードおよび修正されることを意図したアプリケーションで作業するときに、常に最も費用のかかる間違いを犯します。

質問に答えるには、「ここで何がうまくいかないか」を考えてください。特に、「コード」（マークアップ/何でも）を変更した場合、ページを壊していないことをどのように確信できますか。さて、静的ページの場合：

• レンダリングされない可能性があります
• 正しくレンダリングされない可能性があります
• JSが読み込まれない場合があります
• 画像のパスが機能しない場合があります
• リンクが壊れている可能性があります

個人的に、私はお勧めします：

• ページで期待する1つの文字列をチェックするセレン[1]テストを作成します（可能な場合、下部に近い）。これにより、レンダリングが検証されます。
• JSエラーがないことを確認してください（セレンはこれを許可していると思います）
• htmlバリデーター、可能であればリンクチェッカーを介して静的ページを実行します。
• JSを検証するためのツールが見つかりませんでしたが、jslintまたはjshintで成功するかもしれません。

ここで重要なことは、反復可能で使いやすく、テストランナーで自動的に実行されるものが必要なことです。

すでに優れた答えをすべて追加するために、テストするものとテストしないものについての私の考えを以下に示します。

テストを行います：

• ビジネスの論理
• アプリケーションロジック
• 機能性
• 動作、
• だから、本当に、すべてを除いて：

テストしないでください：

• 定数
• プレゼンテーション

したがって、次のようなテストを行っても意味がありません。

assert wibble = 3

と言ういくつかのコード

wibble = 3

また、アイコンがツルニチニチソウの青であるかどうか、見出しに使用したフォントなど、プレゼンテーションの内容をテストしても意味がありません...

したがって、「静的ページをテストする必要があります」と尋ねると、答えは次のとおりです。サイトの機能、ビジネスロジック、または動作の一部である限り、静的ページをテストします。

そのため、アプリには、サイトのすべての部分（匿名ユーザー、ログインユーザー、ダッシュボード、アプリ画面内など）から利用規約が利用可能であることを確認するテストがあります。各ページの「契約条件」と呼ばれるリンク、そのリンクが機能すること、そしてテストは、ページに到着すると、Ts＆Csに「似ている」と言います。 「定数をテストする」または「プレゼンテーションをテストする」ことなく...たとえば、特定のフォントサイズやテキストレイアウトをチェックせずに、テキストが正しいことを確認できます...