-
Notifications
You must be signed in to change notification settings - Fork 52
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Translate 'Testing Overview' page (#124)
- Loading branch information
1 parent
8cac5b1
commit 9bbad54
Showing
1 changed file
with
18 additions
and
19 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,40 +1,39 @@ | ||
--- | ||
id: testing | ||
title: Testing Overview | ||
title: Ogólne informacje | ||
permalink: docs/testing.html | ||
redirect_from: | ||
- "community/testing.html" | ||
next: testing-recipes.html | ||
--- | ||
|
||
You can test React components similar to testing other JavaScript code. | ||
Komponenty reactowe można testować podobnie jak pozostały kod javascriptowy. | ||
|
||
There are a few ways to test React components. Broadly, they divide into two categories: | ||
Istnieje kilka sposobów na przetestowanie komponentów reactowych. W dużym uproszczeniu, dzielą się one na dwie kategorie: | ||
|
||
* **Rendering component trees** in a simplified test environment and asserting on their output. | ||
* **Running a complete app** in a realistic browser environment (also known as “end-to-end” tests). | ||
* **Renderowanie drzew komponentów** w uproszczonym środowisku testowym oraz sprawdzanie wyniku renderowania. | ||
* **Uruchamianie pełnej aplikacji** w realistycznym środowisku przeglądarkowym (znane również jako testy "end-to-end"). | ||
|
||
This documentation section focuses on testing strategies for the first case. While full end-to-end tests can be very useful to prevent regressions to important workflows, such tests are not concerned with React components in particular, and are out of scope of this section. | ||
Ten rozdział dokumentacji skupia się na strategiach testowania w pierwszy sposób. Mimo iż pełne testy "end-to-end" często zapobiegają regresji w kluczowych ścieżkach aplikacji, nie przywiązują one zbyt dużej uwagi do komponentów reactowych. Z tego powodu pominęliśmy je w tej sekcji. | ||
|
||
### Tradeoffs {#tradeoffs} | ||
### Kompromisy {#tradeoffs} | ||
|
||
Podczas wybierania narzędzia testującego warto zastanowić się na kilkoma decyzjami: | ||
|
||
When choosing testing tools, it is worth considering a few tradeoffs: | ||
* **Szybkość iteracji czy realistyczne środowisko:** Niektóre narzędzia oferują szybkie sprzężenie zwrotne pomiędzy wprowadzeniem zmiany a otrzymaniem wyniku, lecz nie odwzorowują dokładnie zachowania przeglądarki. Inne z kolei używają realistycznego środowiska przeglądarkowego, lecz zmniejszają szybkość iteracji i działają topornie na serwerach CI (ang. *Continuous Integration*). | ||
* **Ile powinniśmy zamockować:** W przypadku komponentów, granica pomiędzy testami "jednostkowymi" a "integracyjnymi" może się zacierać. Kiedy testujesz formularz, czy testy powinny także sprawdzić działanie znajdujących się w nim przycisków? Czy może przycisk powinien mieć dedykowany zestaw testowy? Czy zmiany w kodzie przycisku powinny wpływać na testy formularza? | ||
|
||
* **Iteration speed vs Realistic environment:** Some tools offer a very quick feedback loop between making a change and seeing the result, but don't model the browser behavior precisely. Other tools might use a real browser environment, but reduce the iteration speed and are flakier on a continuous integration server. | ||
* **How much to mock:** With components, the distinction between a "unit" and "integration" test can be blurry. If you're testing a form, should its test also test the buttons inside of it? Or should a button component have its own test suite? Should refactoring a button ever break the form test? | ||
Do każdego zespołu i każdego produktu pasują inne odpowiedzi na powyższe pytania. | ||
|
||
Different answers may work for different teams and products. | ||
### Zalecane narzędzia {#tools} | ||
|
||
### Recommended Tools {#tools} | ||
**[Jest](https://facebook.github.io/jest/)** to javascriptowy "test runner" (pol. *narzędzie uruchamiające testy*), które pozwala uzyskać dostęp do DOM dzięki paczce [`jsdom`](/docs/testing-environments.html#mocking-a-rendering-surface). Mimo iż `jsdom` tylko w przybliżeniu działa jak prawdziwa przeglądarka, zwykle wystarcza do przetestowania komponentów reactowych. Biblioteka Jest gwarantuje szybką iterowalność połączoną z praktycznymi funkcjonalnościami, jak mockowanie [modułów](/docs/testing-environments.html#mocking-modules) czy [timerów](/docs/testing-environments.html#mocking-timers). Dzięki temu masz większą kontrolę nad tym, jak wykonywany jest twój kod. | ||
|
||
**[Jest](https://facebook.github.io/jest/)** is a JavaScript test runner that lets you access the DOM via [`jsdom`](/docs/testing-environments.html#mocking-a-rendering-surface). While jsdom is only an approximation of how the browser works, it is often good enough for testing React components. Jest provides a great iteration speed combined with powerful features like mocking [modules](/docs/testing-environments.html#mocking-modules) and [timers](/docs/testing-environments.html#mocking-timers) so you can have more control over how the code executes. | ||
**[React Testing Library](https://testing-library.com/react)** jest zestawem funkcji pomocniczych, które pozwalają nad testowanie komponentów reactowych bez polegania na ich szczegółach implementacyjnych (ang. *implementation details*). Takie podejście sprawia, że refactoring kodu staje się niezwykle prosty, a także "popycha" cię w kierunku dobrych praktyk dotyczących dostępności (ang. *accessibility*). Mimo iż ta biblioteka nie umożliwia "płytkiego" renderowania (ang. *shallow rendering*) komponentów bez ich potomków, doskonale sprawdza się w połączeniu z Jestem i jego funkcjonalnością [mockowania modułów](/docs/testing-recipes.html#mocking-modules). | ||
|
||
**[React Testing Library](https://testing-library.com/react)** is a set of helpers that let you test React components without relying on their implementation details. This approach makes refactoring a breeze and also nudges you towards best practices for accessibility. Although it doesn't provide a way to "shallowly" render a component without its children, a test runner like Jest lets you do this by [mocking](/docs/testing-recipes.html#mocking-modules). | ||
### Dowiedz się więcej {#learn-more} | ||
|
||
### Learn More {#learn-more} | ||
Ten rozdział został podzielony na dwie części: | ||
|
||
This section is divided in two pages: | ||
|
||
- [Recipes](/docs/testing-recipes.html): Common patterns when writing tests for React components. | ||
- [Environments](/docs/testing-environments.html): What to consider when setting up a testing environment for React components. | ||
- [Przykłady i dobre praktyki](/docs/testing-recipes.html): Wzorce często spotykane przy testowaniu komponentów reactowych. | ||
- [Środowiska](/docs/testing-environments.html): Na co należy zwrócić uwagę podczas zestawiania środowiska testującego dla komponentów reactowych. |