4

JavaScript のテスト駆動開発を使い始めていますが、さまざまなプロジェクトで使い始めたいと考えています。

よくある間違いと、それを回避する方法を教えてください。

また、テスト駆動開発の学習とコードへの適用を容易にするために何を読むべきかを知りたいです。

前もって感謝します。

4

3 に答える 3

10

TDD を使用して私が直面した唯一の最大の問題は、開発者が単体テストに自信を持っていないことです。不十分な単体テストは、節約できるよりも多くの時間を浪費します。混乱し、信頼性が低く、保守が難しく、判読できないテストはすぐに見捨てられ、疲れ果てた開発者は時間をかけて再び自動的に単体テストを行いたいと思うようになります。

Per Fagrell は、特にすべての変更後にテストを実行することについて、いくつかの良い点を指摘しています。テストの変更の前後にテストを実行することは、第二の性質になるはずです。

フレームワーク:

JS テストのフレームワークとして QUnit を検討してください: http://docs.jquery.com/Qunit

依存マークアップを含むテスト ハーネス ページがあり、ページの読み込み時にテストがうまく実行されます。

あなたがフォローすることができます

  • 整える
  • 活動
  • 主張する

QUnit を使用した単体テストのフロー。

ただし、手動でテスト セットアップ メソッドとティアダウン メソッドを実装し、テスト メソッドで呼び出す必要があります。これらは、すべてのテストの条件を同一に保ち、テストが実行順序に依存するのを防ぐことで、テスト ケースの分離に役立ちます。

使用する他の言語で役立つフレームワークを探してください。NUnitは .NET で非常に人気があります。

隔離：

Per Fagrell も隔離について良い点を述べています。テストを開始する前に、単体テスト (機能のアトムの 1 つの側面をテストする) と統合 (複数のアトムがどのように連携するかをテストする) の違いを十分に理解する必要があります。テスト メソッドに複数の assert がある場合、単体テストではなく、テスト メソッドを変更する必要があります。

規約:

The Art Of Unit Testingの優れたテストの命名規則は、MethodUnderTest_Condition_ExpectedBehaviourです。

Expand_TextVariable_ExpandsText

同じ本からあなたのテストを保管してください：

  • 信頼できる
  • メンテナンス可能
  • 読み取り可能

そうしないと、あなたや他の開発者がわざわざテストを実行する必要がなくなります。

偽物:

よく誤解されるのは、スタブとモックという 2 種類のフェイクの違いです。

コードが依存する機能をインターフェイスに抽象化することにより、コード内にシームが作成されます。たとえば、コントローラーは具象リポジトリに依存せず、IRepository に依存します。

次に、スタブがこの IRepository を実装し、偽の値を返します。コントローラーコードを分離して実行するために使用されます。たとえばGetCustomer()、実際のリポジトリやストアへの呼び出しなしで、新しい顧客を作成してそれを返します。スタブは に対してテストされることはありません。モック
は、テスト可能 な値を保持できることを除けば、スタブに似ています。たとえば、モックはその値を受け入れ、それに対してアサートできます。モックは に対してテストできます。AddCustomer(Customer customerToBeAdded)

特定のインターフェイスの偽物を自動的に作成できるテスト分離フレームワーク (またはモッキング フレームワーク) を見てください。

モックの目的の誤解により、複数の開発者がモックを作成して機能をテストし、モック自体に対してテストを作成するのを見てきました。

資力：

The Art Of Unit Testingについて言及しましたが、徹底的にお勧めします。これは、コード コンプリートと共に、オフィスが火事になった場合に入手する本の 1 つです。

それが役立つことを願っています。

于 2010-12-16T12:31:53.970 に答える
3

テストで 1 つの機能のみをテストするようにしてください。名前とアサートもそれと完全に一致している必要があります。たとえば、expand() 関数を変数ハンドラーに追加する場合、テストは (大まかに) test_expands_variables または should_expand_defined_variable、または命名規則に合ったものを呼び出す必要があり、アサートは戻り値または副作用に対してのみ行う必要があります。関数呼び出しの。よくある間違いは、セットアップ手順をアサートすることですが、セットアップ内のすべての機能には、まさにそのアサートが既に配置されている独自のテストが必要です。どこでも同じことを主張すると、どのテストを修正する必要があるかが突然わかりにくくなります。

TDD ループ全体の感触をつかむための出発点として、コードのカタを試してみることをお勧めします。ローマ数字コンバーターは、最初にテストを作成するための一般的な最初のイントロです。最初は、少し変更を加えるたびにテストを実行することについて、本当に神経質になりましょう。コツをつかめば、どれだけ執着する必要があるか/すべきかがわかりますが、初心者がリズムを​​つかむには、通常、本当に知識が必要です。

于 2010-12-16T11:48:49.853 に答える
0

Christian Johansen 著の「Test-Driven JavaScript Development」という本を読んで、Javascript での TDD に取り組み始めました。これは優れており、TDD のほぼすべての側面に対応し、JS に適用します: http://tddjs.com/

于 2011-01-30T16:35:20.583 に答える