reassure
v1.3.0
Leistungstestbegleiter für React und React Native.
Lesen Sie die Dokumente
reassure-tests.sh ).gitignorereassure-tests.sh )measureRenders FunktionMeasureRendersOptions TypmeasureFunction FunktionMeasureFunctionOptions TypconfigureresetToDefaults -FunktionSie möchten, dass Ihre React Native App jederzeit gut und schnell funktioniert. Als Teil dieses Ziels profilieren Sie die App, beobachten Rendermuster, wenden Memoisierung an den richtigen Stellen usw. .
Mit Sicherheit können Sie die React Native App -Leistungsregressionstests auf CI oder eine lokale Maschine automatisieren. Auf die gleiche Weise schreiben Sie Ihre Integrations- und Unit -Tests, die automatisch überprüfen, ob Ihre App noch korrekt funktioniert . Sie können Leistungstests schreiben, die überprüfen, ob Ihre App noch leistungsfähig funktioniert .
Sie können es als eine React -Leistungstestbibliothek betrachten. In der Tat soll beruhigend so konzipiert werden, dass sie so viel wie möglich von Ihren React Native Testing Library und so eingerichtet werden.
Beruhigen Sie die Arbeiten, indem Sie die Rendereigenschaften - Dauer und Zählung - des von Ihnen bereitgestellten Testszenarios messen und diese mit der stabilen Version vergleichen. Es wiederholt das Szenario mehrmals, um die Auswirkungen zufälliger Schwankungen der Renderzeiten durch die Laufzeitumgebung zu verringern. Anschließend wird die statistische Analyse angewendet, um festzustellen, ob die Codeänderungen statistisch signifikant sind. Infolgedessen erzeugt es einen menschlich lesbaren Bericht, in dem die Ergebnisse zusammengefasst und auf dem CI oder als Kommentar zu Ihrer Pull-Anfrage angezeigt werden.
Zusätzlich zur Messung der Komponenten kann die Ausführung regulärer JavaScript -Funktionen auch die Ausführung messen.
Um die Beruhigung zu installieren, führen Sie den folgenden Befehl in Ihrem App -Ordner aus:
Mit Garn
yarn add --dev reassureVerwenden von NPM
npm install --save-dev reassureSie benötigen auch ein funktionierendes Scherz -Setup sowie eine der React Native Testing Library oder eine React -Testbibliothek.
Siehe Installationshandbuch.
Sie können unsere Beispielprojekte überprüfen:
Beruhigen Sie, dass Sie versuchen, festzustellen, welche Testbibliothek Sie installiert haben. Wenn sowohl React Native Testing Library als auch React -Testbibliothek vorhanden sind, warnen Sie davor und geben Sie Vorrang, um die native Testbibliothek zu reagieren. Sie können explizit angeben, dass die Testbibliothek mithilfe configure verwendet werden soll:
configure ( { testingLibrary : 'react-native' } ) ;
// or
configure ( { testingLibrary : 'react' } ) ;Sie sollten es in Ihrer Scherz -Setup -Datei festlegen und können sie bei Bedarf in bestimmten Testdateien überschreiben.
Nachdem die Bibliothek installiert ist, können Sie Ihr erstes Testszenario in einer Datei mit .perf-test.js / .perf-test.tsx Erweiterung schreiben:
// ComponentUnderTest.perf-test.tsx
import { measureRenders } from 'reassure' ;
import { ComponentUnderTest } from './ComponentUnderTest' ;
test ( 'Simple test' , async ( ) => {
await measureRenders ( < ComponentUnderTest / >);
} ) ; Dieser Test misst die Renderzeiten der ComponentUnderTest während der Montage und der daraus resultierenden Synchronisierungseffekte.
HINWEIS : Die Beruhigung wird automatisch Test-Dateinamen mit der Option von Scherz
--testMatchmit dem Wert"**/__perf__/**/*.[jt]s?(x)", "**/*.(perf|perf-test).[jt]s?(x)". Wenn Sie jedoch eine benutzerdefinierte Option--testMatchoder--testRegexübergeben möchten, können Sie sie dem Skriptreassure measureum Ihre eigene Globus zu übergeben. Mehr über--testMatchund--testRegexin Scherzdokumenten
Wenn Ihre Komponente eine asynchronisierte Logik enthält oder Sie eine Interaktion testen möchten, sollten Sie die scenario -Option übergeben:
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 });
} ) ; Der Körper der scenario verwendet bekannte React Native Testing Library -Methoden.
Bei der Verwendung einer Version der React Native Testing Library, die niedriger als V10.1.0 ist, wobei screen nicht verfügbar ist, liefert die scenario sie als erstes Argument:
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 });
} ) ; Wenn Ihr Test asynchronisierte Änderungen enthält, müssen Sie sicherstellen, dass das Szenario darauf wartet, dass sich diese Änderungen abgeben, z. B. mit findBy -Abfragen, waitFor oder waitForElementToBeRemoved -Funktionen von RNTL.
Um Ihre erste Testleistung zu messen, müssen Sie den folgenden Befehl im Terminal ausführen:
yarn reassure In diesem Befehl werden Ihre Tests mehrfach mithilfe von Scherz und Erfassungsstatistiken ausgeführt und in .reassure/current.perf -Datei geschrieben. Um Ihr Setup zu überprüfen, überprüfen Sie, ob die Ausgabedatei nach dem ersten Ausführen des Befehls vorhanden ist.
Hinweis: Sie können Ihre
.gitignore-Datei.reassure/Ordner hinzufügen, um die versehentlich begehen Sie Ihre Ergebnisse zu vermeiden.
Beruhigen Sie CLI, wird automatisch versuchen, Ihren Quellcode -Zweignamen zu erkennen und Hash zu verpflichten, wenn Sie Git verwenden. Sie können diese Optionen überschreiben, z. B. wenn Sie ein anderes Versionskontrollsystem verwenden:
yarn reassure --branch [branch name] --commit-hash [commit hash] Um Leistungsänderungen zu erkennen, müssen Sie die Leistung von zwei Versionen Ihres Codestroms (Ihres geänderten Codes) und der Grundlinie (Ihr Bezugspunkt, z. B. main ) messen. Um die Leistung an zwei Zweigen zu messen, müssen Sie Zweige in Git wechseln oder zwei Kopien Ihres Repositorys klonen.
Wir möchten diese Aufgabe automatisieren, um auf dem CI auszuführen. Dazu müssen Sie ein Skript zum Thema Performance-Test erstellen. Sie sollten es in Ihrem Repository speichern, zB als reassure-tests.sh .
Eine einfache Version eines solchen Skripts unter Verwendung eines Zweigveränderungsansatzes ist wie folgt:
#! /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 reassureUm die CI -Integration und alle Voraussetzungen bequemer zu erstellen, haben wir einen CLI -Befehl vorbereitet, um alle erforderlichen Vorlagen zu generieren, mit denen Sie beginnen.
Einfach rennen:
yarn reassure initDadurch wird die folgende Dateistruktur generiert
├── <ROOT>
│ ├── reassure-tests.sh
│ ├── dangerfile.ts/js (or dangerfile.reassure.ts/js if dangerfile.ts/js already present)
│ └── .gitignore
reassure-tests.sh )Grundlegendes Skript, mit dem Sie CI beruhigen können. Mehr zu der Bedeutung und Struktur dieser Datei im folgenden Abschnitt.
Wenn Ihr Projekt bereits eine dangerfile.ts/js enthält, wird die CLI es in keiner Weise außer Kraft setzen. Stattdessen generiert es eine Datei dangerfile.reassure.ts/js -Datei, mit der Sie Ihre eigenen nach Belieben vergleichen und aktualisieren können.
.gitignore Wenn die Datei .gitignore vorhanden ist und keine Erwähnungen der reassure angezeigt werden, wird das Skript das .reassure/ Verzeichnis bis zum Ende angehängt.
reassure-tests.sh ) Um Leistungsänderungen zu erkennen, müssen Sie die Leistung von zwei Versionen Ihres Codestroms (Ihres geänderten Codes) und der Grundlinie (Ihr Bezugspunkt, z. B. main ) messen. Um die Leistung an zwei Zweigen zu messen, müssen Sie Zweige in Git wechseln oder zwei Kopien Ihres Repositorys klonen.
Wir möchten diese Aufgabe automatisieren, um auf dem CI auszuführen. Dazu müssen Sie ein Skript zum Thema Performance-Test erstellen. Sie sollten es in Ihrem Repository speichern, zB als reassure-tests.sh .
Eine einfache Version eines solchen Skripts unter Verwendung eines Zweigveränderungsansatzes ist wie folgt:
#! /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 reassureAls endgültiger Setup -Schritt müssen Sie Ihren CI so konfigurieren, dass das Skript zum Testen von Leistungstests ausgeführt und das Ergebnis ausgegeben wird. Für die Präsentation der Ausgaben integrieren wir uns in die Gefahr JS, die alle wichtigen CI -Tools unterstützt.
Sie benötigen eine Arbeitsgefahr JS -Setup.
Fügen Sie dann Ihrer Dangerfile das Gefahren -JS -Plugin zu versichern:
// /<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' ) ,
} ) ; Wenn Sie keine DangerFile ( dangerfile.js oder dangerfile.ts ) haben, können Sie die von dem reassure init -Skript generierte verwenden, ohne zusätzliche Änderungen vorzunehmen.
Es ist auch in unserer Beispieldatei Dangerfile.
Führen Sie schließlich sowohl das Skript als auch das Performance -Test -Skript und die Gefahr in Ihrer CI -Konfiguration aus:
- name : Run performance testing script
run : ./reassure-tests.sh
- name : Run Danger.js
run : yarn danger ci
env :
GITHUB_TOKEN : ${{ secrets.GITHUB_TOKEN }}Sie können auch unseren Beispiel für GitHub -Workflow überprüfen.
Das obige Beispiel basiert auf GitHub -Aktionen, sollte jedoch anderen CI -Konfigurationsdateien ähnlich sein und in solchen Fällen nur als Referenz dienen.
Hinweis : Ihr Leistungstest läuft viel länger als die regulären Integrationstests. Es liegt daran, dass wir jedes Testszenario mehrmals ausführen (standardmäßig 10) und das für zwei Zweige Ihres Codes wiederholen. Daher läuft jeder Test standardmäßig 20 Mal. Wenn Sie diese Zahl nicht noch höher erhöhen.
Wir messen die React -Komponenten -Render -Zeiten mit Mikrosekundengenauigkeit während der Leistungsmessungen unter Verwendung von React.Profiler . Dies bedeutet, dass der gleiche Code je nach Maschine schneller oder langsamer ausgeführt wird. Aus diesem Grund müssen Basis- und Strommessungen auf derselben Maschine ausgeführt werden. Optimalerweise sollten sie nacheinander geführt werden.
Darüber hinaus muss Ihr CI -Agent eine stabile Leistung haben, um sinnvolle Ergebnisse zu erzielen. Es spielt keine Rolle, ob Ihr Agent schnell oder langsam ist, solange er in seiner Leistung konsistent ist. Aus diesem Grund sollte der Agent während der Leistungstests nicht für andere Arbeiten verwendet werden, die sich auf die Messung der Renderzeiten auswirken könnten.
Um die Stabilität Ihrer Maschine zu bewerten, können Sie den Befehl reassure check-stability verwenden. Für den aktuellen Code werden die Leistungsmessungen zweimal ausgeführt. Daher beziehen sich die Grundlinien- und aktuelle Messungen auf denselben Code. In einem solchen Fall betragen die erwarteten Änderungen 0% (keine Änderung). Der Grad der zufälligen Leistungsänderungen spiegelt die Stabilität Ihrer Maschine wider. Dieser Befehl kann sowohl auf CI- als auch auf lokalen Maschinen ausgeführt werden.
Normalerweise sollten die zufälligen Änderungen unter 5%liegen. Ergebnisse von 10% und mehr werden als zu hoch angesehen, was bedeutet, dass Sie daran arbeiten sollten, die Stabilität Ihrer Maschine zu optimieren.
HINWEIS : Als Trick des letzten Auswegs können Sie die
runvom Standardwert von 10 bis 20, 50 oder sogar 100 für alle oder einige Ihrer Tests erhöhen, basierend auf der Annahme, dass mehr Testläufe sogar Messschwankungen ausführen. Dadurch wird Ihre Tests jedoch noch länger laufen.
Sie können auf unseren Beispiel GitHub Workflow verweisen.
Wenn Sie sich das Beispiel ansehen, können Sie feststellen, dass Testszenarien bestimmten Kategorien zugewiesen werden können:
measureRenders Funktion Benutzerdefinierte Wrapper für die RNTL render , die für die Rendern des übergebenen Bildschirms in einer React.Profiler -Komponente verantwortlich ist, die Leistung messen und Ergebnisse in die Ausgabedatei schreiben. Sie können das optionale options verwenden, das das Anpassen von Aspekten des Tests ermöglicht
async function measureRenders (
ui : React . ReactElement ,
options ?: MeasureRendersOptions ,
) : Promise < MeasureResults > { MeasureRendersOptions Typ interface MeasureRendersOptions {
runs ?: number ;
warmupRuns ?: number ;
wrapper ?: React . ComponentType < { children : ReactElement } > ;
scenario ?: ( view ?: RenderResult ) => Promise < any > ;
writeFile ?: boolean ;
}runs : Anzahl der Läufe pro Serie für den jeweiligen TestwarmupRuns : Anzahl zusätzlicher Aufwärmausläufe, die vor den tatsächlichen Läufen durchgeführt und verworfen werden (Standard 1).wrapper : Reagieren Sie die Komponente wie ein Provider , mit dem die ui verpackt wird. Hinweis: Die Renderdauer der wrapper selbst ist von den Ergebnissen ausgeschlossen; Nur die verpackte Komponente wird gemessen.scenario : Eine benutzerdefinierte asynchronisierende Funktion, die die Benutzerinteraktion innerhalb der Benutzeroberfläche durch Verwendung von RNTL- oder RTL -Funktionen definiertwriteFile : (Standard true ) sollte Ausgabe in Datei schreiben. measureFunction Funktion Ermöglicht die Synchronfunktion, messen Sie die Ausführungszeiten und schreiben Sie Ergebnisse in die Ausgabedatei. Sie können optionale options verwenden, um Aspekte der Tests anzupassen. Hinweis: Die Ausführungszahl wird immer einer sein.
async function measureFunction (
fn : ( ) => void ,
options ?: MeasureFunctionOptions
) : Promise < MeasureResults > { MeasureFunctionOptions Typ interface MeasureFunctionOptions {
runs ?: number ;
warmupRuns ?: number ;
}runs : Anzahl der Läufe pro Serie für den jeweiligen TestwarmupRuns : Anzahl zusätzlicher Aufwärmausläufe, die vor den tatsächlichen Läufen durchgeführt und verworfen werden. Die Standardkonfiguration, die vom Messskript verwendet wird. Dieses Konfigurationsobjekt kann unter Verwendung der configure überschrieben werden.
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 : Die Anzahl der wiederholten Läufe in einer Serie pro Test (ermöglicht eine höhere Genauigkeit, indem mehr Daten zusammengefasst werden). Sollte mit Sorgfalt behandelt werden.
warmupRuns : Die Anzahl der zusätzlichen Aufwärmausfälle, die vor den tatsächlichen Läufen durchgeführt und verworfen werden. outputFile : 'react-native' Name der Datei Die Datensätze werden auf verbose gespeichert 'react' Beruhigen render cleanup mehr, testingLibrary . render und cleanup configure function configure ( customConfig : Partial < Config > ) : void ; Die configure kann die Standardkonfigurationsparameter überschreiben.
resetToDefaults -Funktion resetToDefaults ( ) : void Setzen Sie die aktuelle Konfiguration auf das ursprüngliche defaultConfig -Objekt zurück
Sie können verfügbare Umgebungsvariablen verwenden, um Ihre Testläufereinstellungen zu ändern.
TEST_RUNNER_PATH : ein alternativer Pfad für Ihren Testläufer. Standardeinstellungen zu 'node_modules/.bin/jest' oder unter Windows 'node_modules/jest/bin/jest'TEST_RUNNER_ARGS : Eine Reihe von Argumenten, die dem Läufer gespeist werden. Standardeinstellungen zu '--runInBand --testMatch "**/__perf__/**/*.[jt]s?(x)", "**/*.(perf|perf-test).[jt]s?(x)"'Beispiel:
TEST_RUNNER_PATH=myOwnPath/jest/bin yarn reassureWeitere Informationen finden Sie im beitragenden Leitfaden, um zu erfahren, wie Sie zum Repository und den Entwicklungsworkflow beitragen.
MIT
Beruhigung ist ein Open -Source -Projekt und bleibt immer frei zu verwenden. Das Projekt wurde in enger Partnerschaft mit Entain entwickelt und war ursprünglich ihr internes Projekt. Dank ihrer Bereitschaft, das React & React Native -Ökosystem zu entwickeln, haben wir beschlossen, es Open Source zu machen. Wenn Sie denken, dass es cool ist, spiele es bitte mit?
CallStack ist eine Gruppe von React- und React -Experten. Wenn Sie Hilfe bei diesen benötigen oder Hallo sagen möchten, kontaktieren Sie uns unter [email protected]!
Wie das Projekt? ⚛️ Treten Sie dem CallStack -Team bei, das tolle Sachen für Kunden macht und reagiert native Open Source!
