reassure
v1.3.0
Performance Testing Companion pour React et React Native.
Lisez les documents
reassure-tests.sh ).gitignorereassure-tests.sh )measureRendersMeasureRendersOptionsmeasureFunctionMeasureFunctionOptionsconfigure la fonctionresetToDefaultsVous voulez que votre application native React fonctionne bien et rapidement à tout moment. Dans le cadre de cet objectif, vous profilez l'application, observez les modèles de rendu, appliquez la mémorisation aux bons endroits, etc. Mais tout est manuel et trop facile d'introduire involontairement des régressions de performance qui ne seraient prises que pendant l'AQ ou pire, par vos utilisateurs, par vos utilisateurs .
Rassurer vous permet d'automatiser les tests de régression des performances de l'application Native React sur CI ou une machine locale. De la même manière, vous rédigez vos tests d'intégration et d'unité qui vérifient automatiquement que votre application fonctionne toujours correctement , vous pouvez rédiger des tests de performances qui vérifient que votre application fonctionne toujours avec activité .
Vous pouvez y penser comme une bibliothèque de tests de performances React. En fait, Rassure est conçu pour réutiliser autant que possible de vos tests de bibliothèque de tests natifs React.
Rassurez les travaux en mesurant les caractéristiques de rendu - durée et du nombre - du scénario de test que vous fournissez et en comparant cela à la version stable. Il répète le scénario plusieurs fois pour réduire l'impact des variations aléatoires des temps de rendu causés par l'environnement d'exécution. Ensuite, il applique une analyse statistique pour déterminer si les changements de code sont statistiquement significatifs. En conséquence, il génère un rapport lisible par l'homme résumant les résultats et l'affiche sur le CI ou comme commentaire à votre demande de traction.
En plus de mesurer les temps de rendu des composants, il peut également mesurer l'exécution des fonctions JavaScript ordinaires.
Pour installer Rassure, exécutez la commande suivante dans le dossier de votre application:
Utilisation du fil
yarn add --dev reassureUtilisation de NPM
npm install --save-dev reassureVous aurez également besoin d'une configuration de plaisanterie de travail ainsi que de l'une des bibliothèques de tests natives React ou de la bibliothèque de tests React.
Voir Guide d'installation.
Vous pouvez vérifier nos exemples de projets:
Rassurera essaiera de détecter la bibliothèque de tests que vous avez installée. Si la bibliothèque de tests natives React et la bibliothèque de tests React sont présentes, cela vous en avertira et donnera la priorité à la bibliothèque de tests natifs. Vous pouvez explicitement spécifier la bibliothèque de tests à utiliser en utilisant l'option configure :
configure ( { testingLibrary : 'react-native' } ) ;
// or
configure ( { testingLibrary : 'react' } ) ;Vous devez le définir dans votre fichier de configuration de plaisanterie et vous pouvez le remplacer dans des fichiers de test particuliers si nécessaire.
Maintenant que la bibliothèque est installée, vous pouvez écrire votre premier scénario de test dans un fichier avec .perf-test.js / .perf-test.tsx Extension:
// ComponentUnderTest.perf-test.tsx
import { measureRenders } from 'reassure' ;
import { ComponentUnderTest } from './ComponentUnderTest' ;
test ( 'Simple test' , async ( ) => {
await measureRenders ( < ComponentUnderTest / >);
} ) ; Ce test mesurera les temps de rendu de ComponentUnderTest pendant le montage et les effets de synchronisation qui en résultent.
Remarque : Rassurera correspondra automatiquement aux noms de fichiers de test à l'aide de l'option
--testMatchde Jest avec valeur"**/__perf__/**/*.[jt]s?(x)", "**/*.(perf|perf-test).[jt]s?(x)". Cependant, si vous souhaitez passer une option personnalisée--testMatchou--testRegex, vous pouvez l'ajouter au scriptreassure measurepour passer votre propre globe. En savoir plus sur--testMatchet--testRegexdans JEST DOCS
Si votre composant contient une logique asynchrone ou si vous souhaitez tester une interaction, vous devez passer l'option 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 });
} ) ; Le corps de la fonction scenario utilise des méthodes familières de bibliothèque de tests natives React.
En cas d'utilisation d'une version de la bibliothèque de tests natives React inférieure à V10.1.0, où screen Helper n'est pas disponible, la fonction scenario le fournit comme son premier 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 });
} ) ; Si votre test contient des modifications asynchrones, vous devrez vous assurer que le scénario attend ces modifications à régler, par exemple, en utilisant des requêtes findBy , des fonctions waitFor ou waitForElementToBeRemoved les fonctions de RNTL.
Pour mesurer vos premières performances de test, vous devez exécuter la commande suivante dans le terminal:
yarn reassure Cette commande exécutera vos tests plusieurs fois à l'aide de la plaisanterie, de la collecte de statistiques de performance et les écrira dans le fichier .reassure/current.perf . Pour vérifier votre configuration, vérifiez si le fichier de sortie existe après l'exécution de la commande pour la première fois.
Remarque: vous pouvez ajouter
.reassure/dossier à votre fichier.gitignorepour éviter de commettre accidentellement vos résultats.
Rassure que CLI essaiera automatiquement de détecter le nom de la branche de votre code source et de commettre un hachage lorsque vous utilisez GIT. Vous pouvez remplacer ces options, par exemple si vous utilisez un système de contrôle de version différent:
yarn reassure --branch [branch name] --commit-hash [commit hash] Pour détecter les modifications de performances, vous devez mesurer les performances de deux versions de votre code de code (votre code modifié) et de la ligne de base (votre point de référence, par exemple la branche main ). Pour mesurer les performances sur deux branches, vous devez changer de branches en git ou clone deux copies de votre référentiel.
Nous voulons automatiser cette tâche pour s'exécuter sur l'IC. Pour ce faire, vous devrez créer un script de test de performances. Vous devez l'enregistrer dans votre référentiel, par exemple en tant que reassure-tests.sh .
Une version simple d'un tel script, en utilisant une approche qui change de branche, est la suivante:
#! /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 reassurePour rendre la configuration de l'intégration CI et toutes les conditions préalables plus pratiques, nous avons préparé une commande CLI pour générer tous les modèles nécessaires pour que vous puissiez commencer.
Courez simplement:
yarn reassure initCela générera la structure de fichiers suivante
├── <ROOT>
│ ├── reassure-tests.sh
│ ├── dangerfile.ts/js (or dangerfile.reassure.ts/js if dangerfile.ts/js already present)
│ └── .gitignore
reassure-tests.sh )Script de base vous permettant de rassurer CI. En savoir plus sur l'importance et la structure de ce fichier dans la section suivante.
Si votre projet contient déjà un dangerfile.ts/js , la CLI ne la remplacera en aucune façon. Au lieu de cela, il générera un fichier dangerfile.reassure.ts/js , vous permettant de comparer et de mettre à jour le vôtre à votre convenance.
.gitignore Si le fichier .gitignore est présent et qu'aucune mention de reassure n'apparaît, le script ajoutera le .reassure/ répertoire jusqu'à sa fin.
reassure-tests.sh ) Pour détecter les modifications de performances, vous devez mesurer les performances de deux versions de votre code de code (votre code modifié) et de la ligne de base (votre point de référence, par exemple la branche main ). Pour mesurer les performances sur deux branches, vous devez changer de branches en git ou clone deux copies de votre référentiel.
Nous voulons automatiser cette tâche pour s'exécuter sur l'IC. Pour ce faire, vous devrez créer un script de test de performances. Vous devez l'enregistrer dans votre référentiel, par exemple en tant que reassure-tests.sh .
Une version simple d'un tel script, en utilisant une approche qui change de branche, est la suivante:
#! /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 reassureEn tant qu'étape de configuration finale, vous devez configurer votre CI pour exécuter le script de test de performances et sortir le résultat. Pour présenter la sortie pour le moment, nous nous intégrons à Danger JS, qui prend en charge tous les principaux outils CI.
Vous aurez besoin d'une configuration de danger JS fonctionnelle.
Ajoutez ensuite Rassurez le plugin danger JS à votre dangerfile:
// /<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' ) ,
} ) ; Si vous n'avez pas de dangerfile ( dangerfile.js ou dangerfile.ts ), vous pouvez utiliser celui généré par le script reassure init sans apporter de modifications supplémentaires.
Il est également dans notre exemple de fichier dangerfile.
Enfin, exécutez à la fois le script de test de performances et le danger dans votre configuration CI:
- name : Run performance testing script
run : ./reassure-tests.sh
- name : Run Danger.js
run : yarn danger ci
env :
GITHUB_TOKEN : ${{ secrets.GITHUB_TOKEN }}Vous pouvez également vérifier notre exemple de workflow GitHub.
L'exemple ci-dessus est basé sur les actions GitHub, mais il doit être similaire à d'autres fichiers CI Config et ne doit servir que de référence dans de tels cas.
Remarque : Votre test de performance fonctionnera beaucoup plus longtemps que les tests d'intégration réguliers. C'est parce que nous exécutons chaque scénario de test plusieurs fois (par défaut, 10) et nous le faisons pour deux branches de votre code. Par conséquent, chaque test fonctionnera 20 fois par défaut. C'est à moins que vous n'augmentez ce nombre encore plus élevé.
Nous mesurons les temps de rendement des composants React avec une précision de microseconde lors des mesures de performance en utilisant React.Profiler . Cela signifie que le même code s'exécutera plus rapidement ou plus lent, selon la machine. Pour cette raison, les mesures de référence et de courant doivent être exécutées sur la même machine. De manière optimale, ils devraient être exécutés les uns après les autres.
De plus, votre agent CI doit avoir des performances stables pour obtenir des résultats significatifs. Peu importe si votre agent est rapide ou lent tant qu'il est cohérent dans ses performances. C'est pourquoi l'agent ne doit pas être utilisé lors des tests de performance pour tout autre travail qui pourrait avoir un impact sur la mesure des temps de rendu.
Pour vous aider à évaluer la stabilité de votre machine, vous pouvez utiliser la commande reassure check-stability . Il exécute les mesures de performances deux fois pour le code actuel, de sorte que les mesures de référence et actuelles se réfèrent au même code. Dans un tel cas, les changements attendus sont de 0% (pas de changement). Le degré de changements de performances aléatoires reflétera la stabilité de votre machine. Cette commande peut être exécutée à la fois sur les machines CI et locales.
Normalement, les changements aléatoires doivent être inférieurs à 5%. Les résultats de 10% et plus sont considérés comme trop élevés, ce qui signifie que vous devriez travailler à peaufiner la stabilité de votre machine.
Remarque : En dernier recours, vous pouvez augmenter l'option
runà partir de la valeur par défaut de 10 à 20, 50 ou même 100 pour tous ou certains de vos tests, en fonction de l'hypothèse que plus de tests de test seront même des fluctuations de mesure. Cela permettra cependant à vos tests de fonctionner encore plus longtemps.
Vous pouvez vous référer à notre exemple de workflow GitHub.
En regardant l'exemple, vous pouvez remarquer que les scénarios de test peuvent être attribués à certaines catégories:
measureRenders L'écran personnalisé pour la fonction RNTL render responsable du rendu de l'écran passé dans un composant React.Profiler , mesurant ses performances et ses résultats d'écriture dans le fichier de sortie. Vous pouvez utiliser l'objet options optionnels qui permet de personnaliser les aspects des tests
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 : Nombre de courses par série pour le test particulierwarmupRuns : Nombre d'exécutions d'échauffement supplémentaires qui seront effectuées et jetées avant les exécutions réelles (par défaut 1).wrapper : React Component, comme un Provider , dont l' ui sera enveloppée. Remarque: La durée de rendu de l' wrapper lui-même est exclue des résultats; Seul le composant enveloppé est mesuré.scenario : une fonction asynchrone personnalisée, qui définit l'interaction utilisateur dans l'interface utilisateur en utilisant des fonctions RNTL ou RTLwriteFile : (par défaut true ) devrait écrire la sortie en fichier. measureFunction Vous permet d'envelopper n'importe quelle fonction synchrone, de mesurer ses temps d'exécution et d'écrire des résultats dans le fichier de sortie. Vous pouvez utiliser options facultatives pour personnaliser les aspects des tests. Remarque: le nombre d'exécution sera toujours un.
async function measureFunction (
fn : ( ) => void ,
options ?: MeasureFunctionOptions
) : Promise < MeasureResults > { MeasureFunctionOptions interface MeasureFunctionOptions {
runs ?: number ;
warmupRuns ?: number ;
}runs : Nombre de courses par série pour le test particulierwarmupRuns : Nombre de parcours d'échauffement supplémentaires qui seront effectués et jetés avant les courses réelles. La configuration par défaut qui sera utilisée par le script de mesure. Cet objet de configuration peut être remplacé avec l'utilisation de la fonction 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 : le nombre d'exécutions répétées dans une série par test (permet une précision plus élevée en agrégeant plus de données). Devrait être manipulé avec soin.
warmupRuns : le nombre de réchauffites supplémentaires qui seront effectués et jetés avant les courses réelles. outputFile : le nom du fichier Les enregistrements seront enregistrés sur verbose : Rassurez le journal davantage, par exemple à des fins de débogage testingLibrary : où chercher des fonctions render et cleanup , des valeurs prises en charge 'react-native' , 'react' render et cleanup des fonctions configure la fonction function configure ( customConfig : Partial < Config > ) : void ; La fonction configure peut remplacer les paramètres de configuration par défaut.
resetToDefaults resetToDefaults ( ) : void Réinitialisez la configuration actuelle à l'objet defaultConfig d'origine
Vous pouvez utiliser des variables environnementales disponibles pour modifier les paramètres de vos coureurs de test.
TEST_RUNNER_PATH : un chemin alternatif pour votre coureur de test. Par défaut est 'node_modules/.bin/jest' ou sur Windows 'node_modules/jest/bin/jest'TEST_RUNNER_ARGS : un ensemble d'arguments alimentés au coureur. Par défaut à '--runInBand --testMatch "**/__perf__/**/*.[jt]s?(x)", "**/*.(perf|perf-test).[jt]s?(x)"'Exemple:
TEST_RUNNER_PATH=myOwnPath/jest/bin yarn reassureVoir le guide contribuant pour apprendre à contribuer au référentiel et au flux de travail de développement.
Mit
Rassure est un projet open source et restera toujours libre à utiliser. Le projet a été développé en partenariat étroit avec ENTAIN et était à l'origine leur projet interne. Grâce à leur volonté de développer l'écosystème indigène React & React, nous avons décidé de le rendre open source. Si vous pensez que c'est cool, veuillez le jouer?
CallStack est un groupe d'experts indigènes React et React. Si vous avez besoin d'aide pour ceux-ci ou si vous souhaitez dire bonjour, contactez-nous à [email protected]!
Vous aimez le projet? ⚛️ Rejoignez l'équipe CallStack qui fait des choses incroyables pour les clients et entraîne React Open Source native!
