TDD React.jsアプリケーション

20,000 Lieues Sous les Mersのヘッツェル版



テスト（「ハワード・フィリップス・ラブクラフトの仕事を知っている人なら誰でも理解する」という意味で）「蘇生者」であることに注意してください。



テストとテストのトピックを続けて、私たちのアプローチ、React.jsで書かれたシングルページアプリケーション（SPA）でどのように見えるか、 テスト駆動開発（TDD）がこれにどのように役立ったか、そして私たちが来た理由について少し書きたいと思いますレデューサーとAPIサービスもテストで覆われているという事実。



ここでjest 、 スナップショットテスト、またはストーリー ショットが見られる場合は、すぐにこのメモを閉じてください。 ここで新しいライブラリまたはアプローチから何かを見つけたい場合は、すぐに閉じてください。 上記のいずれも使用しませんでした。 おそらく、これらのツールを使用して新しいプロジェクトを開始しますが、今のところはその方法が判明しました。



これらの手法の多くはさまざまなサイトやフォーラムで説明されていますが、テストがどのように見えるかがわかりました。 さらに、これらのリンクを以下に提供します。

ツール

私たちには非常に標準的なものがあり、紳士用のツールキットもあります。



テストを（ BDDスタイルで）実行して記述するには、 mochaライブラリを使用します。 Sinonはスタブとスパイを提供し、 chaiライブラリのテスト関数を使用し、 酵素を使用してGUI要素をマウントします。 機能テストまたはエンドツーエンドテストを作成するために、 jasmine frameworkで 分度器を使用します。



残念ながら、 ペンテストに適切な重点を置いていませんでした。この部分で脆弱性を検索するために使用したのは、 nspモジュールとnodesecurity.ioだけでした 。 確かに、クライアントには何も見つかりませんでしたが、サーバーモジュールには何かが見つかりました。







また、テストの段階の1つは、 eslintツールを使用してコードの形式とスタイルをチェックすることです。

テスト駆動開発によるコンポーネント駆動開発

開発とテストにおいて、私たちはまだ有名なテストファーストの原則を順守しています。 そして、原則として、多くのクライアント開発者は、このドキュメントがまだ存在しないときに、開発プロセスでどのタグとスタイルを使用する必要があるのか​​わからないときに、ドキュメントのHTML構造をチェックするテストをどのように書くことができますかという質問があります。



最新のクライアントアプリケーション開発は、 コンポーネントの概念に基づいています 。 デザイナのレイアウトは、分解の過程で、複合コンポーネントと基本コンポーネントに分割されます。 クライアントでTDDについて話すときは、コンポーネントレベルを意味します。このGUI要素がpタグまたはdivタグを使用して実装されているかどうかは、特に重要ではありません。実装されることが重要です。 すなわち 次の複合コンポーネント（ページ）の実装がまだありません：







このコンポーネント自体とその内部スケルトンの存在を確認するテストから開始できます。







テストもアプリケーションの一部であることを忘れないでください。この部分では、他の場合と同じように 、 「 自分自身を繰り返さない」（DRY） 、 「あなたはそれを必要としません」（YAGNI） 、 シンプルで愚かな”（KISS）とコードの清潔さを保ってください 。



テストファイルはいずれも、テスト対象のコンポーネントをマウントし、このコンポーネントで作業中にユーザーが実行できるアクションでスパイウェアをハングアップするファクトリメソッドの説明で始まります。 ほとんどの場合、これはもちろん、データウェアハウスの変更にサブスクライブしているコンポーネントに適用されます。 アクションは、条件付きで、状態が変化するストレージ（順番に永続ストレージと非永続ストレージに分割される）とページナビゲーションに分割できます。







ファクトリメソッドは、便宜上、酵素ライブラリを使用してマウントされ、 sinonライブラリスパイに置き換えられるコンポーネントおよびアクション関数を返します。 これはリポジトリにサブスクライブされる複合コンポーネントであるため、コンポーネントファイルでリポジトリをエミュレートしないように1つのトリックを使用して、2つの方法でエクスポートします。







1つ目はテスト用で、2つ目はリポジトリの状態の変更にサインアップするために直接高次コンポーネントにラップされています。



そして、これが最初の「赤」テストです











コンポーネントのrenderメソッドを実装し、 赤緑のリファクタリングのすべての標準に取り組みます。 その後、テストを再度実行します。







さらに、テスト対象の親要素（論理フラグ、ボタン名、テストデータ）から転送された値に応じて、埋め込みコンポーネントのプロパティ、現在の状態、および特性をより詳細にテストできます。







次のステップは、アクションを検証することです。 これは、 test-firstのスタイルでも実行できます。 「アクティブなプロジェクトを取得」アクションは、コンポーネントのマウント時にコンポーネントのライフサイクルメソッド内で呼び出されると想定しています。 同時に、ボタンが押されると遷移アクションが呼び出されます。 すなわち ボタンのクリックをシミュレートする必要があります。 これらの仮定により、コンポーネントにロジック自体を実装する前でも、次のテストのペアを実装できます。 もう1つのトリックは、アクション用に個別のインポートされたネームスペースを使用することです。これにより、ターゲットコンポーネントのインポートセクションがクリーンになり、モック、スタブ、スパイのテスト時に便利になります。







動作中のTDD。 同様に、このコンポーネントを完全に実装するまで進みます。 このアプローチにより、シンプルで基本的なものから、リポジトリに複合してサブスクライブするものまで、すべてのコンポーネントを開発しました。

「私は、アプリケーションコードを直接書くよりもテストを開発したいようです」

Andrey Antonyuk、開発者

そして、はい、ほとんど言及するのを忘れていたので、コードでテストを混乱させないために、テストデータとテスト構造を別々のファイルに入れました。

機能テスト

すべてが、単体およびシステムテストでターゲットコンポーネントを徹底的にテストしているように見えます。 ただし、コンポーネントのマウントは人工的な環境（ TestBed ）であり、残念ながらこの方法では実際のユースケースをシミュレートしません。 この種のエミュレーションには、機能テストと、すでに確立されている分度器があります。



プロジェクトでは、人気のあるPageObjectテンプレートを積極的に使用しています。 その要素にアクセスするためのメソッドを提供するオブジェクトとしてページを操作することで、 テストファースト （PageObject-First / POF）のスタイルで引き続き作業できます。

「PageObjectテンプレートが好きです。テストをすれば、テストがすっきりしてシンプルでわかりやすくなります」 Dmitry Santotsky、開発者

テストを作成する段階では、特定のセレクターとHTML構造に焦点を合わせる必要はありません。 ヘッダーをテストする場合は、単にgetHeaderLabelメソッドを呼び出します。 このようにして、TDDで簡単に作業できます。







ページを実装する赤緑のリファクタリング段階で、特定のセレクターを示します。

単体テストによるギアボックス

テストは、ある種のロジック、ある条件を含むものすべてを意味します。 ギアボックスは、原則として、 純粋な機能として実装されます 。 テストに最適なものは何ですか？ mokamiやスタブで処理する必要のある副作用や依存関係はなく、入力データと出力データのみです。 罪は彼らをテストでカバーしません！



しかし、真剣に、それから私たちが持っているギアボックスに、取るに足らないが、非常に重要なロジックがあります。 状態を変更しています。この場合、リポジトリの特定の部分をチェックする必要があります。 さらに、ギアボックス内で、データ配列を何らかの方法で処理し、いくつかの条件を記述することができます。 これらの場所では、人々はしばしば間違いを犯します。 要するに、彼らは突然出てきます。 これは私たちのプロジェクトで何度も見られました。 テストを介してリデューサーを作成する場合、到着したイベントのどのデータを処理し、そのような処理後にストアがどの新しい状態を受け入れるかについて少なくとも2回考えます。







頻繁に使用される手法の1つは、リポジトリの初期状態（INIT_STATE）と変更（DIRTY_STATE）を使用したテストです。 ギアボックステストを「初期状態で」と「状態を変更して」に分割し始めたのは、開発者のDima Poluyanでした。 彼の意見では、状態が変更されたテストは最初のテストよりもさらに便利です。

ユニットテストによるAPIサービスとアクション

ここでは、ギアボックスと同じ原理です。 呼び出す必要のあるエンドポイントと、このポイントのリクエストを作成する方法を数回検討します。 最終的に、TDDアプローチでは、テストを介してコードを記述する必要があります。つまり、事前に作成されたテストなしではサービスもレデューサーも実装できません。







データ検索のフィルター値を形成する多くのパラメーターを渡す必要があります。 これにはどのHTTP動詞を選択しますか？ 通常、彼らはサービスエンドポイントの実装を開始するときにそれについて考えます。 テストファーストのアプローチでは、テストの実装中にそれについて考える必要があります。



もちろん、私たちは、怠け者のように、サービスをテストでカバーすべきだという結論にすぐには至りませんでした。 それはすべて、いくつかの小さな間違いから始まりました。 一部のエンドポイントは異なる場所で呼び出されましたが、異なるフィルターパラメーターを使用していました。 サービスメソッドの内部には、パラメーターに応じて、必要なフィルター値を形成するか、それなしで要求を送信するロジック（条件）が書き込まれました。 しばらくして、開発者の1人がデフォルトの関数パラメーターをフィルターのサービスメソッドに追加しました。 これにより、メソッドがパラメーターなしで呼び出された場所が破損し、データが間違った方法で送られてきました。



このケースは始まりであり、テストを通じてAPIサービスを開発することも求められました。



機能とアクションのほぼ同じ動機。 さらに、彼らのために、テストはギアボックスのテストと一緒にすぐに書かれ、それらは複雑であり、一緒に行くかのようです。

トレーニングテスト

使用を余儀なくされた別のタイプのテストは、トレーニングテストです。 私たちのプロジェクトの1つで、サーバーはGo開発者の独立したチームによって開発されました。 残念ながら、サーバー部分の開発の開始は、クライアント部分の開始後に計画されていました。 最初は、模擬データを使用してAPIサービスを開発しました。 データ形式は、エンドポイントよりも早く配信されたチャットとドキュメントによるGo開発者の説明に基づいていました。 エンドポイントの出現により、その調査（形式の検証と理解）およびそれとの統合はトレーニングテストを通過しました。







そのため、私たちは知識をドキュメントと同期させ、私たちの側ではないエラーに対して自分自身を保証しました。 Go-developersは統合テストでサービスのエンドポイントをカバーしませんでしたが、これは問題ではなく、トレーニングテストで行いました。 最終的に、組み立てられたクライアントパーツを配信する前でも、すべてのサービスエンドポイントが安定しており、統合に関してアプリケーションが期待どおりに機能するというPMOレポートを送信しました。 トレーニングテストが健康テスト（煙テスト、健全性チェック）に変わったと言えます







->トレーニングテストの詳細：未知のものとの戦い

継続的な統合と配信

何らかの方法で自動化されておらず、CI / CDプロセスに関与していない場合、リポジトリ内のテストの存在自体は役に立ちません。



私たちの場合、テストは最大3回実行されます。



最初のステップは、開発者をコミットすることです。開発者は自分のマシンからコミットします。 この操作が完了すると、 git pre-commitフックが自動的にトリガーされ、ローカル開発マシンですべてのテストが実行されます。 成功すると、コードはgitlabに送られ、 マージ要求がコードビューに送信されます。



すべてが正常であれば、ブランチは開発にマージされ、リモートマシンで2回目のテスト実行が開始されます。これはいわゆるgitlabランナーであり 、その機能はgitlab ciによって提供されます。







そして最後の段階は、各スプリントの終わりにJenkinsツールによって開始されるリリースであるテスト実行です。これはCDプロセスの一部です（以前はJenkinsでビルドをより頻繁に、スケジュールに従って実行していました）。

カバレッジ

私たちはそれを持っていますが、私はそれを信じていません。 nycモジュールを使用します。このモジュールは、 内部では同じイスタンブールです。 なんで信じられないの？ カバレッジを測定するすべての機器は「バカ」だからです。 彼らは単にテストで関数（クラス/メソッド）を呼び出すという事実をチェックしますが、このアプローチはいわゆる計算機の例を完全に破壊します。



数学的な除算の機能をテストする必要があるとします。 1つのテスト「 2/2 = 1」を記述すると、テストカバレッジテストツールは起動後に100％を表示します。 しかし、そうですか？ 100％が表示され、作業が正常に行われたことを示す指標の1つですが、優れたコードカバレッジテストを数えるだけでいいですか？



しかし、 「2/0」はどうですか？ または「2 / null」 ？ または「NaN / undefined」 ？

***

どういうわけか、すべてがシンプルで折り畳まれています。 そして、困難はどこにありますか？



メモの最後で、この考えが頭に落ち着いた場合、これは私たちが目標に到達したことを意味します。 React.jsアプリケーションをどのようにテストしますか？ artur.basak.devingrodno@gmail.comに書き込みます