From 831111ddbb0b9657390a46bca8106c13e8d9696b Mon Sep 17 00:00:00 2001 From: Mohamed Abdel Nasser Date: Fri, 8 Nov 2019 23:25:03 +0200 Subject: [PATCH 1/5] translate first section of Testing Recipes --- content/docs/testing-recipes.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/content/docs/testing-recipes.md b/content/docs/testing-recipes.md index dd7efa5b4..58b7850d0 100644 --- a/content/docs/testing-recipes.md +++ b/content/docs/testing-recipes.md @@ -1,18 +1,21 @@ --- id: testing-recipes -title: Testing Recipes +title: طريقة اعداد الاختبارات permalink: docs/testing-recipes.html prev: testing.html next: testing-environments.html --- -Common testing patterns for React components. +أنماط الاختبار الشائعه لمكونات مكتبة React -> Note: +> ملحوظه: > -> This page assumes you're using [Jest](https://jestjs.io/) as a test runner. If you use a different test runner, you may need to adjust the API, but the overall shape of the solution will likely be the same. Read more details on setting up a testing environment on the [Testing Environments](/docs/testing-environments.html) page. +> تفترض هذه الصفحة أنك تستخدم [Jest](https://jestjs.io/) كمرشح للاختبار. إذا كنت تستخدم عداء اختبار مختلفًا ، فقد تحتاج إلى ضبط واجهة برمجة التطبيقات ، ولكن من المحتمل أن يكون الشكل العام للحل هو نفسه. اقرأ المزيد من التفاصيل حول إعداد بيئة اختبار على صفحة اختبار البيئات.[Testing Environments](/docs/testing-environments.html) + + + +في هذه الصفحة ، سوف نستخدم (functional components) بشكل أساسي. ومع ذلك ، لا تعتمد استراتيجيات الاختبار هذه على تفاصيل التنفيذ ، كما تعمل أيضًا مع (class components). -On this page, we will primarily use function components. However, these testing strategies don't depend on implementation details, and work just as well for class components too. - [Setup/Teardown](#setup--teardown) - [`act()`](#act) From 91340013c6c17dca94c5ed10c6c0fc1d5bd7708c Mon Sep 17 00:00:00 2001 From: Mohamed Abdel Nasser Date: Sun, 10 Nov 2019 02:09:31 +0200 Subject: [PATCH 2/5] finish testing-recipes translate --- content/docs/testing-recipes.md | 80 +++++++++++++++++---------------- 1 file changed, 41 insertions(+), 39 deletions(-) diff --git a/content/docs/testing-recipes.md b/content/docs/testing-recipes.md index 58b7850d0..b9a112a12 100644 --- a/content/docs/testing-recipes.md +++ b/content/docs/testing-recipes.md @@ -1,6 +1,6 @@ --- id: testing-recipes -title: طريقة اعداد الاختبارات +title: طريقة اجراء الاختبارات permalink: docs/testing-recipes.html prev: testing.html next: testing-environments.html @@ -30,11 +30,11 @@ next: testing-environments.html --- -### Setup/Teardown {#setup--teardown} +### (ٍSetup) طريقة الاعداد {#setup--teardown} -For each test, we usually want to render our React tree to a DOM element that's attached to `document`. This is important so that it can receive DOM events. When the test ends, we want to "clean up" and unmount the tree from the `document`. +لكل اختبار نقوم باعادة تقديم React tree الى عنصر DOM المرفق ب `document`. وهذا مهم حتى نتمكن من استقبال DOM events. وعندما ينتهى الاختبار نريد ازاله ال tree من `document`. -A common way to do it is to use a pair of `beforeEach` and `afterEach` blocks so that they'll always run and isolate the effects of a test to itself: +هناك طريقة شائعة للقيام بذلك هي استخدام زوج من `beforeEach` و `afterEach` بحيث يتم تشغيلهما دائمًا وعزل آثار الاختبار عن نفسه: ```jsx import { unmountComponentAtNode } from "react-dom"; @@ -54,13 +54,13 @@ afterEach(() => { }); ``` -You may use a different pattern, but keep in mind that we want to execute the cleanup _even if a test fails_. Otherwise, tests can become "leaky", and one test can change the behavior of another test. That makes them difficult to debug. +يمكنك استخدام نمط مختلف ، ولكن ضع في اعتبارك أننا نرغب في تنفيذ عملية التنظيف - حتى إذا فشل الاختبار -. خلاف ذلك ، يمكن أن تصبح الاختبارات "leaky" ، ويمكن أن يؤدي أحد الاختبارات إلى تغيير سلوك اختبار آخر. هذا يجعلها صعبة التصحيح. --- ### `act()` {#act} -When writing UI tests, tasks like rendering, user events, or data fetching can be considered as "units" of interaction with a user interface. React provides a helper called `act()` that makes sure all updates related to these "units" have been processed and applied to the DOM before you make any assertions: +عند كتابة اختبارات واجهة المستخدم ، يمكن اعتبار المهام مثل التقديم أو أحداث المستخدم أو جلب البيانات "وحدات" للتفاعل مع واجهة المستخدم. توفر React مساعدًا يسمى `act ()` يتأكد من أن جميع التحديثات المتعلقة بهذه "الوحدات" قد تمت معالجتها وتطبيقها على DOM قبل تقديم أي تأكيدات: ```js act(() => { @@ -69,19 +69,19 @@ act(() => { // make assertions ``` -This helps make your tests run closer to what real users would experience when using your application. The rest of these examples use `act()` to make these guarantees. +يساعد هذا في جعل اختباراتك أقرب إلى ما سيختبره المستخدمون الحقيقيون عند استخدام التطبيق الخاص بك. تستخدم بقية هذه الأمثلة `act()` لتقديم هذه الضمانات. -You might find using `act()` directly a bit too verbose. To avoid some of the boilerplate, you could use a library like [React Testing Library](https://testing-library.com/react), whose helpers are wrapped with `act()`. +قد تجد استخدام `act ()`بشكل مطول قليلاً جدًا. لتجنب بعض العناصر النحاسية ، يمكنك استخدام مكتبة مثل [React Testing Library](https://testing-library.com/react)، حيث يتم لف مساعديه `act()`. -> Note: +> ملحوطه: > -> The name `act` comes from the [Arrange-Act-Assert](http://wiki.c2.com/?ArrangeActAssert) pattern. +> اسم `act` يأتى من نمط ال [Arrange-Act-Assert](http://wiki.c2.com/?ArrangeActAssert) --- -### Rendering {#rendering} +### (Rendering) استدعاء {#rendering} -Commonly, you might want to test whether a component renders correctly for given props. Consider a simple component that renders a message based on a prop: +بشكل شائع ، قد ترغب في اختبار ما إذا كان المكون يتم عرضه بشكل صحيح للدعائم المقدمة. ضع في اعتبارك مكونًا بسيطًا يعرض رسالة تستند إلى prop: ```jsx // hello.js @@ -97,7 +97,7 @@ export default function Hello(props) { } ``` -We can write a test for this component: +نستطيع كتابة الاختبار لهذا المكون: ```jsx{24-27} // hello.test.js @@ -142,9 +142,10 @@ it("renders with or without a name", () => { --- -### Data Fetching {#data-fetching} +### (Data Fetching) جلب اليانات {#data-fetching} + +بدلاً من استدعاء واجهات برمجة التطبيقات (APIs) الحقيقية في جميع الاختبارات ، يمكنك الطلب من الطلبات باستخدام بيانات وهمية. السخرية من جلب البيانات باستخدام البيانات "المزيفة" يمنع الاختبارات غير المستقرة بسبب خلفية غير متوفرة ، ويجعلها تعمل بشكل أسرع. ملاحظة: ربما لا تزال ترغب في تشغيل مجموعة فرعية من الاختبارات باستخدام ["end-to-end"](/docs/testing-environ.html # end-to-to-to-end-tests-aka-e2e-tests) التي تخبر ما إذا كان التطبيق كله يعمل معا. -Instead of calling real APIs in all your tests, you can mock requests with dummy data. Mocking data fetching with "fake" data prevents flaky tests due to an unavailable backend, and makes them run faster. Note: you may still want to run a subset of tests using an ["end-to-end"](/docs/testing-environments.html#end-to-end-tests-aka-e2e-tests) framework that tells whether the whole app is working together. ```jsx // user.js @@ -178,7 +179,7 @@ export default function User(props) { } ``` -We can write tests for it: +نستطيع كتابة الاختبارات من أجله: ```jsx{23-33,44-45} // user.test.js @@ -231,11 +232,12 @@ it("renders user data", async () => { --- -### Mocking Modules {#mocking-modules} +### (Mocking Modules) تقليد الوحدات {#mocking-modules} + +قد لا تعمل بعض الوحدات بشكل جيد داخل بيئة اختبار ، أو قد لا تكون ضرورية للاختبار نفسه. يمكن الاستهزاء هذه الوحدات النمطية مع بدائل وهمية تجعل من الأسهل لكتابة اختبارات للرمز الخاص بك. -Some modules might not work well inside a testing environment, or may not be as essential to the test itself. Mocking out these modules with dummy replacements can make it easier to write tests for your own code. +ضع في اعتبارك مكون `Contact` يتضمن مكوّن `GoogleMap` لجهة خارجية: -Consider a `Contact` component that embeds a third-party `GoogleMap` component: ```jsx // map.js @@ -274,7 +276,7 @@ function Contact(props) { } ``` -If we don't want to load this component in our tests, we can mock out the dependency itself to a dummy component, and run our tests: +إذا كنا لا نريد تحميل هذا المكون في اختباراتنا ، فيمكننا الاستغناء عن التبعية نفسها لمكون وهمية ، وإجراء اختباراتنا: ```jsx{10-18} // contact.test.js @@ -340,9 +342,9 @@ it("should render contact information", () => { --- -### Events {#events} +### (Events) الأحداث {#events} -We recommend dispatching real DOM events on DOM elements, and then asserting on the result. Consider a `Toggle` component: +نوصي بإرسال أحداث DOM حقيقية على عناصر DOM ، ثم التأكيد على النتيجة. النظر في عنصر `toggle`: ```jsx // toggle.js @@ -365,7 +367,7 @@ export default function Toggle(props) { } ``` -We could write tests for it: +نستطيع كتابة الاختبارات من أجله: ```jsx{13-14,35,43} // toggle.test.js @@ -419,17 +421,16 @@ it("changes value when clicked", () => { }); ``` -Different DOM events and their properties are described in [MDN](https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent). Note that you need to pass `{ bubbles: true }` in each event you create for it to reach the React listener because React automatically delegates events to the document. +يتم وصف أحداث DOM المختلفة وخصائصها في [MDN](https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent). لاحظ أنك بحاجة إلى تمرير `{bubbles: true}` في كل حدث تقوم بإنشائه للوصول إلى مستمع React لأن React يفوض الأحداث تلقائيًا إلى المستند. -> Note: +> ملحوظه: > -> React Testing Library offers a [more concise helper](https://testing-library.com/docs/dom-testing-library/api-events) for firing events. - +> تقدم مكتبة React الاختبار [more concise helper](https://testing-library.com/docs/dom-testing-library/api-events) لإطلاق الأحداث. --- -### Timers {#timers} +### (Timers) العداد {#timers} -Your code might use timer-based functions like `setTimeout` to schedule more work in the future. In this example, a multiple choice panel waits for a selection and advances, timing out if a selection isn't made in 5 seconds: +قد يستخدم الكود الخاص بك وظائف تعتمد على المؤقت مثل `setTimeout` لجدولة المزيد من العمل في المستقبل. في هذا المثال ، تنتظر لوحة الاختيار من متعدد التحديد والتقدم ، وتنتهي المهلة إذا لم يتم تحديد في غضون 5 ثوانٍ: ```jsx // card.js @@ -458,7 +459,8 @@ export default function Card(props) { } ``` -We can write tests for this component by leveraging [Jest's timer mocks](https://jestjs.io/docs/en/timer-mocks), and testing the different states it can be in. +يمكننا كتابة اختبارات لهذا المكون من خلال الاستفادة من [Jest's timer mocks](https://jestjs.io/docs/en/timer-mocks) ، واختبار الحالات المختلفة التي يمكن أن يكون فيها. + ```jsx{7,31,37,49,59} // card.test.js @@ -540,15 +542,15 @@ it("should accept selections", () => { }); ``` -You can use fake timers only in some tests. Above, we enabled them by calling `jest.useFakeTimers()`. The main advantage they provide is that your test doesn't actually have to wait five seconds to execute, and you also didn't need to make the component code more convoluted just for testing. +يمكنك استخدام مؤقتات مزيفة فقط في بعض الاختبارات. أعلاه ، قمنا بتمكينهم من خلال استدعاء`jest.useFakeTimers ()`. الميزة الرئيسية التي يقدمونها هي أن اختبارك ليس مضطرًا في الواقع إلى الانتظار خمس ثوان للتنفيذ ، وأنك لست بحاجة أيضًا إلى جعل رمز المكون معقدًا فقط للاختبار. --- -### Snapshot Testing {#snapshot-testing} +### (Snapshot Testing) لقطة احتبار {#snapshot-testing} -Frameworks like Jest also let you save "snapshots" of data with [`toMatchSnapshot` / `toMatchInlineSnapshot`](https://jestjs.io/docs/en/snapshot-testing). With these, we can "save" the renderered component output and ensure that a change to it has to be explicitly committed as a change to the snapshot. +تتيح لك أطر مثل Jest أيضًا حفظ "لقطات" للبيانات باستخدام [`toMatchSnapshot` /` toMatchInlineSnapshot`](https://jestjs.io/docs/ar/snapshot-testing). باستخدام هذه ، يمكننا "حفظ" إخراج المكون الذي تم تقديمه والتأكد من أن التغيير الذي تم إجراؤه عليه يجب الالتزام به صراحة كتغيير في اللقطة. -In this example, we render a component and format the rendered HTML with the [`pretty`](https://www.npmjs.com/package/pretty) package, before saving it as an inline snapshot: +في هذا المثال ، نقدم مكونًا ونقوم بتنسيق HTML المقدم مع الحزمة [`pretty`](https://www.npmjs.com/package/pretty) ، قبل حفظها في صورة لقطة مضمّنة: ```jsx{29-31} // hello.test.js, again @@ -601,13 +603,13 @@ it("should render a greeting", () => { }); ``` -It's typically better to make more specific assertions than to use snapshots. These kinds of tests include implementation details so they break easily, and teams can get desensitized to snapshot breakages. Selectively [mocking some child components](#mocking-modules) can help reduce the size of snapshots and keep them readable for the code review. +من الأفضل عادة تقديم تأكيدات أكثر تحديدًا من استخدام اللقطات. تتضمن هذه الأنواع من الاختبارات تفاصيل التنفيذ حتى تنقطع بسهولة ، ويمكن أن تتأثر الفرق بالحساسية عند كسرها. بشكل انتقائي [mocking some child components](#mocking-modules) يمكن أن يساعد في تقليل حجم اللقطات وإبقائها قابلة للقراءة لمراجعة الكود. --- -### Multiple Renderers {#multiple-renderers} +### (Multiple Renderers) استدعاء كثيرا {#multiple-renderers} -In rare cases, you may be running a test on a component that uses multiple renderers. For example, you may be running snapshot tests on a component with `react-test-renderer`, that internally uses `ReactDOM.render` inside a child component to render some content. In this scenario, you can wrap updates with `act()`s corresponding to their renderers. +في حالات نادرة ، قد تقوم بإجراء اختبار على مكون يستخدم عارضين متعددين. على سبيل المثال ، قد تقوم بإجراء اختبارات لقطة على مكون باستخدام `react-test-renderer` ، والذي يستخدم داخليًا `ReactDOM.render` داخل مكون تابع لتقديم بعض المحتوى. في هذا السيناريو ، يمكنك التفاف التحديثات مع `act ()` المطابقين للعارضين. ```jsx import { act as domAct } from "react-dom/test-utils"; @@ -624,6 +626,6 @@ expect(root).toMatchSnapshot(); --- -### Something Missing? {#something-missing} +### أيوجد شئ مفقود ؟ {#something-missing} -If some common scenario is not covered, please let us know on the [issue tracker](https://github.com/reactjs/reactjs.org/issues) for the documentation website. +إذا لم تتم تغطية بعض السيناريوهات الشائعة ، فالرجاء إخبارنا على [issue tracker](https://github.com/reactjs/reactjs.org/issues) لموقع الوثائق. From 5bbcfd1211821dd4440bbc869cd31b4553c5eadb Mon Sep 17 00:00:00 2001 From: Mohamed Abdel Nasser Date: Fri, 22 Nov 2019 09:54:31 +0200 Subject: [PATCH 3/5] Update translating the requested changes --- content/docs/testing-recipes.md | 42 ++++++++++++++++----------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/content/docs/testing-recipes.md b/content/docs/testing-recipes.md index b9a112a12..c6125cc64 100644 --- a/content/docs/testing-recipes.md +++ b/content/docs/testing-recipes.md @@ -1,16 +1,16 @@ --- id: testing-recipes -title: طريقة اجراء الاختبارات +title: طرق اجراء الاختبارات permalink: docs/testing-recipes.html prev: testing.html next: testing-environments.html --- -أنماط الاختبار الشائعه لمكونات مكتبة React +أنماط الاختبار الشائعة لمكونات React. -> ملحوظه: +> ملاحظة: > -> تفترض هذه الصفحة أنك تستخدم [Jest](https://jestjs.io/) كمرشح للاختبار. إذا كنت تستخدم عداء اختبار مختلفًا ، فقد تحتاج إلى ضبط واجهة برمجة التطبيقات ، ولكن من المحتمل أن يكون الشكل العام للحل هو نفسه. اقرأ المزيد من التفاصيل حول إعداد بيئة اختبار على صفحة اختبار البيئات.[Testing Environments](/docs/testing-environments.html) +> تفترض هذه الصفحة أنك تستخدم [Jest](https://jestjs.io/) كمرشح للاختبار. إذا كنت تستخدم عداء اختبار مختلفًا ، فقد تحتاج إلى ضبط واجهة برمجة التطبيقات ، ولكن من المحتمل أن يكون الشكل العام للحل هو نفسه. اقرأ المزيد من التفاصيل حول إعداد بيئة اختبار على صفحة اختبار البيئات.[بيئات الاختبار](/docs/testing-environments.html) @@ -30,7 +30,7 @@ next: testing-environments.html --- -### (ٍSetup) طريقة الاعداد {#setup--teardown} +### التثبيت/الغاء التثبيت {#setup--teardown} لكل اختبار نقوم باعادة تقديم React tree الى عنصر DOM المرفق ب `document`. وهذا مهم حتى نتمكن من استقبال DOM events. وعندما ينتهى الاختبار نريد ازاله ال tree من `document`. @@ -73,13 +73,13 @@ act(() => { قد تجد استخدام `act ()`بشكل مطول قليلاً جدًا. لتجنب بعض العناصر النحاسية ، يمكنك استخدام مكتبة مثل [React Testing Library](https://testing-library.com/react)، حيث يتم لف مساعديه `act()`. -> ملحوطه: +> ملاحظة: > > اسم `act` يأتى من نمط ال [Arrange-Act-Assert](http://wiki.c2.com/?ArrangeActAssert) --- -### (Rendering) استدعاء {#rendering} +### التصيير {#rendering} بشكل شائع ، قد ترغب في اختبار ما إذا كان المكون يتم عرضه بشكل صحيح للدعائم المقدمة. ضع في اعتبارك مكونًا بسيطًا يعرض رسالة تستند إلى prop: @@ -142,9 +142,9 @@ it("renders with or without a name", () => { --- -### (Data Fetching) جلب اليانات {#data-fetching} +### جلب البيانات {#data-fetching} -بدلاً من استدعاء واجهات برمجة التطبيقات (APIs) الحقيقية في جميع الاختبارات ، يمكنك الطلب من الطلبات باستخدام بيانات وهمية. السخرية من جلب البيانات باستخدام البيانات "المزيفة" يمنع الاختبارات غير المستقرة بسبب خلفية غير متوفرة ، ويجعلها تعمل بشكل أسرع. ملاحظة: ربما لا تزال ترغب في تشغيل مجموعة فرعية من الاختبارات باستخدام ["end-to-end"](/docs/testing-environ.html # end-to-to-to-end-tests-aka-e2e-tests) التي تخبر ما إذا كان التطبيق كله يعمل معا. +بدلاً من استدعاء واجهات برمجة التطبيقات (APIs) الحقيقية في جميع الاختبارات ، يمكنك الطلب من الطلبات باستخدام بيانات وهمية. السخرية من جلب البيانات باستخدام البيانات "المزيفة" يمنع الاختبارات غير المستقرة بسبب خلفية غير متوفرة ، ويجعلها تعمل بشكل أسرع. ملاحظة: ربما لا تزال ترغب في تشغيل مجموعة فرعية من الاختبارات باستخدام ["end-to-end"](/docs/testing-environ.html#end-to-to-to-end-tests-aka-e2e-tests) التي تخبر ما إذا كان التطبيق كله يعمل معا. ```jsx @@ -232,9 +232,9 @@ it("renders user data", async () => { --- -### (Mocking Modules) تقليد الوحدات {#mocking-modules} +### محاكاة الوحدات {#mocking-modules} -قد لا تعمل بعض الوحدات بشكل جيد داخل بيئة اختبار ، أو قد لا تكون ضرورية للاختبار نفسه. يمكن الاستهزاء هذه الوحدات النمطية مع بدائل وهمية تجعل من الأسهل لكتابة اختبارات للرمز الخاص بك. +قد لا تعمل بعض الوحدات بشكل جيد داخل بيئة اختبار ، أو قد لا تكون ضرورية للاختبار نفسه. يمكن محاكاة هذه الوحدات النمطية مع بدائل وهمية تجعل من الأسهل لكتابة اختبارات للرمز الخاص بك. ضع في اعتبارك مكون `Contact` يتضمن مكوّن `GoogleMap` لجهة خارجية: @@ -342,9 +342,9 @@ it("should render contact information", () => { --- -### (Events) الأحداث {#events} +### الأحداث {#events} -نوصي بإرسال أحداث DOM حقيقية على عناصر DOM ، ثم التأكيد على النتيجة. النظر في عنصر `toggle`: +نوصي بإرسال أحداث DOM حقيقية على عناصر DOM ، ثم التأكيد على النتيجة. النظر في عنصر `Toggle`: ```jsx // toggle.js @@ -423,9 +423,9 @@ it("changes value when clicked", () => { يتم وصف أحداث DOM المختلفة وخصائصها في [MDN](https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent). لاحظ أنك بحاجة إلى تمرير `{bubbles: true}` في كل حدث تقوم بإنشائه للوصول إلى مستمع React لأن React يفوض الأحداث تلقائيًا إلى المستند. -> ملحوظه: +> ملاحظة: > -> تقدم مكتبة React الاختبار [more concise helper](https://testing-library.com/docs/dom-testing-library/api-events) لإطلاق الأحداث. +> تقدم مكتبة React الاختبار [أكثر اختصارا للمساعدات](https://testing-library.com/docs/dom-testing-library/api-events) لإطلاق الأحداث. --- ### (Timers) العداد {#timers} @@ -546,7 +546,7 @@ it("should accept selections", () => { --- -### (Snapshot Testing) لقطة احتبار {#snapshot-testing} +### لقطة اختبار {#snapshot-testing} تتيح لك أطر مثل Jest أيضًا حفظ "لقطات" للبيانات باستخدام [`toMatchSnapshot` /` toMatchInlineSnapshot`](https://jestjs.io/docs/ar/snapshot-testing). باستخدام هذه ، يمكننا "حفظ" إخراج المكون الذي تم تقديمه والتأكد من أن التغيير الذي تم إجراؤه عليه يجب الالتزام به صراحة كتغيير في اللقطة. @@ -603,13 +603,13 @@ it("should render a greeting", () => { }); ``` -من الأفضل عادة تقديم تأكيدات أكثر تحديدًا من استخدام اللقطات. تتضمن هذه الأنواع من الاختبارات تفاصيل التنفيذ حتى تنقطع بسهولة ، ويمكن أن تتأثر الفرق بالحساسية عند كسرها. بشكل انتقائي [mocking some child components](#mocking-modules) يمكن أن يساعد في تقليل حجم اللقطات وإبقائها قابلة للقراءة لمراجعة الكود. +من الأفضل عادة تقديم تأكيدات أكثر تحديدًا من استخدام اللقطات. تتضمن هذه الأنواع من الاختبارات تفاصيل التنفيذ حتى تنقطع بسهولة ، ويمكن أن تتأثر الفرق بالحساسية عند كسرها. بشكل انتقائي [محاكاة بعض المكونات الابناء](#mocking-modules) يمكن أن يساعد في تقليل حجم اللقطات وإبقائها قابلة للقراءة لمراجعة الكود. --- -### (Multiple Renderers) استدعاء كثيرا {#multiple-renderers} +### التصيير المتعدد {#multiple-renderers} -في حالات نادرة ، قد تقوم بإجراء اختبار على مكون يستخدم عارضين متعددين. على سبيل المثال ، قد تقوم بإجراء اختبارات لقطة على مكون باستخدام `react-test-renderer` ، والذي يستخدم داخليًا `ReactDOM.render` داخل مكون تابع لتقديم بعض المحتوى. في هذا السيناريو ، يمكنك التفاف التحديثات مع `act ()` المطابقين للعارضين. +في حالات نادرة ، قد تقوم بإجراء اختبار على مكون يستخدم التصيير المتعدد. على سبيل المثال ، قد تقوم بإجراء اختبارات لقطة على مكون باستخدام `react-test-renderer` ، والذي يستخدم داخليًا `ReactDOM.render` داخل مكون تابع لتقديم بعض المحتوى. في هذا السيناريو ، يمكنك التفاف التحديثات مع `act ()` المطابقين لتصيير. ```jsx import { act as domAct } from "react-dom/test-utils"; @@ -626,6 +626,6 @@ expect(root).toMatchSnapshot(); --- -### أيوجد شئ مفقود ؟ {#something-missing} +### شئ مفقود ؟ {#something-missing} -إذا لم تتم تغطية بعض السيناريوهات الشائعة ، فالرجاء إخبارنا على [issue tracker](https://github.com/reactjs/reactjs.org/issues) لموقع الوثائق. +إذا لم تتم تغطية بعض السيناريوهات الشائعة ، فالرجاء إخبارنا على [تتبع القضايا](https://github.com/reactjs/reactjs.org/issues) لموقع الوثائق. From f92411a6327b16639d5462c96015b500e5ffbf6f Mon Sep 17 00:00:00 2001 From: Mohamed Abdel Nasser Date: Sat, 23 Nov 2019 09:48:16 +0200 Subject: [PATCH 4/5] improve the requested changes --- content/docs/testing-recipes.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/docs/testing-recipes.md b/content/docs/testing-recipes.md index c6125cc64..f7b7360fc 100644 --- a/content/docs/testing-recipes.md +++ b/content/docs/testing-recipes.md @@ -60,7 +60,7 @@ afterEach(() => { ### `act()` {#act} -عند كتابة اختبارات واجهة المستخدم ، يمكن اعتبار المهام مثل التقديم أو أحداث المستخدم أو جلب البيانات "وحدات" للتفاعل مع واجهة المستخدم. توفر React مساعدًا يسمى `act ()` يتأكد من أن جميع التحديثات المتعلقة بهذه "الوحدات" قد تمت معالجتها وتطبيقها على DOM قبل تقديم أي تأكيدات: +عند كتابة اختبارات واجهة المستخدم ، يمكن اعتبار المهام مثل التصيير أو أحداث المستخدم أو جلب البيانات "وحدات" للتفاعل مع واجهة المستخدم. توفر React مساعدًا يسمى `act ()` يتأكد من أن جميع التحديثات المتعلقة بهذه "الوحدات" قد تمت معالجتها وتطبيقها على DOM قبل تقديم أي تأكيدات: ```js act(() => { @@ -542,13 +542,13 @@ it("should accept selections", () => { }); ``` -يمكنك استخدام مؤقتات مزيفة فقط في بعض الاختبارات. أعلاه ، قمنا بتمكينهم من خلال استدعاء`jest.useFakeTimers ()`. الميزة الرئيسية التي يقدمونها هي أن اختبارك ليس مضطرًا في الواقع إلى الانتظار خمس ثوان للتنفيذ ، وأنك لست بحاجة أيضًا إلى جعل رمز المكون معقدًا فقط للاختبار. +يمكنك استخدام مؤقتات مزيفة فقط في بعض الاختبارات. أعلاه ، قمنا بتمكينهم من خلال استدعاء`jest.useFakeTimers()`. الميزة الرئيسية التي يقدمونها هي أن اختبارك ليس مضطرًا في الواقع إلى الانتظار خمس ثوان للتنفيذ ، وأنك لست بحاجة أيضًا إلى جعل رمز المكون معقدًا فقط للاختبار. --- ### لقطة اختبار {#snapshot-testing} -تتيح لك أطر مثل Jest أيضًا حفظ "لقطات" للبيانات باستخدام [`toMatchSnapshot` /` toMatchInlineSnapshot`](https://jestjs.io/docs/ar/snapshot-testing). باستخدام هذه ، يمكننا "حفظ" إخراج المكون الذي تم تقديمه والتأكد من أن التغيير الذي تم إجراؤه عليه يجب الالتزام به صراحة كتغيير في اللقطة. +تتيح لك أطر مثل Jest أيضًا حفظ "لقطات" للبيانات باستخدام [`toMatchSnapshot` /`toMatchInlineSnapshot`](https://jestjs.io/docs/en/snapshot-testing). باستخدام هذه ، يمكننا "حفظ" إخراج المكون الذي تم تقديمه والتأكد من أن التغيير الذي تم إجراؤه عليه يجب الالتزام به صراحة كتغيير في اللقطة. في هذا المثال ، نقدم مكونًا ونقوم بتنسيق HTML المقدم مع الحزمة [`pretty`](https://www.npmjs.com/package/pretty) ، قبل حفظها في صورة لقطة مضمّنة: @@ -626,6 +626,6 @@ expect(root).toMatchSnapshot(); --- -### شئ مفقود ؟ {#something-missing} +### شئ مفقود ؟ {#something-missing} إذا لم تتم تغطية بعض السيناريوهات الشائعة ، فالرجاء إخبارنا على [تتبع القضايا](https://github.com/reactjs/reactjs.org/issues) لموقع الوثائق. From 6594af55ffa0ca87d0bf3b2637695971375dc1a8 Mon Sep 17 00:00:00 2001 From: Mohamed Abdel Nasser Date: Sun, 24 Nov 2019 16:25:00 +0200 Subject: [PATCH 5/5] remove double spaces --- content/docs/testing-recipes.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/content/docs/testing-recipes.md b/content/docs/testing-recipes.md index f7b7360fc..cace84545 100644 --- a/content/docs/testing-recipes.md +++ b/content/docs/testing-recipes.md @@ -10,7 +10,7 @@ next: testing-environments.html > ملاحظة: > -> تفترض هذه الصفحة أنك تستخدم [Jest](https://jestjs.io/) كمرشح للاختبار. إذا كنت تستخدم عداء اختبار مختلفًا ، فقد تحتاج إلى ضبط واجهة برمجة التطبيقات ، ولكن من المحتمل أن يكون الشكل العام للحل هو نفسه. اقرأ المزيد من التفاصيل حول إعداد بيئة اختبار على صفحة اختبار البيئات.[بيئات الاختبار](/docs/testing-environments.html) +> تفترض هذه الصفحة أنك تستخدم [Jest](https://jestjs.io/) كمرشح للاختبار. إذا كنت تستخدم عداء اختبار مختلفًا ، فقد تحتاج إلى ضبط واجهة برمجة التطبيقات ، ولكن من المحتمل أن يكون الشكل العام للحل هو نفسه. اقرأ المزيد من التفاصيل حول إعداد بيئة اختبار على صفحة اختبار البيئات.[بيئات الاختبار](/docs/testing-environments.html) @@ -32,9 +32,9 @@ next: testing-environments.html ### التثبيت/الغاء التثبيت {#setup--teardown} -لكل اختبار نقوم باعادة تقديم React tree الى عنصر DOM المرفق ب `document`. وهذا مهم حتى نتمكن من استقبال DOM events. وعندما ينتهى الاختبار نريد ازاله ال tree من `document`. +لكل اختبار نقوم باعادة تقديم React tree الى عنصر DOM المرفق ب `document`. وهذا مهم حتى نتمكن من استقبال DOM events. وعندما ينتهى الاختبار نريد ازاله ال tree من `document`. -هناك طريقة شائعة للقيام بذلك هي استخدام زوج من `beforeEach` و `afterEach` بحيث يتم تشغيلهما دائمًا وعزل آثار الاختبار عن نفسه: +هناك طريقة شائعة للقيام بذلك هي استخدام زوج من `beforeEach` و `afterEach` بحيث يتم تشغيلهما دائمًا وعزل آثار الاختبار عن نفسه: ```jsx import { unmountComponentAtNode } from "react-dom"; @@ -71,11 +71,11 @@ act(() => { يساعد هذا في جعل اختباراتك أقرب إلى ما سيختبره المستخدمون الحقيقيون عند استخدام التطبيق الخاص بك. تستخدم بقية هذه الأمثلة `act()` لتقديم هذه الضمانات. -قد تجد استخدام `act ()`بشكل مطول قليلاً جدًا. لتجنب بعض العناصر النحاسية ، يمكنك استخدام مكتبة مثل [React Testing Library](https://testing-library.com/react)، حيث يتم لف مساعديه `act()`. +قد تجد استخدام `act()`بشكل مطول قليلاً جدًا. لتجنب بعض العناصر النحاسية ، يمكنك استخدام مكتبة مثل [React Testing Library](https://testing-library.com/react)، حيث يتم لف مساعديه `act()`. > ملاحظة: > -> اسم `act` يأتى من نمط ال [Arrange-Act-Assert](http://wiki.c2.com/?ArrangeActAssert) +> اسم `act` يأتى من نمط ال [Arrange-Act-Assert](http://wiki.c2.com/?ArrangeActAssert) --- @@ -142,7 +142,8 @@ it("renders with or without a name", () => { --- -### جلب البيانات {#data-fetching} +### جلب البيانات {#data-fetching} + بدلاً من استدعاء واجهات برمجة التطبيقات (APIs) الحقيقية في جميع الاختبارات ، يمكنك الطلب من الطلبات باستخدام بيانات وهمية. السخرية من جلب البيانات باستخدام البيانات "المزيفة" يمنع الاختبارات غير المستقرة بسبب خلفية غير متوفرة ، ويجعلها تعمل بشكل أسرع. ملاحظة: ربما لا تزال ترغب في تشغيل مجموعة فرعية من الاختبارات باستخدام ["end-to-end"](/docs/testing-environ.html#end-to-to-to-end-tests-aka-e2e-tests) التي تخبر ما إذا كان التطبيق كله يعمل معا. @@ -232,7 +233,7 @@ it("renders user data", async () => { --- -### محاكاة الوحدات {#mocking-modules} +### محاكاة الوحدات {#mocking-modules} قد لا تعمل بعض الوحدات بشكل جيد داخل بيئة اختبار ، أو قد لا تكون ضرورية للاختبار نفسه. يمكن محاكاة هذه الوحدات النمطية مع بدائل وهمية تجعل من الأسهل لكتابة اختبارات للرمز الخاص بك. @@ -342,7 +343,7 @@ it("should render contact information", () => { --- -### الأحداث {#events} +### الأحداث {#events} نوصي بإرسال أحداث DOM حقيقية على عناصر DOM ، ثم التأكيد على النتيجة. النظر في عنصر `Toggle`: @@ -546,7 +547,7 @@ it("should accept selections", () => { --- -### لقطة اختبار {#snapshot-testing} +### لقطة اختبار {#snapshot-testing} تتيح لك أطر مثل Jest أيضًا حفظ "لقطات" للبيانات باستخدام [`toMatchSnapshot` /`toMatchInlineSnapshot`](https://jestjs.io/docs/en/snapshot-testing). باستخدام هذه ، يمكننا "حفظ" إخراج المكون الذي تم تقديمه والتأكد من أن التغيير الذي تم إجراؤه عليه يجب الالتزام به صراحة كتغيير في اللقطة.