web-dev-qa-db-ja.com

angularアプリケーションでユニットテストを何をしていますか？

私は現在チームで働いており、チームに加わったとき、ユニットや統合のテストは一切していませんでした。

過去2年間、私は少しずつdotnetユニットテストをプッシュしてきましたが、それは現在、日常のワークフローの一部と見なされています。統合テストも実施されており、注目すべきポイントとして再び注目されています。チームは一般に、dotnet単体テストは間違いなく価値があること、およびdotnet統合テストも優れた追加であることに同意しますが、作成と設定には時間がかかります。

単体テストがほとんど存在しない領域は、角度/ UIコードです。私は再利用可能な機能などの単体テストを追加するように求めてきましたが、私とチームの他のメンバーの両方が、それが価値があるかどうかを定量化するのに苦労しているため、コンポーネントの単体テストはほとんどそのままにされています。 UIに単体テストを追加するいくつかの試みは、一連の単体テストを作成してしまいましたが、その価値を実際に理解している人はいませんでした。

つい最近、経験豊富な（そして非常に公然と意見を述べた）フロントエンド開発者がチームに加わりました、そして彼の意見は、angular UIユニットテストは完全にそして全く価値がないということです。私はこれに単に同意することを恐れていますこれは、当初はドットネットユニットテストに関するチームの見解と似ていましたが、今は反対の考えです。

質問：angularアプリケーションで何をテストし、ソフトウェアの品質/安定性を向上させると思いますか？

考えられる論点：単体テストはありますか？もしそうなら-あなたは何をテストしますか？コンポーネント？サービス？状態？実際のDOMの変更？代わりに、エンドツーエンドのテストがありますか？時間（コスト）対利益をどのように定量化しますか？

どんな洞察/ etcも非常に評価されます！

ありがとう！

unit-testingtestingintegration-testsangularend-to-end
3
Ross

質問：angularアプリケーションで何をテストし、ソフトウェアの品質/安定性を向上させると思いますか？

ComponentsUI-logicをカプセル化するコンポーネントの場合、コンポーネントの動作をカバーしようとします。

たとえば、「ListComponent」：

このコンポーネントは製品をリストし、しきい値（価格<しきい値）によって単一の製品を強調表示する必要があります。

次のことを確認します。

  • コンポーネントが作成されます
  • コンポーネントは入力として与えられたすべての要素を表示します
  • コンポーネントは、条件に一致する要素に「ハイライト」クラスを追加します

「ListControllerComponent」を使用した別の例：

このコンポーネントは、サービスから製品を取得し、ユーザーに入力フィールドを提供して、しきい値を変更します。

次のことを確認します。

  • コンポーネントが作成する
  • 製品を入手しようとする試みが行われる
  • レンジスライダーの入力値が反映されます。

これらのテストが成功した場合、UIは説明したとおりに機能すると想定できます。独自のUIロジックのみをカバーします。ブラウザAPIのAngularであり、どこかに提供されたデータが有効であると想定しています。

ServicesHttpClientをラップするだけのサービスの場合、個別のテストを記述しませんが、モックオブジェクトはこのサービスは他のテストにとって決定的です。

製品モデル：

export interface Product {
    id: number;
    name: string;
    price: number;
};

ProductService：

export class ProductService {

  constructor(private http: HttpClient) { }

  public getProducts(): Observable<Product[]> {
      return this.http.get<Product[]>('products');
  }
}

ProductService：

export class ProductServiceMock {

    constructor() { }

    public getProducts(): Observable<Product[]> {
        return of(
            [
                { id: 1, name: 'Product A', price: 4 },
                { id: 2, name: 'Product B', price: 2.66 },
                { id: 3, name: 'Product C', price: 7 },
                { id: 4, name: 'Product D', price: 3 }
            ]
        );
    }
}

APIが変更されたと仮定すると、製品タイプには「price」というフィールドがなくなり、「price1」という名前になりました。これらの変更をフロントエンドに適用するには、製品モデルを変更する必要があります。

そして、テストの1つの値が表示されます。

  1. ProductServiceMockが一致しないタイプの価格の値を返すため、テストセットアップ全体が実行されません（TypeScriptエラー）！== price1
  2. これを修正すると、「コンポーネントがハイライトを追加する」テストが失敗することがわかります。

いくつかの主要なAPIブレークが大きな勝利である場合、アプリケーションのどの部分に調整が必要かを知っていると思います

このため、単独でテストする価値はあります。

完全な例が追加されています。 https://stackblitz.com/github/EnricoVogt/testangular

2
enno.void