From a694db61b3c4b8e960f177dc69c9f3e2bf8391d4 Mon Sep 17 00:00:00 2001 From: Jakub Drozdek Date: Mon, 26 Aug 2019 23:51:49 +0200 Subject: [PATCH 1/2] Translate 'Testing Overview' page --- content/docs/testing.md | 37 ++++++++++++++++++------------------- 1 file changed, 18 insertions(+), 19 deletions(-) diff --git a/content/docs/testing.md b/content/docs/testing.md index 5bccd1fc4..9d40a9281 100644 --- a/content/docs/testing.md +++ b/content/docs/testing.md @@ -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. Ogólnie rzecz biorąc, 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 oproszczonym ś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 są często bardzo pomocne przy zapobieganiu regresji w kluczowych ścieżkach aplikacji, nie zwracają one uwagi na komponenty reactowe. 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 kwestiami: -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 testowania komponentów reactowych. Jest gwarantuje szybką iterowalność połączoną ze skutecznymi 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ę prosty jak drut, 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. From c7835063e2d87af3e50d0024ccb141a1e25c1d1d Mon Sep 17 00:00:00 2001 From: Jakub Drozdek Date: Mon, 9 Sep 2019 23:25:21 +0200 Subject: [PATCH 2/2] Minor adjustments --- content/docs/testing.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/docs/testing.md b/content/docs/testing.md index 9d40a9281..c8af44ba6 100644 --- a/content/docs/testing.md +++ b/content/docs/testing.md @@ -9,27 +9,27 @@ next: testing-recipes.html Komponenty reactowe można testować podobnie jak pozostały kod javascriptowy. -Istnieje kilka sposobów na przetestowanie komponentów reactowych. Ogólnie rzecz biorąc, dzielą się one na dwie kategorie: +Istnieje kilka sposobów na przetestowanie komponentów reactowych. W dużym uproszczeniu, dzielą się one na dwie kategorie: -* **Renderowanie drzew komponentów** w oproszczonym środowisku testowym oraz sprawdzanie wyniku renderowania. +* **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"). -Ten rozdział dokumentacji skupia się na strategiach testowania w pierwszy sposób. Mimo iż pełne testy end-to-end są często bardzo pomocne przy zapobieganiu regresji w kluczowych ścieżkach aplikacji, nie zwracają one uwagi na komponenty reactowe. Z tego powodu pominęliśmy je w tej sekcji. +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. ### Kompromisy {#tradeoffs} -Podczas wybierania narzędzia testującego warto zastanowić się na kilkoma kwestiami: +Podczas wybierania narzędzia testującego warto zastanowić się na kilkoma decyzjami: -* **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? +* **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? Do każdego zespołu i każdego produktu pasują inne odpowiedzi na powyższe pytania. ### Zalecane narzędzia {#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 testowania komponentów reactowych. Jest gwarantuje szybką iterowalność połączoną ze skutecznymi 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/)** 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. -**[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ę prosty jak drut, 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)** 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). ### Dowiedz się więcej {#learn-more}