الصفحة الرئيسية>المتعلقة بالبرمجة>شفرة المصدر الأخرى
تنزيل

طمأنة

رفيق اختبار الأداء للتفاعل وتفاعل الأصلي.

callstack x entain

اقرأ المستندات

  • المشكلة
  • هذا الحل
  • التثبيت والإعداد
    • كتابة اختبارك الأول
      • كتابة اختبارات ASYNC
    • قياس أداء الاختبار
    • اكتب نص اختبار الأداء
  • إعداد CI
    • السقالات
      • سيناريو CI ( reassure-tests.sh )
      • Dangerfile
      • .gitignore
    • سيناريو CI ( reassure-tests.sh )
    • اندماج
      • تحديث DangerFile الحالي
      • خلق dangerfile
      • تحديث ملف تكوين CI
  • تقييم استقرار CI
  • تحليل النتائج
  • API
    • القياسات
      • وظيفة measureRenders
      • نوع MeasureRendersOptions نوع
      • دالة measureFunction
      • نوع MeasureFunctionOptions
    • إعدادات
      • التكوين الافتراضي
      • configure الوظيفة
      • وظيفة resetToDefaults
      • المتغيرات البيئية
  • المراجع الخارجية
  • المساهمة
  • رخصة
  • صنع مع ❤ في callstack

المشكلة

تريد أن يؤدي تطبيق React Native الخاص بك بشكل جيد وسريع في جميع الأوقات. كجزء من هذا الهدف ، يمكنك ملف تعريف التطبيق ، ومراقبة أنماط التقديم ، وتطبيق المذكرات في الأماكن الصحيحة ، وما إلى ذلك ، ولكن كل شيء يدويًا وسهلاً للغاية على تقديم انحدارات الأداء التي ستنشغل بها فقط خلال QA أو أسوأ من قبل المستخدمين .

هذا الحل

يتيح لك الطمأنينة أتمتة اختبار انحدار أداء التطبيق الأصلي على CI أو آلة محلية. بالطريقة نفسها ، تكتب اختبارات التكامل والوحدة التي تتحقق تلقائيًا من أن تطبيقك لا يزال يعمل بشكل صحيح ، يمكنك كتابة اختبارات الأداء التي تتحقق من أن تطبيقك لا يزال يعمل بشكل أداء .

يمكنك التفكير في الأمر كمكتبة اختبار أداء رد الفعل. في الواقع ، تم تصميم الطمأنينة لإعادة استخدام أكبر قدر ممكن من اختبارات مكتبة React Native و Ettening.

يعمل طمأنة الأعمال عن طريق قياس خصائص تقديم - مدة وعد - لسيناريو الاختبار الذي تقدمه ومقارنته بالنسخة المستقرة. يكرر السيناريو عدة مرات لتقليل تأثير الاختلافات العشوائية في أوقات العرض الناجمة عن بيئة وقت التشغيل. ثم ، ينطبق التحليل الإحصائي لتحديد ما إذا كانت تغييرات الكود ذات دلالة إحصائية. نتيجة لذلك ، فإنه يولد تقريرًا قابل للقراءة الإنسان يلخص النتائج ويعرضه على CI أو كتعليق على طلب السحب الخاص بك.

بالإضافة إلى قياس أوقات عرض المكون ، يمكن أيضًا قياس تنفيذ وظائف JavaScript العادية.

التثبيت والإعداد

لتثبيت الطمأنينة ، قم بتشغيل الأمر التالي في مجلد التطبيق الخاص بك:

باستخدام الغزل 

yarn add --dev reassure

باستخدام NPM 

npm install --save-dev reassure

ستحتاج أيضًا إلى إعداد مزاح يعمل بالإضافة إلى أحد مكتبة React Native Testing أو مكتبة اختبار رد الفعل.

انظر دليل التثبيت.

يمكنك التحقق من مشاريع مثالنا:

  • React Native (Expo)
  • رد فعل مواطن (CLI)
  • React.js (next.js)
  • React.js (Vite)

سوف تحاول الطمأنينة اكتشاف مكتبة الاختبار التي قمت بتثبيتها. إذا كان كل من مكتبة الاختبار الأصلي ومكتبة اختبار رد الفعل موجودين ، فسوف يحذرك من ذلك ويمنح الأسبقية رد فعل مكتبة الاختبار الأصلي. يمكنك تحديد مكتبة الاختبار بشكل صريح لاستخدامها باستخدام خيار 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 أثناء التركيب وتأثيرات المزامنة الناتجة.

ملاحظة : سوف تتطابق طمأنتها تلقائيًا مع أسماء الملفات باستخدام خيار Jest --testMatch مع القيمة "**/__perf__/**/*.[jt]s?(x)", "**/*.(perf|perf-test).[jt]s?(x)" . ومع ذلك ، إذا كنت ترغب في تمرير خيار مخصص --testMatch أو --testRegex ، فيمكنك إضافته إلى البرنامج النصي reassure measure لتمرير الكرة الأرضية الخاصة بك. المزيد عن --testMatch و --testRegex في Docs Jest

كتابة اختبارات ASYNC

إذا كان المكون الخاص بك يحتوي على أي منطق 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 طرق مكتبة الاختبار المحلية المألوفة.

في حالة استخدام إصدار من مكتبة React Native Testing أقل من V10.1.0 ، حيث لا يتوفر مساعد 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 });
} ) ;

إذا كان الاختبار الخاص بك يحتوي على أي تغييرات غير متزامنة ، فستحتاج إلى التأكد من أن السيناريو ينتظر هذه التغييرات لتستقر ، على سبيل المثال باستخدام استفسارات findBy أو waitFor أو waitForElementToBeRemoved من RNTL.

قياس أداء الاختبار

لقياس أداء الاختبار الأول ، تحتاج إلى تشغيل الأمر التالي في المحطة: 

yarn reassure

سيقوم هذا الأمر بتشغيل الاختبارات الخاصة بك عدة مرات باستخدام Jest ، وجمع إحصائيات الأداء وسيقوم بكتابتها إلى ملف .reassure/current.perf . للتحقق من الإعداد الخاص بك ، تحقق مما إذا كان ملف الإخراج موجودًا بعد تشغيل الأمر لأول مرة.

ملاحظة: يمكنك إضافة .reassure/ Folder إلى ملف .gitignore الخاص بك لتجنب ارتكاب نتائجك عن طريق الخطأ.

سيحاول طمأن CLI تلقائيًا اكتشاف اسم فرع الكود الخاص بك وارتكاب التجزئة عند استخدام GIT. يمكنك تجاوز هذه الخيارات ، على سبيل المثال ، إذا كنت تستخدم نظام التحكم في الإصدار مختلف: 

yarn reassure --branch [branch name] --commit-hash [commit hash]

اكتب نص اختبار الأداء

للكشف عن تغييرات الأداء ، يجب عليك قياس أداء نسختين من الكود الحالي (الرمز المعدل) وخط الأساس (نقطة المرجع ، على سبيل المثال الفرع main ). لقياس الأداء في فرعين ، يجب عليك تبديل الفروع في GIT أو استنساخ نسختين من مستودعك.

نريد أتمتة هذه المهمة لتشغيلها على 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 وجميع المتطلبات المسبقة أكثر ملاءمة ، قمنا بإعداد أمر CLI لإنشاء جميع القوالب اللازمة لتبدأ بها.

ببساطة الجري: 

yarn reassure init

سيؤدي هذا إلى إنشاء بنية الملف التالية 

 ├── <ROOT>
│   ├── reassure-tests.sh
│   ├── dangerfile.ts/js (or dangerfile.reassure.ts/js if dangerfile.ts/js already present)
│   └── .gitignore

السقالات

سيناريو CI ( reassure-tests.sh )

البرنامج النصي الأساسي يسمح لك بتشغيل الطمأنينة على CI. المزيد عن أهمية وهيكل هذا الملف في القسم التالي.

Dangerfile

إذا كان مشروعك يحتوي بالفعل على dangerfile.ts/js ، فلن يتجاوزه CLI بأي شكل من الأشكال. بدلاً من ذلك ، سيؤدي ذلك إلى إنشاء ملف dangerfile.reassure.ts/js ، مما يتيح لك مقارنة وتحديث راحتك.

.gitignore

إذا كان ملف .gitignore موجودًا ولم يظهر أي إشارة إلى reassure ، فسوف يقوم البرنامج النصي بإلحاق .reassure/ Directory حتى نهايته.

سيناريو CI ( reassure-tests.sh )

للكشف عن تغييرات الأداء ، يجب عليك قياس أداء نسختين من الكود الحالي (الرمز المعدل) وخط الأساس (نقطة المرجع ، على سبيل المثال الفرع main ). لقياس الأداء في فرعين ، يجب عليك تبديل الفروع في GIT أو استنساخ نسختين من مستودعك.

نريد أتمتة هذه المهمة لتشغيلها على 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 لتشغيل البرنامج النصي اختبار الأداء وإخراج النتيجة. لتقديم الإخراج في الوقت الحالي ، ندمج مع Danger JS ، الذي يدعم جميع أدوات CI الرئيسية.

تحديث DangerFile الحالي

ستحتاج إلى خطر عمل JS.

ثم أضف البرنامج المساعد لخطر js إلى 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' ) ,
} ) ;

خلق dangerfile

إذا لم يكن لديك dangerfile ( dangerfile.js أو dangerfile.ts ) حتى الآن ، يمكنك استخدام النصي الذي تم إنشاؤه بواسطة برنامج reassure init دون إجراء أي تغييرات إضافية.

إنه أيضًا في مثال ملف DangerFile.

تحديث ملف تكوين CI

أخيرًا ، قم بتشغيل كل من برنامج اختبار الأداء والخطر في تكوين 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) وكرر ذلك لفرعين من الكود الخاص بك. وبالتالي ، سيتم تشغيل كل اختبار 20 مرة بشكل افتراضي. هذا ما لم تزيد من هذا الرقم أعلى.

تقييم استقرار CI

نقوم بقياس أوقات عرض مكونات React مع دقة microsecond أثناء قياسات الأداء باستخدام React.Profiler . هذا يعني أن نفس الرمز سيعمل بشكل أسرع أو أبطأ ، اعتمادًا على الجهاز. لهذا السبب ، يجب تشغيل القياسات الأساسية والحالية على نفس الجهاز. على النحو الأمثل ، يجب أن يتم تشغيل واحد تلو الآخر.

علاوة على ذلك ، يحتاج وكيل CI الخاص بك إلى الحصول على أداء مستقر لتحقيق نتائج ذات مغزى. لا يهم ما إذا كان وكيلك سريعًا أو بطيئًا طالما كان ثابتًا في أدائه. لهذا السبب لا ينبغي استخدام الوكيل أثناء اختبارات الأداء لأي عمل آخر قد يؤثر على أوقات التقديم.

لمساعدتك في تقييم استقرار جهازك ، يمكنك استخدام أمر reassure check-stability . يقوم بتشغيل قياسات الأداء مرتين للرمز الحالي ، لذلك تشير القياسات الأساسية والحالية إلى نفس الرمز. في مثل هذه الحالة ، تكون التغييرات المتوقعة 0 ٪ (بدون تغيير). ستعكس درجة تغيير الأداء العشوائي استقرار جهازك. يمكن تشغيل هذا الأمر على CI والآلات المحلية.

عادة ، يجب أن تكون التغييرات العشوائية أقل من 5 ٪. تعتبر نتائج 10 ٪ وأكثر من ذلك مرتفعة للغاية ، مما يعني أنه يجب عليك العمل على تغيير استقرار جهازك.

ملاحظة : كخدعة في الملاذ الأخير ، يمكنك زيادة خيار run من القيمة الافتراضية من 10 إلى 20 أو 50 أو حتى 100 لجميع أو بعض الاختبارات الخاصة بك ، بناءً على افتراض أن المزيد من الاختبارات ستخرج من تقلبات القياس. ومع ذلك ، فإن هذا سيجعل اختباراتك تعمل لفترة أطول.

يمكنك الرجوع إلى مثالنا على سير عمل GitHub.

تحليل النتائج

تقرير تخفيض

بالنظر إلى المثال ، يمكنك ملاحظة أنه يمكن تعيين سيناريوهات الاختبار لفئات معينة:

  • تُظهر التغييرات المهمة في المدة سيناريوهات الاختبار حيث يكون تغيير الأداء ذو ​​دلالة إحصائية ويجب النظر فيه لأنه يمثل فقدان/تحسينًا محتملًا للأداء
  • تُظهر التغييرات التي لا معنى لها في المدة سيناريوهات الاختبار حيث لا يكون تغيير الأداء ذو ​​دلالة إحصائية
  • تظهر التغييرات في العد سيناريوهات الاختبار حيث تغير عدد العرض أو التنفيذ
  • تعرض السيناريوهات المضافة سيناريوهات الاختبار التي لا توجد في قياسات خط الأساس
  • تعرض السيناريوهات التي تمت إزالتها سيناريوهات الاختبار التي لا توجد في القياسات الحالية

API

القياسات

وظيفة measureRenders

غلاف مخصص لوظيفة render RNTL مسؤولة عن تقديم الشاشة التي تم تمريرها داخل مكون 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 : مكون React ، مثل Provider ، والتي سيتم لفها ui . ملحوظة: يتم استبعاد مدة العرض من wrapper نفسه من النتائج ؛ يتم قياس المكون ملفوف فقط.
  • scenario : وظيفة ASYNC مخصصة ، والتي تحدد تفاعل المستخدم داخل واجهة المستخدم عن طريق استخدام وظائف RNTL أو RTL
  • writeFile : ( true الافتراضي) يجب أن تكتب الإخراج إلى الملف.

دالة measureFunction

يتيح لك لف أي وظيفة متزامنة ، وقياس أوقات التنفيذ الخاصة بها وكتابة النتائج إلى ملف الإخراج. يمكنك استخدام options اختيارية لتخصيص جوانب الاختبار. ملاحظة: سيكون عدد التنفيذ دائمًا واحدًا. 

 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 : اجعل سجل الطمأنينة أكثر ، على سبيل المثال لأغراض تصحيح الأخطاء testingLibrary : أين تبحث عن وظائف render cleanup ، والقيم المدعومة 'react-native' أو 'react' أو كائن توفير العرف وظائف 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

المراجع الخارجية

  • الدليل النهائي لرد التحسين الأصلي 2024 طبعة - المذكورة في الفصل "اجعل تطبيقك بسرعة ثابتة".

المساهمة

راجع دليل المساهمة لتعلم كيفية المساهمة في المستودع وسير العمل التنموي.

رخصة

معهد ماساتشوستس للتكنولوجيا

صنع مع ❤ في callstack

الطمأنينة هو مشروع مفتوح المصدر وسيظل دائمًا مجانيًا في الاستخدام. تم تطوير المشروع في شراكة وثيقة مع Entain وكان في الأصل مشروعهم الداخلي. بفضل استعدادهم لتطوير نظام React & React الأصلي ، قررنا أن نجعله مفتوحًا. إذا كنت تعتقد أنه رائع ، فالرجاء نجمة ذلك؟

Callstack هي مجموعة من الخبراء الأصليين React and React. إذا كنت بحاجة إلى مساعدة في هذه أو تريد أن تقول مرحبًا ، اتصل بنا على [email protected]!

مثل المشروع؟ ⚛ انضم إلى فريق Callstack الذي يقوم بأشياء مذهلة للعملاء ومحركات React Open Source!

يوسع
معلومات إضافية
تطبيقات ذات صلة
نوصي لك
أخبار ذات صلة الكل