6

私は何年にもわたってたくさんの言語でプログラミングをしてきましたが、一般的にはかなり上手だと思います。ただし、自動テストを作成したことはありません。単体テスト、TDD、BDD、何もありません。

私は自分のプロジェクトに適切なテストスイートを書き始めようとしました。変更を加えた後、プロジェクト内のすべてのコードを自動的にテストできることの理論的価値を確認できます。RSpecやMochaなどのテストフレームワークが、前述のテストのセットアップと実行を合理的に簡単にする方法を理解できます。また、テストを作成するために提供されるDSLが気に入っています。

しかし、コードのどの部分に対しても実際の単体テストを作成することはできませんでした。私が書いたものは、実際に役立つ方法で非常にテスト可能であるようには思えません。

  • 関数は、それらが使用されているコンテキストの外ではあまり呼び出せないようです。私が作成する多くの関数は、HTTPリクエスト呼び出し、データベースクエリ、またはその他の簡単にテストできない呼び出しを行います。
  • 一部の関数はHTMLの文字列を返します。HTML文字列を同じ文字列のハードコードされたバージョンと比較することはできますが、それはコードのその部分を変更する能力を制限しているように見えます。さらに、テストコードに大量のHTMLが含まれていると、混乱します。
  • モック/スパイオブジェクトをメソッドに渡し、それらが特定のメソッド呼び出しを取得することを確認できますが、それは私が「テスト」しているメソッドの実装の詳細をテストしているだけです。

適切なBDDテストを開始するにはどうすればよいですか？（MochaとNode.jsを使用してこれを実行したいのですが、BDDに関する一般的なアドバイスも問題ありません。）

4

2 に答える 2

3

あなたが尋ねている主な質問は、「テスト可能なコードをどのように書くか」ということのようです。

オブジェクト指向プログラミングのファンである私は偏見があることを知っていますが、私の経験では、オブジェクト指向スタイルで記述されたコードをテストする方がはるかに簡単です。この理由は、単体テストはシステムの小さな分離されたコンポーネントをテストすることを目的としており、適切に設計されたオブジェクト指向コードが（ほとんど）これを提供するためです。

私は、関数がそれらが存在するコンテキストにリンクされていることが多く、テストを困難にしていることに同意します。関数型プログラミングの経験はあまりありませんが、コンテキストが何らかの変数で渡されることが多く、関数の関心の分離が難しいことは知っています。

オブジェクト指向プログラミングでは、実際のネットワーク要求を実行するオブジェクトをモックして既知のデータセットを返すことにより、HTTP要求やデータベースクエリなどをラップアラウンドするオブジェクトのテストに成功しました。次に、ラッパーオブジェクトがそのデータを正しい方法で処理することをテストします。障害や予期しないデータをテストすることもできます。これを行う別の方法は、通常のエンドポイントの代わりに使用するローカルサーバーを設定することですが、これによりテストスイートに外部依存関係が与えられ、可能な場合は回避する必要があります。

HTMLをテストする場合、ビューレイヤーの性質が大きく変化するため、多くの人はこれをまったく行いません。ただし、実際にテストする価値のあるものがいくつかありますが、HTMLの完全な文字列ではありません。ご存知のように、わずかな変更だけでテスト全体が失敗することになります。その場合、コードベースの別々の部分にある2つの文字列が同じであるということで、実際に何をテストしていますか？

最善の方法は、関数/オブジェクトからHTMLパーサーライブラリにHTML文字列をロードすることです。通常、XpathまたはCSSセレクターを使用して、特定のクラス、ID、またはその他の属性を持つタグをチェックし、要素の数をチェックできます。特定の要件に一致します。have_tag()多くのテストライブラリと同様に、Rspecにはこれが組み込まれています（メソッド）。

あなたが見たいと思うかもしれない他の何かは統合テストです（例えば、Capybara、Selenium）。これにより、WebアプリにJavaScriptエンジンが読み込まれるため、HTML要素とJavaScriptイベントを確認できます。

モック/スタブ全体では、通常、テストしているオブジェクトの依存関係であるオブジェクトでのみこれを実行する必要があります。それ以外の場合は、trueとしてアサートするためにほとんど何でも操作できます！

テストに関するリソースについては、TDDを実践する予定がない場合でも、テスト駆動開発の本を参照することをお勧めします。主な理由は、彼らがあなたを最初にテストに投げ込むことです。ここにいくつかあります：

  1. Kent Beckの著書「テスト駆動開発：例による」
  2. PHPを使用したTDDに関する無料の電子ブック、実用的なPHPテスト
  3. このウェブサイト、Art of Unit Testing
  4. Slideshare-ユニットテストまたはBDDを検索して、できるだけ多く読んでください！
  5. デビッド・チェリムスキー他 al.:RSpecブック
于 2013-02-14T10:00:30.847 に答える
0

TDDまたはBDDは関係ありません。これらは、プラグ可能なフロントエンドであるMochaによって証明されるように、同形です。

モック/スパイオブジェクトをメソッドに渡し、それらが特定のメソッド呼び出しを取得することを確認できますが、私が知る限り、それは私が「テスト」しているメソッドの実装の詳細をテストするだけです。

それがまさに単体テストのポイントです。テストしているのは、テストしているコードだけであり、それ以上ではありません。さらにテストする場合の問題は、失敗したテストは通常​​、問題に正確にフラグを立てないことです。単体テストの約束は、デバッグを大幅に回避できることです。粗すぎるテストはそれを無効にします。もちろん、バランスが必要です。UTの経験がある人なら誰でも、私がテストしたい、気づかなかったという罠に陥りやすいと言うでしょう。テストがすべて緑色で、実際のコードが機能していない可能性があります。

于 2013-02-14T10:16:57.577 に答える