Translate Testing Environment

content/docs/testing-environments.md

@@ -1,58 +1,58 @@
 ---
 id: testing-environments
-title: Testing Environments
+title: Test Etmə Mühitləri
 permalink: docs/testing-environments.html
 prev: testing-recipes.html
 ---
 
 <!-- This document is intended for folks who are comfortable with JavaScript, and have probably written tests with it. It acts as a reference for the differences in testing environments for React components, and how those differences affect the tests that they write. This document also assumes a slant towards web-based react-dom components, but has notes for other renderers. -->
 
-This document goes through the factors that can affect your environment and recommendations for some scenarios.
+Bu sənəddə mühitə təsir edə bilən amillərdən və bəzi ssenarilər üçün tövsiyyələrdən danışacağıq.
 
-### Test runners {#test-runners}
+### Test icra edicilər {#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.
+[Jest](https://jestjs.io/), [mocha](https://mochajs.org/) və [ava](https://github.com/avajs/ava) kimi test işləyiciləri test dəstlərinin sadə JavaScript kimi yazılmasına və bu testləri development prosesinin bir hissəsi kimi icra edilməsinə imkan yaradır. Əlavə olaraq, test dəstləri davamlı inteqrasiyanın bir hissəsi kimi icra oluna bilir.
 
-- 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 test icra edicisi React layihələri ilə çox uyğundur. Bu alət ilə [modul](#mocking-modules) və [taymerlərin](#mocking-timers) mok edilməsi və [`jsdom`](#mocking-a-rendering-surface) kimi xüsusiyyətləri dəstəkləyir. **Create React App işlətdikdə, [heç bir konfiqurasiyasız](https://facebook.github.io/create-react-app/docs/running-tests) Jest-dən istifadə edə bilərsiniz.**
+- [mocha](https://mochajs.org/#running-mocha-in-the-browser) kimi kitabxanalar real brauzer mühitlərində yaxşı işləyir. Bu kitabxanalar əsl brauzer mühitindən asılı olan testlər üçün faydalı ola bilər.
+- Bir neçə səhifələr arasında olan axını test etmək üçün end-to-end testlər işlənir. Bu testlər üçün [fərqli quraşdırma](#end-to-end-tests-aka-e2e-tests) lazımdır.
 
-### Mocking a rendering surface {#mocking-a-rendering-surface}
+### Render sahəsinin mok edilməsi {#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.
+Adətən, testlər brauzer kimi real render sahəsi olmayan mühitlərdə icra olunurlar. Bu mühitlər üçün brauzeri [`jsdom`](https://github.com/jsdom/jsdom) (Node.js-də işləyən yüngül brauzer tətbiqi) ilə simulyasiya etməyi tövsiyyə edirik.
 
-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.
+Bir çox halda, jsdom normal brauzer kimi işləyir. Lakin, bu alətin [şablon və naviqasiya kimi](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform) xüsusiyyətləri yoxdur. Buna baxmayaraq, bu alət ilə hər test üçün yeni brauzerin açılmasının lazım olmadığından əksər veb əsaslı komponentlərin test edilməsi faydalıdır. Əlavə olaraq, bu alətin testlər ilə eyni sistem prosesində işlədiyindən render olunan DOM-u yoxlayıb təsdiq edə bilərsiniz.
 
-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 [<small>(example)</small>](/docs/testing-recipes.html#events).
+Real brauzerdə olduğu kimi jsdom ilə istifadəçi interaksiyalarını yoxlamaq mümkündür: testlər ilə hadisələri DOM nodlara göndərib bu hadisələrdən yaranan yan effektləri təsdiq edə bilirik [<small>(nümunə)</small>](/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 [<small>(example)</small>](/docs/testing-recipes.html). For example, a lot of React's own tests are written with this combination.
+UI testlərin böyük hissəsi yuxarıdakı formada yazıla bilər: Jest icra edicisindən istifadə edib `act()` köməkçisindən [<small>(nümunə)</small>](/docs/testing-recipes.html) istifadə edərək istifadəçi interaksiyalarını brauzer hadisələri kimi göndərib UI-ı jsdom-a render etmək.
 
-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/)
+Brauzer spesifik davranışları test edən və şablon və real daxil olmalar kimi nativ brauzer davranışlarından asılı olan kitabxana yazdıqda [mocha](https://mochajs.org/) kimi freymvorkdan istifadə edə bilərsiniz.
 
-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).
+DOM-un simulyasiya _oluna bilmədiyi_ mühitdə (məsələn, Node.js-dən React Native komponentləri test etdikdə) işlədikdə elementlər ilə interaksiyaları simulyasiya etmək üçün [hadisə simulyasiya köməkçilərindən](https://reactjs.org/docs/test-utils.html#simulate) istifadə edə bilərsiniz. Alternativ olaraq, [`@testing-library/react-native`](https://testing-library.com/docs/native-testing-library) kitabxanasında olan `fireEvent` köməkçisindən istifadə edə bilərsiniz.
 
-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).
+[End-to-end testləri](#end-to-end-tests-aka-e2e-tests) icra etmək üçün [Cypress](https://www.cypress.io/), [puppeteer](https://github.com/GoogleChrome/puppeteer) və [webdriver](https://www.seleniumhq.org/projects/webdriver/) alətləri faydalıdır.
 
-### Mocking functions {#mocking-functions}
+### Funksiyaların mok edilməsi {#mocking-functions}
 
-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.
+Testlər yazdıqda test mühitində ekvivalenti olmayan kod parçalarını mok etmək lazım ola bilər (məsələn, Node.js-də `navigator.onLine` statusu yoxlamaq kimi). Testlər ilə bəzi funksiyaları "spy" edib testin digər hissələrinin bu funksiyalar ilə necə işlədiyini müşahidə etmək mümkündür. Bu funksiyaları mok edərək test mühitinə uyğun versiyalarını düzəltmək faydalıdır.
 
-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 [<small>(example)</small>](/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.
+Bu, xüsusilə məlumat yüklənməsi üçün faydalıdır. Real API nöqtələrindən məlumatların yüklənməsi testləri yavaşladır deyə testləri "saxta" məlumat ilə yazmaq daha sərfəlidir [<small>(nümunə)</small>](/docs/testing-recipes.html#data-fetching). Əlavə olaraq, saxta məlumat ilə testlər daha proqnozlaşdırıla biləndir. [Jest](https://jestjs.io/) və [sinon](https://sinonjs.org/) kimi kitabxanalar ilə funksiyaları mok etmək mümkündür. End-to-end testlərdə şəbəkəni mok etmək daha çətin olur. Lakin, bu testlərdə real API nöqtələrindən istifadə etmək daha faydalıdır.
 
-### Mocking modules {#mocking-modules}
+### Modulların mok edilməsi {#mocking-modules}
 
-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 [<small>(example)</small>](/docs/testing-recipes.html#mocking-modules).
+Bəzi komponentlər test mühitində yaxşı işləməyən modullardan istifadə edə bilər və ya testlər üçün vacib olmaya bilər. Bu modulları uyğun əvəzetmələr ilə mok etmək faydalı ola bilər [<small>(nümunə)</small>](/docs/testing-recipes.html#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).
+Node.js-də Jest kimi icra edicilərdə [modulların mok edilməsi dəstəklənir](https://jestjs.io/docs/en/manual-mocks). Siz, həmçinin [`mock-require`](https://www.npmjs.com/package/mock-require) kimi kitabxanalardan istifadə edə bilərsiniz.
 
 ### Mocking timers {#mocking-timers}
 
-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 [<small>(example)</small>](/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.
+Komponentlər `setTimeout`, `setInterval` və ya `Date.now` kimi funksiyalardan istifadə edə bilərlər. Test mühitlərində bu funksiyaları, zamanı əl ilə "qabağa çəkə bilən" əvəzetmələri ilə mok etmək faydalı ola bilər. Bu, testlərin tez işləməsinə imkan yaradır! Taymerlərdən asılı olan testlər yeni sıra ilə daha tez həll olunacaq [<small>(nümunə)</small>](/docs/testing-recipes.html#timers). [Jest](https://jestjs.io/docs/en/timer-mocks), [sinon](https://sinonjs.org/releases/v7.3.2/fake-timers/) və [lolex](https://github.com/sinonjs/lolex) kimi freymvorklar taymerləri mok etməyə imkan yaradır.
 
-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.
+Bəzən, taymerləri mok etmək lazım olmaya bilər. Məsələn, bəzən animasiyaları və ya vaxta həssas olan (API sürəti məhdudlaşdırıcısı kimi) API nöqtələri ilə interaksiyalar test etikdə taymerləri mok etmək faydalı deyil. Taymerləri mok edən kitabxanalar, mokları hər test/test dəsti üçün aktivləşdirməyə və ya ləğv etməyə imkan yaradır. Bu səbəbdən, siz hər testin necə işləyəcəyini seçə bilərsiniz.
 
-### End-to-end tests {#end-to-end-tests-aka-e2e-tests}
+### End-to-end testlər {#end-to-end-tests-aka-e2e-tests}
 
-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).
+Biznesiniz üçün kritiki olan uzun axınları (məsələn, registrasiya və ya ödəmələr kimi) test etmək üçün End-to-end testlər faydalıdır. Bu testlərdə applikasiyanın brauzerdə render edilməsi, məlumatların real API-dan yüklənməsi, sessiya və kukilərdən istifa, və linklər arasında naviqasiyalar test edilir. Əlavə olaraq, DOM vəziyyəti üzərində iddialardan əlavə, gələn məlumat (məsələn, yeniliklərin database-ə yazılmasının test edilməsi) da test edilir.
 
-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.
+Belə ssenarilər üçün kimi [Cypress](https://www.cypress.io/) freymvorkdan və ya [puppeteer](https://github.com/GoogleChrome/puppeteer) kimi kitabxanalardan istifadə edərək fərqli linklərə naviqasiya edib yalnız brauzer yan effektlərini yox, backend yan effektlərini də test edə bilərsiniz.