reassure
v1.3.0
ReactおよびReact Nativeのパフォーマンステストコンパニオン。
ドキュメントを読んでください
reassure-tests.sh ）.gitignorereassure-tests.sh ）measureRenders機能MeasureRendersOptionsタイプmeasureFunction関数MeasureFunctionOptionsタイプconfigureresetToDefaults関数Reactネイティブアプリが常にうまく機能しているようにしたいです。この目標の一部として、アプリをプロファイルし、レンダリングパターンを観察し、適切な場所にメモを適用します。 。
Lessureを使用すると、CIまたはローカルマシンでのNative Native Appパフォーマンス回帰テストを自動化できます。同様に、アプリがまだ正しく機能していることを自動的に確認する統合テストとユニットテストを作成すると、アプリがまだパフォーマンスが発生していることを確認するパフォーマンステストを作成できます。
それについては、React Performance Testing Libraryと考えることができます。実際、Reasusureは、Reactネイティブテストライブラリテストとセットアップをできるだけ再利用するように設計されています。
レンダリング特性（期間とカウント）を測定することにより、安定したバージョンと比較するレンダリング特性（期間とカウント）を測定することにより、機能することができます。シナリオを複数回繰り返し、ランタイム環境によって引き起こされるレンダリング時間のランダムな変動の影響を減らします。次に、統計分析を適用して、コードの変更が統計的に有意であるかどうかを判断します。その結果、結果を要約する人間の読み取り可能なレポートを生成し、CIに表示するか、プルリクエストへのコメントとして表示します。
コンポーネントのレンダリング時間の測定に加えて、通常のJavaScript関数の実行も測定できます。
Lessureをインストールするには、アプリフォルダーで次のコマンドを実行します。
糸を使用します
yarn add --dev reassureNPMを使用します
npm install --save-dev reassureまた、機能するJestセットアップと、React Native Testing LibraryまたはReact Testingライブラリのいずれかのいずれかが必要です。
インストールガイドを参照してください。
あなたは私たちの例プロジェクトを確認できます：
Lessureは、インストールしたテストライブラリを検出しようとします。両方とも反応ネイティブテストライブラリと反応テストライブラリが存在する場合、それについて警告し、反応ネイティブテストライブラリに優先されます。 configureオプションを使用して、使用するテストライブラリを明示的に指定できます。
configure ( { testingLibrary : 'react-native' } ) ;
// or
configure ( { testingLibrary : 'react' } ) ;Jestセットアップファイルに設定する必要があります。必要に応じて、特定のテストファイルをオーバーライドできます。
ライブラリがインストールされたので、 .perf-test.js / .perf-test.tsx拡張機能を備えたファイルに最初のテストシナリオを記述できます。
// ComponentUnderTest.perf-test.tsx
import { measureRenders } from 'reassure' ;
import { ComponentUnderTest } from './ComponentUnderTest' ;
test ( 'Simple test' , async ( ) => {
await measureRenders ( < ComponentUnderTest / >);
} ) ;このテストでは、取り付け中のComponentUnderTestのレンダリング時間と結果として同期効果を測定します。
注：selsureは、jestの
--testMatchオプションをvalue"**/__perf__/**/*.[jt]s?(x)", "**/*.(perf|perf-test).[jt]s?(x)"。ただし、カスタム--testMatchまたは--testRegexオプション）を渡す場合は、自社のグローブを通過するためにreassure measureスクリプトに追加することができます。 jestドキュメントの--testMatchと--testRegexの詳細
コンポーネントにAsyncロジックが含まれている場合、または相互作用をテストする場合は、 scenarioオプションを渡す必要があります。
import { measureRenders } from 'reassure' ;
import { screen , fireEvent } from '@testing-library/react-native' ;
import { ComponentUnderTest } from './ComponentUnderTest' ;
test ( 'Test with scenario' , async ( ) => {
const scenario = async ( ) => {
fireEvent . press ( screen . getByText ( 'Go' ) ) ;
await screen . findByText ( 'Done' ) ;
} ;
await measureRenders ( < ComponentUnderTest / >, { scenario });
} ) ; scenario関数の本体は、おなじみの反応ネイティブテストライブラリ方法を使用しています。
v10.1.0より低いReactネイティブテストライブラリのバージョンを使用する場合、 screenヘルパーが利用できない場合、 scenario関数はそれを最初の引数として提供します。
import { measureRenders } from 'reassure' ;
import { fireEvent } from '@testing-library/react-native' ;
test ( 'Test with scenario' , async ( ) => {
const scenario = async ( screen ) => {
fireEvent . press ( screen . getByText ( 'Go' ) ) ;
await screen . findByText ( 'Done' ) ;
} ;
await measureRenders ( < ComponentUnderTest / >, { scenario });
} ) ;テストに非同期の変更が含まれている場合、rntlからのfindByクエリの使用、 waitFor 、またはwaitForElementToBeRemoved関数を使用するなど、これらの変更が解決するのをシナリオが待機することを確認する必要があります。
最初のテストパフォーマンスを測定するには、端末で次のコマンドを実行する必要があります。
yarn reassureこのコマンドは、JESTを使用してテストを複数回実行し、パフォーマンス統計を収集し、 .reassure/current.perfファイルに書き込みます。セットアップを確認するには、コマンドを初めて実行した後に出力ファイルが存在するかどうかを確認します。
注：誤って結果をコミットしないように、
.gitignoreファイルに.reassure/フォルダーを追加できます。
CLIの安心は、GITを使用しているときにソースコードのブランチ名を自動的に検出し、ハッシュをコミットします。これらのオプションをオーバーライドできます。たとえば、別のバージョン制御システムを使用している場合：
yarn reassure --branch [branch name] --commit-hash [commit hash]パフォーマンスの変更を検出するには、コード電流（修正コード）とベースライン（ main点など）の2つのバージョンのパフォーマンスを測定する必要があります。 2つのブランチのパフォーマンスを測定するには、Gitのブランチを切り替えるか、リポジトリの2つのコピーをクローンする必要があります。
このタスクを自動化して、CIで実行します。そのためには、パフォーマンステストスクリプトを作成する必要があります。 reassure-tests.shに保存する必要があります。
ブランチを変えるアプローチを使用したこのようなスクリプトの単純なバージョンは、次のとおりです。
#! /usr/bin/env bash
set -e
BASELINE_BRANCH= ${GITHUB_BASE_REF := " main " }
# Required for `git switch` on CI
git fetch origin
# Gather baseline perf measurements
git switch " $BASELINE_BRANCH "
yarn install
yarn reassure --baseline
# Gather current perf measurements & compare results
git switch --detach -
yarn install
yarn reassureCI統合とすべての前提条件をより便利に設定するために、最初に必要なすべてのテンプレートを生成するためにCLIコマンドを準備しました。
単純に実行：
yarn reassure initこれにより、次のファイル構造が生成されます
├── <ROOT>
│ ├── reassure-tests.sh
│ ├── dangerfile.ts/js (or dangerfile.reassure.ts/js if dangerfile.ts/js already present)
│ └── .gitignore
reassure-tests.sh ）CIで安心することを可能にする基本的なスクリプト。次のセクションのこのファイルの重要性と構造の詳細。
プロジェクトに既にdangerfile.ts/js含まれている場合、CLIはそれを無効にしません。代わりに、 dangerfile.reassure.ts/jsファイルを生成し、都合の良いときに独自のファイルを比較および更新することができます。
.gitignore .gitignoreファイルが存在し、 reassureの言及が表示されない場合、スクリプトは.reassure/ディレクトリを最後に追加します。
reassure-tests.sh ）パフォーマンスの変更を検出するには、コード電流（修正コード）とベースライン（ main点など）の2つのバージョンのパフォーマンスを測定する必要があります。 2つのブランチのパフォーマンスを測定するには、Gitのブランチを切り替えるか、リポジトリの2つのコピーをクローンする必要があります。
このタスクを自動化して、CIで実行します。そのためには、パフォーマンステストスクリプトを作成する必要があります。 reassure-tests.shに保存する必要があります。
ブランチを変えるアプローチを使用したこのようなスクリプトの単純なバージョンは、次のとおりです。
#! /usr/bin/env bash
set -e
BASELINE_BRANCH= ${GITHUB_BASE_REF := " main " }
# Required for `git switch` on CI
git fetch origin
# Gather baseline perf measurements
git switch " $BASELINE_BRANCH "
yarn install
yarn reassure --baseline
# Gather current perf measurements & compare results
git switch --detach -
yarn install
yarn reassure最終的なセットアップステップとして、パフォーマンステストスクリプトを実行して結果を出力するようにCIを構成する必要があります。現時点で出力を提示するために、すべての主要なCIツールをサポートするDanger JSと統合します。
JSセットアップが機能する必要があります。
次に、DangerFileにDanger JSプラグインを安心させます。
// /<project_root>/dangerfile.reassure.ts (generated by the init script)
import path from 'path' ;
import { dangerReassure } from 'reassure' ;
dangerReassure ( {
inputFilePath : path . join ( __dirname , '.reassure/output.md' ) ,
} ) ; DangerFile（ dangerfile.jsまたはdangerfile.ts ）がない場合は、追加の変更を加えることなく、 reassure initスクリプトによって生成されたものを使用できます。
また、私たちの例ファイルDangerFileにもあります。
最後に、CI構成でパフォーマンステストスクリプトと危険の両方を実行します。
- name : Run performance testing script
run : ./reassure-tests.sh
- name : Run Danger.js
run : yarn danger ci
env :
GITHUB_TOKEN : ${{ secrets.GITHUB_TOKEN }}Githubワークフローの例を確認することもできます。
上記の例はGitHubアクションに基づいていますが、他のCI構成ファイルと類似している必要があり、そのような場合は参照としてのみ機能する必要があります。
注：パフォーマンステストは、通常の統合テストよりもはるかに長く実行されます。それは、各テストシナリオを複数回実行し（デフォルト、10）、コードの2つのブランチについてそれを繰り返すためです。したがって、各テストはデフォルトで20回実行されます。それは、その数をさらに高くしない限りです。
React.Profilerを使用したパフォーマンス測定中に、マイクロ秒の精度で反応成分レンダリング時間を測定します。これは、マシンに応じて、同じコードがより速くまたは遅くなることを意味します。このため、ベースラインと電流の測定値を同じマシンで実行する必要があります。最適には、次々に実行する必要があります。
さらに、CIエージェントは、意味のある結果を達成するために安定したパフォーマンスを持つ必要があります。エージェントがパフォーマンスに一貫している限り、エージェントが高速であるか遅いかは関係ありません。そのため、レンダリング時間の測定に影響を与える可能性のある他の作業のパフォーマンステスト中にエージェントを使用すべきではありません。
マシンの安定性を評価するために、 reassure check-stabilityコマンドを使用できます。現在のコードでパフォーマンス測定値が2回実行されるため、ベースラインと現在の測定値は同じコードを参照しています。そのような場合、予想される変更は0％です（変更なし）。ランダムなパフォーマンスの変更の程度は、マシンの安定性を反映します。このコマンドは、CIとローカルマシンの両方で実行できます。
通常、ランダムの変更は5％未満でなければなりません。 10％以上の結果は高すぎると見なされます。つまり、マシンの安定性を微調整することに取り組む必要があります。
注：最後の手段のトリックとして、テストのすべてまたは一部のテストでは、すべてまたは一部のテストで10〜20、50、または100のデフォルト値から
runオプションを増やすことができます。ただし、テストはさらに長く実行されます。
GitHubワークフローの例を参照できます。
この例を見ると、テストシナリオは特定のカテゴリに割り当てることができることに気付くことができます。
measureRenders機能RNTL render関数のカスタムラッパーは、 React.Profilerコンポーネント内で通過した画面をレンダリングし、そのパフォーマンスを測定し、結果を出力ファイルに書き込みます。テストのアスペクトをカスタマイズできるようにするオプションのoptionsオブジェクトを使用できます
async function measureRenders (
ui : React . ReactElement ,
options ?: MeasureRendersOptions ,
) : Promise < MeasureResults > { MeasureRendersOptionsタイプ interface MeasureRendersOptions {
runs ?: number ;
warmupRuns ?: number ;
wrapper ?: React . ComponentType < { children : ReactElement } > ;
scenario ?: ( view ?: RenderResult ) => Promise < any > ;
writeFile ?: boolean ;
}runs ：特定のテストのシリーズあたりの実行数warmupRuns ：実際の実行前に実行および破棄される追加のウォームアップ実行の数（デフォルト1）。wrapper ： uiにラップされるProviderなどの反応コンポーネント。注： wrapper自体のレンダリング期間は、結果から除外されます。ラップされたコンポーネントのみが測定されます。scenario ：RNTLまたはRTL関数を使用してUI内のユーザーインタラクションを定義するカスタムアナイク機能writeFile ：（デフォルトtrue ）は、出力をファイルに書き込む必要があります。 measureFunction関数同期関数をラップし、実行時間を測定し、結果を出力ファイルに書き込むことができます。オプションのoptions使用して、テストの側面をカスタマイズできます。注：実行数は常に1つになります。
async function measureFunction (
fn : ( ) => void ,
options ?: MeasureFunctionOptions
) : Promise < MeasureResults > { MeasureFunctionOptionsタイプ interface MeasureFunctionOptions {
runs ?: number ;
warmupRuns ?: number ;
}runs ：特定のテストのシリーズあたりの実行数warmupRuns ：実際の実行前に実行および破棄される追加のウォームアップ実行の数。測定スクリプトで使用されるデフォルトの構成。この構成オブジェクトは、 configure関数を使用してオーバーライドできます。
type Config = {
runs ?: number ;
warmupRuns ?: number ;
outputFile ?: string ;
verbose ?: boolean ;
testingLibrary ?:
| 'react-native'
| 'react'
| { render : ( component : React . ReactElement < any > ) => any ; cleanup : ( ) => any } ;
} ; const defaultConfig : Config = {
runs : 10 ,
warmupRuns : 1 ,
outputFile : '.reassure/current.perf' ,
verbose : false ,
testingLibrary : undefined , // Will try auto-detect first RNTL, then RTL
} ; runs ：テストごとのシリーズでの繰り返しの実行の数（より多くのデータを集約することにより、より高い精度を可能にします）。注意して処理する必要があります。
warmupRuns ：実際の実行前に行われ、破棄される追加のウォームアップ実行の数。 outputFile ：ファイルの名前レコードはverbose 'react'保存されますtestingLibrary render cleanupためにログをより'react-native'させます。機能をrenderおよびcleanup configure function configure ( customConfig : Partial < Config > ) : void ; configure関数は、デフォルトの構成パラメーターをオーバーライドできます。
resetToDefaults関数 resetToDefaults ( ) : void現在の構成を元のdefaultConfigオブジェクトにリセットします
利用可能な環境変数を使用して、テストランナーの設定を変更できます。
TEST_RUNNER_PATH ：テストランナーの代替パス。デフォルトは'node_modules/.bin/jest'またはwindows 'node_modules/jest/bin/jest'TEST_RUNNER_ARGS ：ランナーに供給された一連の引数。デフォルトは'--runInBand --testMatch "**/__perf__/**/*.[jt]s?(x)", "**/*.(perf|perf-test).[jt]s?(x)"'例：
TEST_RUNNER_PATH=myOwnPath/jest/bin yarn reassureリポジトリと開発ワークフローに貢献する方法を学ぶための寄稿ガイドを参照してください。
mit
Lessureはオープンソースプロジェクトであり、常に自由に使用できます。このプロジェクトは、Entainと緊密なパートナーシップで開発されており、元々は社内プロジェクトでした。 React＆Reactネイティブの生態系を開発する意欲のおかげで、オープンソースにすることにしました。かっこいいと思うなら、主演してください？
CallStackはReactおよびReactのネイティブ専門家のグループです。これらのサポートが必要な場合、またはこんにちはと言いたい場合は、[email protected]までご連絡ください！
プロジェクトのように？ ⚛️クライアントのために素晴らしいものをしているコールスタックチームに参加し、ネイティブのオープンソースを反応させるドライブ！
