From 840510bbc99bd6143bdbccffe8364f516d948509 Mon Sep 17 00:00:00 2001 From: Mohamed Abdel Nasser Date: Tue, 26 Nov 2019 06:05:20 +0200 Subject: [PATCH 1/5] translate first part of testing-envs --- content/docs/testing-environments.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index 5120a4f6d..e65d31cc7 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -1,17 +1,18 @@ --- id: testing-environments -title: Testing Environments +title: بيئات الاختبار permalink: docs/testing-environments.html prev: testing-recipes.html --- -This document goes through the factors that can affect your environment and recommendations for some scenarios. +يتناول هذا المستند العوامل التي يمكن أن تؤثر على بيئتك والتوصيات المتعلقة ببعض السيناريوهات. -### Test runners {#test-runners} -Test runners like [Jest](https://jestjs.io/), [mocha](https://mochajs.org/), [ava](https://github.com/avajs/ava) let you write test suites as regular JavaScript, and run them as part of your development process. Additionally, test suites are run as part of continuous integration. +### منفذي الاختبار {#test-runners} + +يتيح لك منفذى الاختبار مثل [Jest](https://jestjs.io/), [mocha](https://mochajs.org/), [ava](https://github.com/avajs/ava) كتابة مجموعات اختبار على هيئه JavaScript و تشغيلها كجزء من عملية التطوير الخاصة بك. بالاضافة الى ذلك يتم تشغبل مجموعات الاختبار كجزء من التكامل المستمر. - Jest is widely compatible with React projects, supporting features like mocked [modules](#mocking-modules) and [timers](#mocking-timers), and [`jsdom`](#mocking-a-rendering-surface) support. **If you use Create React App, [Jest is already included out of the box](https://facebook.github.io/create-react-app/docs/running-tests) with useful defaults.** - Libraries like [mocha](https://mochajs.org/#running-mocha-in-the-browser) work well in real browser environments, and could help for tests that explicitly need it. From f84d6e28dddf4cea082bcab2f0ca60da3cd3d25d Mon Sep 17 00:00:00 2001 From: Mohamed Abdel Nasser Date: Wed, 27 Nov 2019 17:53:20 +0200 Subject: [PATCH 2/5] finish translating testing envs --- content/docs/testing-environments.md | 47 ++++++++++++++-------------- 1 file changed, 24 insertions(+), 23 deletions(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index e65d31cc7..408a8ecbf 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -14,46 +14,47 @@ prev: testing-recipes.html يتيح لك منفذى الاختبار مثل [Jest](https://jestjs.io/), [mocha](https://mochajs.org/), [ava](https://github.com/avajs/ava) كتابة مجموعات اختبار على هيئه JavaScript و تشغيلها كجزء من عملية التطوير الخاصة بك. بالاضافة الى ذلك يتم تشغبل مجموعات الاختبار كجزء من التكامل المستمر. -- Jest is widely compatible with React projects, supporting features like mocked [modules](#mocking-modules) and [timers](#mocking-timers), and [`jsdom`](#mocking-a-rendering-surface) support. **If you use Create React App, [Jest is already included out of the box](https://facebook.github.io/create-react-app/docs/running-tests) with useful defaults.** -- Libraries like [mocha](https://mochajs.org/#running-mocha-in-the-browser) work well in real browser environments, and could help for tests that explicitly need it. -- End-to-end tests are used for testing longer flows across multiple pages, and require a [different setup](#end-to-end-tests-aka-e2e-tests). +- Jest متوافق على نطاق واسع مع مشاريع React, و دعم مميزات جديده مثل [الوحدات النمطية ](#moking-modules)و [العداد](#moking-timers) و دعم [`jsdom`](#mocking-a-rendering-surface`). **اذا كنت تستخدم Create React App اذن [Jest موجود بالفعل](https://facebook.github.io/create-react-app/docs/running-tests) مع افتراضات مفيده**. +- المكتبات مثل [mocha](https://mochajs.org/#running-mocha-in-the-browser) تعمل بشكل جيد في بيئات المتصفح الحقيقي ، ويمكن أن تساعد في الاختبارات التي تحتاجها بشكل صريح. +- تُستخدم الاختبارات من طرف إلى طرف لاختبار تدفقات أطول عبر عدة صفحات ، وتتطلب [إعداد مختلف](#end-to-end-tests-aka-e2e-tests). -### Mocking a rendering surface {#mocking-a-rendering-surface} +### محاكاة سطح التصيير {#mocking-a-rendering-surface} -Tests often run in an environment without access to a real rendering surface like a browser. For these environments, we recommend simulating a browser with [`jsdom`](https://github.com/jsdom/jsdom), a lightweight browser implementation that runs inside Node.js. +تعمل الاختبارات غالبًا في بيئة دون الوصول إلى سطح التصيير الحقيقي مثل المستعرض. بالنسبة لهذه البيئات ، نوصي بمحاكاة مستعرض باستخدام [`jsdom`](https://github.com/jsdom/jsdom) ، وهو تطبيق متصفح خفيف الوزن يعمل داخل Node.js. -In most cases, jsdom behaves like a regular browser would, but doesn't have features like [layout and navigation](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform). This is still useful for most web-based component tests, since it runs quicker than having to start up a browser for each test. It also runs in the same process as your tests, so you can write code to examine and assert on the rendered DOM. +في معظم الحالات ، يتصرف jsdom كالمتصفح العادي ، لكن ليس به ميزات مثل [layout and navigation ](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform). لا يزال هذا مفيدًا لمعظم اختبارات المكونات المستندة إلى الويب ، لأنه يعمل بشكل أسرع من الاضطرار إلى بدء تشغيل مستعرض لكل اختبار. يتم تشغيله أيضًا في نفس عملية الاختبارات الخاصة بك ، حتى تتمكن من كتابة التعليمات البرمجية لفحصها وتأكيدها على DOM. -Just like in a real browser, jsdom lets us model user interactions; tests can dispatch events on DOM nodes, and then observe and assert on the side effects of these actions [(example)](/docs/testing-recipes.html#events). +تمامًا كما في المتصفح الحقيقي ، تتيح لنا jsdom تصميم تفاعلات المستخدم ؛ يمكن للاختبارات إرسال الأحداث على عقد DOM ، ثم مراقبة الآثار الجانبية لهذه الإجراءات والتأكيد عليها [(مثال)](/docs/testing-recipes.html#events). -A large portion of UI tests can be written with the above setup: using Jest as a test runner, rendered to jsdom, with user interactions specified as sequences of browser events, powered by the `act()` helper [(example)](/docs/testing-recipes.html). For example, a lot of React's own tests are written with this combination. -If you're writing a library that tests mostly browser-specific behavior, and requires native browser behavior like layout or real inputs, you could use a framework like [mocha.](https://mochajs.org/) +يمكن كتابة جزء كبير من اختبارات واجهة المستخدم باستخدام الإعداد أعلاه: استخدام Jest كمنفذ للاختبار ، يتم تصييره إلى jsdom ، مع تفاعلات المستخدم المحددة كسلسلة من أحداث المتصفح ، مدعومًا بـ `act ()` helper [(مثال)](/docs/testing-recipes.html). على سبيل المثال ، تتم كتابة الكثير من اختبارات React الخاصة مع هذه المجموعة. -In an environment where you _can't_ simulate a DOM (e.g. testing React Native components on Node.js), you could use [event simulation helpers](https://reactjs.org/docs/test-utils.html#simulate) to simulate interactions with elements. Alternately, you could use the `fireEvent` helper from [`@testing-library/react-native`](https://testing-library.com/docs/native-testing-library). +إذا كنت تكتب مكتبة تختبر في الغالب السلوك الخاص بالمتصفح ، وتتطلب سلوك المستعرض الأصلي مثل التخطيط أو المدخلات الحقيقية ، يمكنك استخدام إطار عمل مثل [mocha.](https://mochajs.org/) -Frameworks like [Cypress](https://www.cypress.io/), [puppeteer](https://github.com/GoogleChrome/puppeteer) and [webdriver](https://www.seleniumhq.org/projects/webdriver/) are useful for running [end-to-end tests](#end-to-end-tests-aka-e2e-tests). +في بيئة لا يمكنك فيها محاكاة DOM (على سبيل المثال ، اختبار مكونات React Native على Node.js) ، يمكنك استخدام [مساعدي محاكاة الأحداث](https://reactjs.org/docs/test-utils.html#simulate) لمحاكاة التفاعلات مع العناصر. بالتناوب ، يمكنك استخدام "fireEvent" المساعد من [`@ testing-library / react-native`](https://testing-library.com/docs/native-testing-library). -### Mocking functions {#mocking-functions} +اطارات العمل مثل [Cypress](https://www.cypress.io/) و [puppeteer](https://github.com/GoogleChrome/puppeteer) و [webdriver](https://www.seleniumhq.org/projects / webdriver /) مفيدة لتشغيل [end-to-end test ](#end-to-end-tests-aka-e2e-tests). -When writing tests, we'd like to mock out the parts of our code that don't have equivalents inside our testing environment (e.g. checking `navigator.onLine` status inside Node.js). Tests could also spy on some functions, and observe how other parts of the test interact with them. It is then useful to be able to selectively mock these functions with test-friendly versions. +### محاكاة الدوال {#mocking-functions} -This is especially useful for data fetching. It is usually preferable to use "fake" data for tests to avoid the slowness and flakiness due to fetching from real API endpoints [(example)](/docs/testing-recipes.html#data-fetching). This helps make the tests predictable. Libraries like [Jest](https://jestjs.io/) and [sinon](https://sinonjs.org/), among others, support mocked functions. For end-to-end tests, mocking network can be more difficult, but you might also want to test the real API endpoints in them anyway. +عند كتابة الاختبارات ، نود أن نحاكى الكود الخاص بنا الذى لا يحتوى على مكافئ له فى بيئة الاختبار الخاصة بنا (على سبيل المثال التحقق من حالة `navigator.onLin` داخل Node.js). يمكن للاختبارات أيضًا التجسس على بعض الوظائف ، ومراقبة كيفية تفاعل أجزاء أخرى من الاختبار معها. من المفيد عندئذ أن تكون قادرًا على محاكاة هذه الدوال باصدارات سهلة الاستخدام بشكل الانتقائى. -### Mocking modules {#mocking-modules} +هذا مفيد بشكل خاص لجلب البيانات. من المفضل عادة استخدام البيانات "المزيفة" للاختبارات لتجنب البطء والضعف بسبب جلب نقاط نهاية API الحقيقية [(مثال) ](/docs/testing-recipes.html#data-fetching ). هذا يساعد على جعل الاختبارات يمكن التنبؤ بها. المكتبات مثل [Jest](https://jestjs.io/) و [sinon](https://sinonjs.org/)، من بين أمور أخرى ، تدعم محاكاه الدوال. بالنسبة للاختبارات الشاملة ، يمكن أن تكون محاكاة الشبكة أكثر صعوبة ، ولكن قد ترغب أيضًا في اختبار نقاط النهاية الحقيقية لواجهة برمجة التطبيقات فيها. -Some components have dependencies for modules that may not work well in test environments, or aren't essential to our tests. It can be useful to selectively mock these modules out with suitable replacements [(example)](/docs/testing-recipes.html#mocking-modules). +### محاكاه الوحدات {#mocking-modules} -On Node.js, runners like Jest [support mocking modules](https://jestjs.io/docs/en/manual-mocks). You could also use libraries like [`mock-require`](https://www.npmjs.com/package/mock-require). +تحتوي بعض المكونات على تبعيات للوحدات النمطية التي قد لا تعمل بشكل جيد في بيئات الاختبار ، أو ليست ضرورية لاختباراتنا. قد يكون من المفيد الاستغناء عن هذه الوحدات بشكل انتقائي مع بدائل مناسبة [(مثال)](/docs/testing-recipes.html#mocking-modules). -### Mocking timers {#mocking-timers} +على Node.js ، يقوم منفذى الاختبارات مثل Jest [بدعم محاكاة الوحدات](https://jestjs.io/docs/en/manual-mocks). يمكنك أيضًا استخدام مكتبات مثل [`mock-require`](https://www.npmjs.com/package/mock-require). -Components might be using time-based functions like `setTimeout`, `setInterval`, or `Date.now`. In testing environments, it can be helpful to mock these functions out with replacements that let you manually "advance" time. This is great for making sure your tests run fast! Tests that are dependent on timers would still resolve in order, but quicker [(example)](/docs/testing-recipes.html#timers). Most frameworks, including [Jest](https://jestjs.io/docs/en/timer-mocks), [sinon](https://sinonjs.org/releases/v7.3.2/fake-timers/) and [lolex](https://github.com/sinonjs/lolex), let you mock timers in your tests. +### محاكاة العداد {#mocking-timers} -Sometimes, you may not want to mock timers. For example, maybe you're testing an animation, or interacting with an endpoint that's sensitive to timing (like an API rate limiter). Libraries with timer mocks let you enable and disable them on a per test/suite basis, so you can explicitly choose how these tests would run. +قد تستخدم المكونات وظائف تستند إلى الوقت مثل `setTimeout` أو` setInterval` أو `Date.now`. في بيئات الاختبار ، قد يكون من المفيد الاستغناء عن هذه الوظائف مع البدائل التي تتيح لك "التقدم" يدويًا. هذا شيء عظيم للتأكد من أن اختباراتك تعمل بسرعة! الاختبارات التي تعتمد على العداد ستظل قائمة بالترتيب ، ولكن أسرع [(مثال)](/docs/testing-recipes.html#timers). معظم اطارات العمل ، بما في ذلك [Jest](https://jestjs.io/docs/en/timer-mocks) ، [sinon](https://sinonjs.org/releases/v7.3.2/fake-timers/) و [lolex](https://github.com/sinonjs/lolex) ، تتيح لك محاكاة العداد في اختباراتك. -### End-to-end tests {#end-to-end-tests-aka-e2e-tests} +في بعض الأحيان ، قد لا ترغب في محاكاة العداد. على سبيل المثال ، ربما تقوم باختبار رسم متحرك ، أو تتفاعل مع نقطة نهاية حساسة للتوقيت (like an API rate limiter). تتيح لك المكتبات التي بها محاكاه العداد تمكينها وتعطيلها على أساس كل اختبار / مجموعة ، بحيث يمكنك اختيار كيفية تشغيل هذه الاختبارات بشكل صريح. -End-to-end tests are useful for testing longer workflows, especially when they're critical to your business (such as payments or signups). For these tests, you'd probably want to test both how a real browser renders the whole app, fetches data from the real API endpoints, uses sessions and cookies, navigates between different links. You might also likely want to make assertions not just on the DOM state, but on the backing data as well (e.g. to verify whether the updates have been persisted to the database). +### اختبارات طرف الى طرف {#end-to-end-tests-aka-e2e-tests} -In this scenario, you would use a framework like [Cypress](https://www.cypress.io/) or a library like [puppeteer](https://github.com/GoogleChrome/puppeteer) so you can navigate between multiple routes and assert on side effects not just in the browser, but potentially on the backend as well. +تعد اختبارات طرف الى طرف مفيدة لاختبار سير عمل أطول ، خاصةً عندما تكون مهمة لنشاطك التجاري (مثل المدفوعات أو الاشتراكات). بالنسبة لهذه الاختبارات ، قد ترغب في اختبار كلٍّ من كيفية عرض المتصفح الحقيقي للتطبيق بأكمله ، وجلب البيانات من نقاط النهاية الحقيقية لواجهة برمجة التطبيقات ، واستخدام الجلسات وملفات تعريف الارتباط ، والتنقل بين الروابط المختلفة. قد ترغب أيضًا في تقديم تأكيدات ليس فقط في حالة DOM ، ولكن أيضًا على بيانات النسخ الاحتياطي (على سبيل المثال للتحقق من استمرار التحديثات في قاعدة البيانات). + +في هذا السيناريو ، يمكنك استخدام إطار عمل مثل [Cypress](https://www.cypress.io/) أو مكتبة مثل [puppeteer](https://github.com/GoogleChrome/puppeteer) حتى تتمكن من التنقل بين طرق متعددة والتأكيد على الآثار الجانبية ليس فقط في المتصفح ، ولكن يحتمل أن يكون على الواجهة الخلفية أيضًا. From 9ca4bb89e758573f311fb2efe06e4f81a6d2857f Mon Sep 17 00:00:00 2001 From: Mohamed Abdel Nasser Date: Thu, 28 Nov 2019 22:29:27 +0200 Subject: [PATCH 3/5] improve testing envs translate --- content/docs/testing-environments.md | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index 408a8ecbf..a38d9639f 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -1,6 +1,6 @@ --- id: testing-environments -title: بيئات الاختبار +title: اختبار البيئات permalink: docs/testing-environments.html prev: testing-recipes.html --- @@ -12,13 +12,12 @@ prev: testing-recipes.html ### منفذي الاختبار {#test-runners} -يتيح لك منفذى الاختبار مثل [Jest](https://jestjs.io/), [mocha](https://mochajs.org/), [ava](https://github.com/avajs/ava) كتابة مجموعات اختبار على هيئه JavaScript و تشغيلها كجزء من عملية التطوير الخاصة بك. بالاضافة الى ذلك يتم تشغبل مجموعات الاختبار كجزء من التكامل المستمر. - -- Jest متوافق على نطاق واسع مع مشاريع React, و دعم مميزات جديده مثل [الوحدات النمطية ](#moking-modules)و [العداد](#moking-timers) و دعم [`jsdom`](#mocking-a-rendering-surface`). **اذا كنت تستخدم Create React App اذن [Jest موجود بالفعل](https://facebook.github.io/create-react-app/docs/running-tests) مع افتراضات مفيده**. +- يتيح لك منفذى الاختبار مثل [Jest](https://jestjs.io/), [mocha](https://mochajs.org/), [ava](https://github.com/avajs/ava) كتابة مجموعات اختبار على هيئه JavaScript و تشغيلها كجزء من عملية التطوير الخاصة بك. بالاضافة الى ذلك يتم تشغيل مجموعات الاختبار كجزء من التكامل المستمر (CI). +- Jest متوافق على نطاق واسع مع مشاريع React, و دعم مميزات جديده مثل [الوحدات النمطية ](#moking-modules)و [العداد](#moking-timers) و دعم [`jsdom`](#mocking-a-rendering-surface`). **اذا كنت تستخدم Create React App اذن [Jest موجود بالفعل](https://facebook.github.io/create-react-app/docs/running-tests) مع تسطيب افتراضي مفيد**. - المكتبات مثل [mocha](https://mochajs.org/#running-mocha-in-the-browser) تعمل بشكل جيد في بيئات المتصفح الحقيقي ، ويمكن أن تساعد في الاختبارات التي تحتاجها بشكل صريح. -- تُستخدم الاختبارات من طرف إلى طرف لاختبار تدفقات أطول عبر عدة صفحات ، وتتطلب [إعداد مختلف](#end-to-end-tests-aka-e2e-tests). +- تُستخدم اختبارات End-to-End لاختبار تدفقات أطول عبر عدة صفحات، وتتطلب [إعدادات مختلفة](#end-to-end-tests-aka-e2e-tests). -### محاكاة سطح التصيير {#mocking-a-rendering-surface} +### محاكاة واجهة التصيير {#mocking-a-rendering-surface} تعمل الاختبارات غالبًا في بيئة دون الوصول إلى سطح التصيير الحقيقي مثل المستعرض. بالنسبة لهذه البيئات ، نوصي بمحاكاة مستعرض باستخدام [`jsdom`](https://github.com/jsdom/jsdom) ، وهو تطبيق متصفح خفيف الوزن يعمل داخل Node.js. @@ -39,7 +38,7 @@ prev: testing-recipes.html عند كتابة الاختبارات ، نود أن نحاكى الكود الخاص بنا الذى لا يحتوى على مكافئ له فى بيئة الاختبار الخاصة بنا (على سبيل المثال التحقق من حالة `navigator.onLin` داخل Node.js). يمكن للاختبارات أيضًا التجسس على بعض الوظائف ، ومراقبة كيفية تفاعل أجزاء أخرى من الاختبار معها. من المفيد عندئذ أن تكون قادرًا على محاكاة هذه الدوال باصدارات سهلة الاستخدام بشكل الانتقائى. -هذا مفيد بشكل خاص لجلب البيانات. من المفضل عادة استخدام البيانات "المزيفة" للاختبارات لتجنب البطء والضعف بسبب جلب نقاط نهاية API الحقيقية [(مثال) ](/docs/testing-recipes.html#data-fetching ). هذا يساعد على جعل الاختبارات يمكن التنبؤ بها. المكتبات مثل [Jest](https://jestjs.io/) و [sinon](https://sinonjs.org/)، من بين أمور أخرى ، تدعم محاكاه الدوال. بالنسبة للاختبارات الشاملة ، يمكن أن تكون محاكاة الشبكة أكثر صعوبة ، ولكن قد ترغب أيضًا في اختبار نقاط النهاية الحقيقية لواجهة برمجة التطبيقات فيها. +هذا مفيد بشكل خاص لجلب البيانات. من المفضل عادة استخدام البيانات "المزيفة" للاختبارات لتجنب البطء والضعف بسبب الجلب من نقاط الوصول النهائية لواجهة برمجة التطبيقات الحقيقية. [(مثال) ](/docs/testing-recipes.html#data-fetching ). هذا يساعد على جعل الاختبارات يمكن التنبؤ بها. مكتبات مثل [Jest](https://jestjs.io/) و [sinon](https://sinonjs.org/)، من بين أمور أخرى ، تدعم محاكاه الدوال. بالنسبة لاختبارات الـ end-to-end ، يمكن أن تكون محاكاة الشبكة أكثر صعوبة ، ولكن قد ترغب أيضًا في اختبار نقاط الوصول الحقيقية لواجهة برمجة التطبيقات فيها. ### محاكاه الوحدات {#mocking-modules} @@ -51,10 +50,10 @@ prev: testing-recipes.html قد تستخدم المكونات وظائف تستند إلى الوقت مثل `setTimeout` أو` setInterval` أو `Date.now`. في بيئات الاختبار ، قد يكون من المفيد الاستغناء عن هذه الوظائف مع البدائل التي تتيح لك "التقدم" يدويًا. هذا شيء عظيم للتأكد من أن اختباراتك تعمل بسرعة! الاختبارات التي تعتمد على العداد ستظل قائمة بالترتيب ، ولكن أسرع [(مثال)](/docs/testing-recipes.html#timers). معظم اطارات العمل ، بما في ذلك [Jest](https://jestjs.io/docs/en/timer-mocks) ، [sinon](https://sinonjs.org/releases/v7.3.2/fake-timers/) و [lolex](https://github.com/sinonjs/lolex) ، تتيح لك محاكاة العداد في اختباراتك. -في بعض الأحيان ، قد لا ترغب في محاكاة العداد. على سبيل المثال ، ربما تقوم باختبار رسم متحرك ، أو تتفاعل مع نقطة نهاية حساسة للتوقيت (like an API rate limiter). تتيح لك المكتبات التي بها محاكاه العداد تمكينها وتعطيلها على أساس كل اختبار / مجموعة ، بحيث يمكنك اختيار كيفية تشغيل هذه الاختبارات بشكل صريح. +في بعض الأحيان ، قد لا ترغب في محاكاة العداد. على سبيل المثال ، ربما تقوم باختبار رسم متحرك ، أو تتفاعل مع نقطة نهاية حساسة للتوقيت (مثل واجهة برمجة التطبيقات من نوع API rate limiter). تتيح لك المكتبات التي بها محاكاه العداد تمكينها وتعطيلها على أساس كل اختبار / مجموعة ، بحيث يمكنك اختيار كيفية تشغيل هذه الاختبارات بشكل صريح. -### اختبارات طرف الى طرف {#end-to-end-tests-aka-e2e-tests} +### اختبارات end-to-end {#end-to-end-tests-aka-e2e-tests} -تعد اختبارات طرف الى طرف مفيدة لاختبار سير عمل أطول ، خاصةً عندما تكون مهمة لنشاطك التجاري (مثل المدفوعات أو الاشتراكات). بالنسبة لهذه الاختبارات ، قد ترغب في اختبار كلٍّ من كيفية عرض المتصفح الحقيقي للتطبيق بأكمله ، وجلب البيانات من نقاط النهاية الحقيقية لواجهة برمجة التطبيقات ، واستخدام الجلسات وملفات تعريف الارتباط ، والتنقل بين الروابط المختلفة. قد ترغب أيضًا في تقديم تأكيدات ليس فقط في حالة DOM ، ولكن أيضًا على بيانات النسخ الاحتياطي (على سبيل المثال للتحقق من استمرار التحديثات في قاعدة البيانات). +تعد اختبارات end-to-end مفيدة لاختبار سير عمل أطول ، خاصةً عندما تكون مهمة لنشاطك التجاري (مثل المدفوعات أو الاشتراكات). بالنسبة لهذه الاختبارات ، قد ترغب في اختبار كلٍّ من كيفية عرض المتصفح الحقيقي للتطبيق بأكمله ، وجلب البيانات من نقاط الوصول الحقيقية لواجهة برمجة التطبيقات ، واستخدام الجلسات (session) وملفات تعريف الارتباط (cookies)، والتنقل بين الروابط المختلفة. قد ترغب أيضًا في تقديم تأكيدات ليس فقط في حالة DOM ، ولكن أيضًا على بيانات النسخ الاحتياطي (على سبيل المثال للتحقق من استمرار التحديثات في قاعدة البيانات). -في هذا السيناريو ، يمكنك استخدام إطار عمل مثل [Cypress](https://www.cypress.io/) أو مكتبة مثل [puppeteer](https://github.com/GoogleChrome/puppeteer) حتى تتمكن من التنقل بين طرق متعددة والتأكيد على الآثار الجانبية ليس فقط في المتصفح ، ولكن يحتمل أن يكون على الواجهة الخلفية أيضًا. +في هذا السيناريو ، يمكنك استخدام إطار عمل مثل [Cypress](https://www.cypress.io/) أو مكتبة مثل [puppeteer](https://github.com/GoogleChrome/puppeteer) حتى تتمكن من التنقل و تصفح بين نقاط الوصول والطرق (routes) المتعددة والتأكيد على الآثار الجانبية ليس فقط في المتصفح ، ولكن يحتمل أن يكون على الواجهة الخلفية (back-end) أيضًا. From 6818581d4cfff7de16701cc91913d77dc5964782 Mon Sep 17 00:00:00 2001 From: Mohamed Abdel Nasser Date: Fri, 29 Nov 2019 12:32:53 +0200 Subject: [PATCH 4/5] modify testing envs translate --- content/docs/testing-environments.md | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index a38d9639f..ee67a9ead 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -9,7 +9,6 @@ prev: testing-recipes.html يتناول هذا المستند العوامل التي يمكن أن تؤثر على بيئتك والتوصيات المتعلقة ببعض السيناريوهات. - ### منفذي الاختبار {#test-runners} - يتيح لك منفذى الاختبار مثل [Jest](https://jestjs.io/), [mocha](https://mochajs.org/), [ava](https://github.com/avajs/ava) كتابة مجموعات اختبار على هيئه JavaScript و تشغيلها كجزء من عملية التطوير الخاصة بك. بالاضافة الى ذلك يتم تشغيل مجموعات الاختبار كجزء من التكامل المستمر (CI). @@ -19,24 +18,23 @@ prev: testing-recipes.html ### محاكاة واجهة التصيير {#mocking-a-rendering-surface} -تعمل الاختبارات غالبًا في بيئة دون الوصول إلى سطح التصيير الحقيقي مثل المستعرض. بالنسبة لهذه البيئات ، نوصي بمحاكاة مستعرض باستخدام [`jsdom`](https://github.com/jsdom/jsdom) ، وهو تطبيق متصفح خفيف الوزن يعمل داخل Node.js. - -في معظم الحالات ، يتصرف jsdom كالمتصفح العادي ، لكن ليس به ميزات مثل [layout and navigation ](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform). لا يزال هذا مفيدًا لمعظم اختبارات المكونات المستندة إلى الويب ، لأنه يعمل بشكل أسرع من الاضطرار إلى بدء تشغيل مستعرض لكل اختبار. يتم تشغيله أيضًا في نفس عملية الاختبارات الخاصة بك ، حتى تتمكن من كتابة التعليمات البرمجية لفحصها وتأكيدها على DOM. +تعمل الاختبارات غالبًا في بيئة دون الوصول إلى واجهة التصيير الحقيقية مثل المتصفح. بالنسبة لهذه البيئات ، نوصي بمحاكاة متصفح باستخدام [`jsdom`](https://github.com/jsdom/jsdom) ، وهو تطبيق متصفح خفيف الوزن يعمل داخل Node.js. -تمامًا كما في المتصفح الحقيقي ، تتيح لنا jsdom تصميم تفاعلات المستخدم ؛ يمكن للاختبارات إرسال الأحداث على عقد DOM ، ثم مراقبة الآثار الجانبية لهذه الإجراءات والتأكيد عليها [(مثال)](/docs/testing-recipes.html#events). +في معظم الحالات ، يتصرف jsdom كالمتصفح العادي ، لكن ليس به ميزات مثل [layout و navigation](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform). لا يزال هذا مفيدًا لمعظم اختبارات المكونات المستندة إلى الويب ، لأنه يعمل بشكل أسرع من إعادة بدء تشغيل متصفح لكل اختبار. يتم تشغيله أيضًا في نفس عملية الاختبارات الخاصة بك ، حتى تتمكن من كتابة التعليمات البرمجية لفحصها وتأكيدها على DOM. +تمامًا كما في المتصفح الحقيقي ، تتيح لنا jsdom تصميم تفاعلات المستخدم ؛ يمكن للاختبارات إرسال الأحداث في عقدات DOM، ثم مراقبة الآثار الجانبية لهذه الإجراءات والتأكيد عليها [(مثال)](/docs/testing-recipes.html#events). -يمكن كتابة جزء كبير من اختبارات واجهة المستخدم باستخدام الإعداد أعلاه: استخدام Jest كمنفذ للاختبار ، يتم تصييره إلى jsdom ، مع تفاعلات المستخدم المحددة كسلسلة من أحداث المتصفح ، مدعومًا بـ `act ()` helper [(مثال)](/docs/testing-recipes.html). على سبيل المثال ، تتم كتابة الكثير من اختبارات React الخاصة مع هذه المجموعة. +يمكن كتابة جزء كبير من اختبارات واجهة المستخدم باستخدام الإعداد أعلاه: استخدام Jest كمنفذ للاختبار ، يتم تصييره إلى jsdom ، مع تفاعلات المستخدم المحددة كسلسلة من أحداث المتصفح ، مدعومًا بـالمساعد `act ()` [(مثال)](/docs/testing-recipes.html). على سبيل المثال ، تتم كتابة الكثير من اختبارات React الخاصة مع هذه التركيبة. -إذا كنت تكتب مكتبة تختبر في الغالب السلوك الخاص بالمتصفح ، وتتطلب سلوك المستعرض الأصلي مثل التخطيط أو المدخلات الحقيقية ، يمكنك استخدام إطار عمل مثل [mocha.](https://mochajs.org/) +إذا كنت تكتب مكتبة تختبر في الغالب السلوك الخاص بالمتصفح ، وتتطلب سلوك المتصفح الأصلي مثل الـ layout أو حقول الإدخال الحقيقية ، يمكنك استخدام إطار عمل مثل [mocha.](https://mochajs.org/) -في بيئة لا يمكنك فيها محاكاة DOM (على سبيل المثال ، اختبار مكونات React Native على Node.js) ، يمكنك استخدام [مساعدي محاكاة الأحداث](https://reactjs.org/docs/test-utils.html#simulate) لمحاكاة التفاعلات مع العناصر. بالتناوب ، يمكنك استخدام "fireEvent" المساعد من [`@ testing-library / react-native`](https://testing-library.com/docs/native-testing-library). +في بيئة لا يمكنك فيها محاكاة DOM (على سبيل المثال ، اختبار مكونات React Native على Node.js) ، يمكنك استخدام [مساعدي محاكاة الأحداث](https://reactjs.org/docs/test-utils.html#simulate) لمحاكاة التفاعلات مع العناصر. بالتناوب ، يمكنك استخدام `fireEvent` المساعد من [`@ testing-library / react-native`](https://testing-library.com/docs/native-testing-library). -اطارات العمل مثل [Cypress](https://www.cypress.io/) و [puppeteer](https://github.com/GoogleChrome/puppeteer) و [webdriver](https://www.seleniumhq.org/projects / webdriver /) مفيدة لتشغيل [end-to-end test ](#end-to-end-tests-aka-e2e-tests). +اطارات عمل مثل [Cypress](https://www.cypress.io/) و [puppeteer](https://github.com/GoogleChrome/puppeteer) و [webdriver](https://www.seleniumhq.org/projects / webdriver /) مفيدة لتشغيل [اختيبارات end-to-end](#end-to-end-tests-aka-e2e-tests). ### محاكاة الدوال {#mocking-functions} -عند كتابة الاختبارات ، نود أن نحاكى الكود الخاص بنا الذى لا يحتوى على مكافئ له فى بيئة الاختبار الخاصة بنا (على سبيل المثال التحقق من حالة `navigator.onLin` داخل Node.js). يمكن للاختبارات أيضًا التجسس على بعض الوظائف ، ومراقبة كيفية تفاعل أجزاء أخرى من الاختبار معها. من المفيد عندئذ أن تكون قادرًا على محاكاة هذه الدوال باصدارات سهلة الاستخدام بشكل الانتقائى. +عند كتابة الاختبارات ، نود أن نحاكى الكود الخاص بنا الذى لا يحتوى على مُمَاثل له فى بيئة الاختبار الخاصة بنا (على سبيل المثال التحقق من حالة `navigator.onLin` داخل Node.js). يمكن للاختبارات أيضًا التجسس على بعض الدوال، ومراقبة كيفية تفاعل أجزاء أخرى من الاختبار معها. من المفيد عندئذ أن تكون قادرًا على محاكاة هذه الدوال باصدارات سهلة الاستخدام بشكل الانتقائى. هذا مفيد بشكل خاص لجلب البيانات. من المفضل عادة استخدام البيانات "المزيفة" للاختبارات لتجنب البطء والضعف بسبب الجلب من نقاط الوصول النهائية لواجهة برمجة التطبيقات الحقيقية. [(مثال) ](/docs/testing-recipes.html#data-fetching ). هذا يساعد على جعل الاختبارات يمكن التنبؤ بها. مكتبات مثل [Jest](https://jestjs.io/) و [sinon](https://sinonjs.org/)، من بين أمور أخرى ، تدعم محاكاه الدوال. بالنسبة لاختبارات الـ end-to-end ، يمكن أن تكون محاكاة الشبكة أكثر صعوبة ، ولكن قد ترغب أيضًا في اختبار نقاط الوصول الحقيقية لواجهة برمجة التطبيقات فيها. @@ -46,7 +44,7 @@ prev: testing-recipes.html على Node.js ، يقوم منفذى الاختبارات مثل Jest [بدعم محاكاة الوحدات](https://jestjs.io/docs/en/manual-mocks). يمكنك أيضًا استخدام مكتبات مثل [`mock-require`](https://www.npmjs.com/package/mock-require). -### محاكاة العداد {#mocking-timers} +### محاكاة المؤقتات {#mocking-timers} قد تستخدم المكونات وظائف تستند إلى الوقت مثل `setTimeout` أو` setInterval` أو `Date.now`. في بيئات الاختبار ، قد يكون من المفيد الاستغناء عن هذه الوظائف مع البدائل التي تتيح لك "التقدم" يدويًا. هذا شيء عظيم للتأكد من أن اختباراتك تعمل بسرعة! الاختبارات التي تعتمد على العداد ستظل قائمة بالترتيب ، ولكن أسرع [(مثال)](/docs/testing-recipes.html#timers). معظم اطارات العمل ، بما في ذلك [Jest](https://jestjs.io/docs/en/timer-mocks) ، [sinon](https://sinonjs.org/releases/v7.3.2/fake-timers/) و [lolex](https://github.com/sinonjs/lolex) ، تتيح لك محاكاة العداد في اختباراتك. From 5cdf49bb7c35d5dd695330e711a58a086ef9fa0d Mon Sep 17 00:00:00 2001 From: Mohamed Abdel Nasser Date: Fri, 29 Nov 2019 22:34:55 +0200 Subject: [PATCH 5/5] remove spaces & improve translation --- content/docs/testing-environments.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index ee67a9ead..10ff205c2 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -11,14 +11,14 @@ prev: testing-recipes.html ### منفذي الاختبار {#test-runners} -- يتيح لك منفذى الاختبار مثل [Jest](https://jestjs.io/), [mocha](https://mochajs.org/), [ava](https://github.com/avajs/ava) كتابة مجموعات اختبار على هيئه JavaScript و تشغيلها كجزء من عملية التطوير الخاصة بك. بالاضافة الى ذلك يتم تشغيل مجموعات الاختبار كجزء من التكامل المستمر (CI). +- يتيح لك منفذي الاختبار مثل [Jest](https://jestjs.io/), [mocha](https://mochajs.org/), [ava](https://github.com/avajs/ava) كتابة مجموعات اختبار على هيئه JavaScript و تشغيلها كجزء من عملية التطوير الخاصة بك. بالاضافة الى ذلك يتم تشغيل مجموعات الاختبار كجزء من التكامل المستمر (CI). - Jest متوافق على نطاق واسع مع مشاريع React, و دعم مميزات جديده مثل [الوحدات النمطية ](#moking-modules)و [العداد](#moking-timers) و دعم [`jsdom`](#mocking-a-rendering-surface`). **اذا كنت تستخدم Create React App اذن [Jest موجود بالفعل](https://facebook.github.io/create-react-app/docs/running-tests) مع تسطيب افتراضي مفيد**. -- المكتبات مثل [mocha](https://mochajs.org/#running-mocha-in-the-browser) تعمل بشكل جيد في بيئات المتصفح الحقيقي ، ويمكن أن تساعد في الاختبارات التي تحتاجها بشكل صريح. +- المكتبات مثل [mocha](https://mochajs.org/#running-mocha-in-the-browser) تعمل بشكل جيد في بيئات المتصفح الحقيقي، ويمكن أن تساعد في الاختبارات التي تحتاجها بشكل صريح. - تُستخدم اختبارات End-to-End لاختبار تدفقات أطول عبر عدة صفحات، وتتطلب [إعدادات مختلفة](#end-to-end-tests-aka-e2e-tests). ### محاكاة واجهة التصيير {#mocking-a-rendering-surface} -تعمل الاختبارات غالبًا في بيئة دون الوصول إلى واجهة التصيير الحقيقية مثل المتصفح. بالنسبة لهذه البيئات ، نوصي بمحاكاة متصفح باستخدام [`jsdom`](https://github.com/jsdom/jsdom) ، وهو تطبيق متصفح خفيف الوزن يعمل داخل Node.js. +تعمل الاختبارات غالبًا في بيئة دون الوصول إلى واجهة التصيير الحقيقية مثل المتصفح. بالنسبة لهذه البيئات، نوصي بمحاكاة متصفح باستخدام [`jsdom`](https://github.com/jsdom/jsdom) ، وهو تطبيق متصفح خفيف الوزن يعمل داخل Node.js. في معظم الحالات ، يتصرف jsdom كالمتصفح العادي ، لكن ليس به ميزات مثل [layout و navigation](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform). لا يزال هذا مفيدًا لمعظم اختبارات المكونات المستندة إلى الويب ، لأنه يعمل بشكل أسرع من إعادة بدء تشغيل متصفح لكل اختبار. يتم تشغيله أيضًا في نفس عملية الاختبارات الخاصة بك ، حتى تتمكن من كتابة التعليمات البرمجية لفحصها وتأكيدها على DOM. @@ -28,13 +28,13 @@ prev: testing-recipes.html إذا كنت تكتب مكتبة تختبر في الغالب السلوك الخاص بالمتصفح ، وتتطلب سلوك المتصفح الأصلي مثل الـ layout أو حقول الإدخال الحقيقية ، يمكنك استخدام إطار عمل مثل [mocha.](https://mochajs.org/) -في بيئة لا يمكنك فيها محاكاة DOM (على سبيل المثال ، اختبار مكونات React Native على Node.js) ، يمكنك استخدام [مساعدي محاكاة الأحداث](https://reactjs.org/docs/test-utils.html#simulate) لمحاكاة التفاعلات مع العناصر. بالتناوب ، يمكنك استخدام `fireEvent` المساعد من [`@ testing-library / react-native`](https://testing-library.com/docs/native-testing-library). +في بيئة لا يمكنك فيها محاكاة DOM (على سبيل المثال ، اختبار مكونات React Native على Node.js) ، يمكنك استخدام [مساعدي محاكاة الأحداث](https://reactjs.org/docs/test-utils.html#simulate) لمحاكاة التفاعلات مع العناصر. بالتناوب ، يمكنك استخدام `fireEvent` المساعد من [`@ testing-library/react-native`](https://testing-library.com/docs/native-testing-library). -اطارات عمل مثل [Cypress](https://www.cypress.io/) و [puppeteer](https://github.com/GoogleChrome/puppeteer) و [webdriver](https://www.seleniumhq.org/projects / webdriver /) مفيدة لتشغيل [اختيبارات end-to-end](#end-to-end-tests-aka-e2e-tests). +اطارات عمل مثل [Cypress](https://www.cypress.io/) و [puppeteer](https://github.com/GoogleChrome/puppeteer) و [webdriver](https://www.seleniumhq.org/projects/webdriver /) مفيدة لتشغيل [اختيبارات end-to-end](#end-to-end-tests-aka-e2e-tests). ### محاكاة الدوال {#mocking-functions} -عند كتابة الاختبارات ، نود أن نحاكى الكود الخاص بنا الذى لا يحتوى على مُمَاثل له فى بيئة الاختبار الخاصة بنا (على سبيل المثال التحقق من حالة `navigator.onLin` داخل Node.js). يمكن للاختبارات أيضًا التجسس على بعض الدوال، ومراقبة كيفية تفاعل أجزاء أخرى من الاختبار معها. من المفيد عندئذ أن تكون قادرًا على محاكاة هذه الدوال باصدارات سهلة الاستخدام بشكل الانتقائى. +عند كتابة الاختبارات ، نود أن نحاكى الكود الخاص بنا الذى لا يحتوى على مُمَاثل له فى بيئة الاختبار الخاصة بنا (على سبيل المثال التحقق من حالة `navigator.onLin` داخل Node.js). يمكن للاختبارات أيضًا التجسس على بعض الدوال، ومراقبة كيفية تفاعل أجزاء أخرى من الاختبار معها. من المفيد عندئذ أن تكون قادرًا على محاكاة هذه الدوال باصدارات سهلة الاستخدام بشكل الانتقائى. هذا مفيد بشكل خاص لجلب البيانات. من المفضل عادة استخدام البيانات "المزيفة" للاختبارات لتجنب البطء والضعف بسبب الجلب من نقاط الوصول النهائية لواجهة برمجة التطبيقات الحقيقية. [(مثال) ](/docs/testing-recipes.html#data-fetching ). هذا يساعد على جعل الاختبارات يمكن التنبؤ بها. مكتبات مثل [Jest](https://jestjs.io/) و [sinon](https://sinonjs.org/)، من بين أمور أخرى ، تدعم محاكاه الدوال. بالنسبة لاختبارات الـ end-to-end ، يمكن أن تكون محاكاة الشبكة أكثر صعوبة ، ولكن قد ترغب أيضًا في اختبار نقاط الوصول الحقيقية لواجهة برمجة التطبيقات فيها. @@ -48,7 +48,7 @@ prev: testing-recipes.html قد تستخدم المكونات وظائف تستند إلى الوقت مثل `setTimeout` أو` setInterval` أو `Date.now`. في بيئات الاختبار ، قد يكون من المفيد الاستغناء عن هذه الوظائف مع البدائل التي تتيح لك "التقدم" يدويًا. هذا شيء عظيم للتأكد من أن اختباراتك تعمل بسرعة! الاختبارات التي تعتمد على العداد ستظل قائمة بالترتيب ، ولكن أسرع [(مثال)](/docs/testing-recipes.html#timers). معظم اطارات العمل ، بما في ذلك [Jest](https://jestjs.io/docs/en/timer-mocks) ، [sinon](https://sinonjs.org/releases/v7.3.2/fake-timers/) و [lolex](https://github.com/sinonjs/lolex) ، تتيح لك محاكاة العداد في اختباراتك. -في بعض الأحيان ، قد لا ترغب في محاكاة العداد. على سبيل المثال ، ربما تقوم باختبار رسم متحرك ، أو تتفاعل مع نقطة نهاية حساسة للتوقيت (مثل واجهة برمجة التطبيقات من نوع API rate limiter). تتيح لك المكتبات التي بها محاكاه العداد تمكينها وتعطيلها على أساس كل اختبار / مجموعة ، بحيث يمكنك اختيار كيفية تشغيل هذه الاختبارات بشكل صريح. +في بعض الأحيان ، قد لا ترغب في محاكاة العداد. على سبيل المثال ، ربما تقوم باختبار رسم متحرك ، أو تتفاعل مع نقطة نهاية حساسة للتوقيت (مثل واجهة برمجة التطبيقات من نوع API rate limiter). تتيح لك المكتبات التي بها محاكاه العداد تمكينها وتعطيلها على أساس كل اختبار/مجموعة ، بحيث يمكنك اختيار كيفية تشغيل هذه الاختبارات بشكل صريح. ### اختبارات end-to-end {#end-to-end-tests-aka-e2e-tests}