19

私は Javacript 単体テストにまったく慣れていません。1 つのことが私を悩ませ続けます。JavaScript をテストするとき、DOM 操作を行う必要があることがよくあります。コントローラー/コンポーネントでメソッド/関数を単体テストしているように見えますが、テンプレートの HTML 要素に依存する必要があります。id (またはテスト ケースでセレクターとして使用されていた属性) が変更されたら、テスト ケースも変更する必要があります。これは単体テストの目的に違反しませんか?

4

3 に答える 3

13

JavaScript 単体テストの最も難しい部分の 1 つは、テストではなく、コードをテスト可能にする方法を学習することです。

テスト可能なロジックと DOM 操作を明確に分離して、コードを構造化する必要があります。

私の経験則は次のとおりです。

DOM 構造に依存するものをテストしている場合、それは間違っています。

要約: データ操作と論理演算のみをテストしてください。

于 2013-09-17T14:29:09.727 に答える
6

私は@BentOnCodingに敬意を表して同意しません。ほとんどの場合、コンポーネントはそのクラス以上のものです。コンポーネントは、HTML テンプレートと JavaScript/TypeScript クラスを結合します。そのため、テンプレートとクラスが意図したとおりに連携することをテストする必要があります。クラスのみのテストでは、クラスの動作について知ることができます。しかし、コンポーネントが適切にレンダリングされ、ユーザー入力に応答するかどうかはわかりません。

統合テストでテストすべきだと言う人もいます。ただし、統合テストは、作成/実行が遅く、実行/保守に (時間とリソースの点で) よりコストがかかります。そのため、統合テストでコンポーネントの機能のほとんどをテストすると、速度が低下する可能性があります。

統合テストをスキップする必要があるという意味ではありません。統合テストと E2E テストは、単体テストよりも時間と費用がかかる場合がありますが、アプリが意図したとおりに動作するという確信が得られます。統合テストは、個々のユニット/コンポーネントを組み合わせてグループとしてテストする場所です。コンポーネントのテンプレートをテストする唯一の場所と考えるべきではありません。

于 2020-09-08T10:46:49.287 に答える