From b6ba7d338f62d62d1388a118dfe8ae65d42c6150 Mon Sep 17 00:00:00 2001 From: Michal Date: Thu, 26 Mar 2020 17:56:57 +0100 Subject: [PATCH] update avoid-global-test-fixture.polish.md fixed --- sections/testingandquality/avoid-global-test-fixture.polish.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sections/testingandquality/avoid-global-test-fixture.polish.md b/sections/testingandquality/avoid-global-test-fixture.polish.md index 53a1c4c0..43791fb7 100644 --- a/sections/testingandquality/avoid-global-test-fixture.polish.md +++ b/sections/testingandquality/avoid-global-test-fixture.polish.md @@ -2,7 +2,7 @@

-### Wyjaśnienie jednego akapitu +### Wyjaśnienie jednym akapitem Kierując się złotą zasadą testowania - spraw, aby przypadki testowe były wyjątkowo proste, każdy test powinien dodawać i działać na swoim własnym zestawie wierszy BD, aby zapobiec sprzężeniu i łatwo uzasadnić przebieg testu. W rzeczywistości jest to często naruszane przez testerów, którzy zapełniają bazę danych danymi przed uruchomieniem testów (znanych również jako „urządzenie testowe”) w celu poprawy wydajności. Chociaż wydajność jest istotnym problemem - można ją złagodzić (np. BD w pamięci, patrz punkt „Testowanie komponentów”), jednak złożoność testu jest bardzo bolesnym smutkiem, który powinien rządzić innymi rozważaniami. Praktycznie spraw, aby każdy przypadek testowy wyraźnie dodał potrzebne rekordy BD i działał tylko na tych rekordach. Jeśli wydajność stanie się kluczowym problemem - zrównoważony kompromis może przyjść w postaci inicjowania jedynego zestawu testów, które nie powodują mutacji danych (np. zapytania)