How Guru’s Engineers Use Cypress for Better Burn Testing
Potrzebujesz lepszego sposobu na obsługę testów obciążeniowych? Dwóch naszych inżynierów front-end znalazło sposób na wykorzystanie Cypress do poprawy sposobu, w jaki obsługują zapewnienie jakości.
Jesteśmy zwolennikami dzielenia się wiedzą w Guru, a gdy odkrywamy coś nowego i przydatnego, chcemy, aby świat o tym wiedział! Nasz zespół inżynieryjny używa Cypress w swoim procesie testowania i zapewnienia jakości. Odkryli nowy sposób na przeprowadzanie lepszych testów obciążeniowych i chcą podzielić się swoim nowym i ulepszonym procesem z innymi inżynierami i testerami.
W ciągu ostatniego roku koncentrowaliśmy się na zwiększeniu pokrycia naszych testów — szczególnie przeprowadzając testy end-to-end, które zapewniają, że różne części naszych procesów produktowych działają prawidłowo podczas aktualizacji kodu. Do tego rodzaju testowania wykorzystujemy narzędzie o nazwie Cypress, które naśladuje zachowanie użytkownika z naszą aplikacją internetową i rozszerzeniem Google Chrome. Ten zestaw testów działa przy każdym pull requeście, aby zapewnić, że nowy kod nie psuje naszego interfejsu użytkownika. Chcemy także zablokować wydania, jeśli nasz zestaw Cypress nie zadziała na naszym głównym branchu produkcyjnym.
Czego szukamy w tradycyjnym testowaniu
Jednym z problemów, z którymi się borykaliśmy, jest to, że niektóre z naszych testów mogą się nie powieść, ale nie z powodu problemów związanych z interfejsem użytkownika lub kodem. Jak Cypress pomaga w takich przypadkach? Mamy Cypress, który działa jako użytkownik, którego zachowanie możemy zdefiniować. Istnieje wiele zmiennych, które mogą spowodować, że Cypress powie nam, że wystąpiła awaria, ale z perspektywy użytkownika nic nie wydaje się być nie tak.
Na przykład może istnieć test, który mówi: "Przejdź do tej części aplikacji internetowej > Dodaj nową kartę Guru > Oczekuj, że zobaczysz stan po utworzeniu". Jeśli stan ładowania utworzenia karty będzie trwał o milisekundę za długo i Cypress zacznie szukać stanu po utworzeniu zanim tam będzie, ten test może się nie powieść (jednak w większości przypadków, ten test przejdzie). Jeśli przechodzi raz przy pull requeście, możemy zmergować kod, który czasami może sprawiać problemy. Ale nie będziemy wiedzieć, czy tak jest; zdany test nie jest gwarancją, że kod jest prawidłowy.
Tego rodzaju sytuacja obniża niezawodność naszego pokrycia testowego. W rezultacie, gdy pojawia się awaria testu w naszym pipeline wdrożeniowym, musimy zweryfikować, czy jest to problem z UI — czy z testem. Aby to naprawić, zaczęliśmy myśleć o sposobach, w jakie moglibyśmy wykryć, czy test może mieć problemy przed przystąpieniem do naszej gałęzi kodu produkcyjnego.
Jak testy obciążeniowe pomagają
Wprowadzenie testów obciążeniowych. Testy obciążeniowe to proces używany do testowania czegoś w bardziej rygorystycznych lub ekstremalnych warunkach. Są także czasami nazywane testami obciążeniowymi lub testami wydajnościowymi, w zależności od metody lub konkretnego obszaru, który jest testowany.
W Guru używamy testów obciążeniowych jako części naszego zestawu Cypress dla wszelkich nowych lub zmodyfikowanych testów, które dodawane są do naszego kodu. Zanim te testy mogą zostać scalone, uruchamiamy je kilka razy z rzędu i wszystkie muszą przejść, aby przejść do następnego kroku w naszym potoku budowy CircleCI.
Ten krok następuje bezpośrednio przed uruchomieniem całego zestawu testów Cypress. Zaletą tej kolejności jest to, że jeśli nasz krok testowania obciążeniowego wywołuje awarię, możemy oznaczyć cały test jako awarię wcześnie. Pominięcie reszty zestawu pozwala nam zaoszczędzić czas i zmniejszyć liczbę cykli potrzebnych do zapewnienia, że nowo wprowadzone testy są tak niezawodne i odporne na awarie, jak ich potrzebujemy.
Aby znaleźć pliki, których szukamy, używamy git diff na bieżącym branchu i podajemy wynik jako parametr do narzędzia o nazwie cypress-repeat, które pozwala nam uruchamiać te testy dowolną określoną liczbę razy, skutecznie dodając testy obciążeniowe jako krok w naszym zestawie testów end-to-end.
Wynik
Wprowadzenie tej zmiany w naszych planach testowych przyniosło całkiem pozytywne rezultaty. Dla nas dodanie testów obciążeniowych może skrócić czas potrzebny na znalezienie niezawodnych testów o 30 minut. Poprawia także czas reakcji przy dodawaniu nowej funkcjonalności. Ponieważ nowo dodane testy są teraz uruchamiane jako pierwsze, pozwalają nam zweryfikować stabilność przed kontynuowaniem procesu budowy.
Ogólnie nasze ciągłe skupienie się na ulepszaniu naszych procesów testowych zwiększa zaufanie całego zespołu inżynieryjnego do szybkiego wprowadzania nowych funkcji. Szybciej naprawiamy błędy i ułatwiamy pracę w całej naszej bazie kodów. Mamy nadzieję, że ten wpis pomoże innym użytkownikom Cypress w tworzeniu lepszych testów i całym zespołom w budowaniu bardziej efektywnie.
Jesteśmy zwolennikami dzielenia się wiedzą w Guru, a gdy odkrywamy coś nowego i przydatnego, chcemy, aby świat o tym wiedział! Nasz zespół inżynieryjny używa Cypress w swoim procesie testowania i zapewnienia jakości. Odkryli nowy sposób na przeprowadzanie lepszych testów obciążeniowych i chcą podzielić się swoim nowym i ulepszonym procesem z innymi inżynierami i testerami.
W ciągu ostatniego roku koncentrowaliśmy się na zwiększeniu pokrycia naszych testów — szczególnie przeprowadzając testy end-to-end, które zapewniają, że różne części naszych procesów produktowych działają prawidłowo podczas aktualizacji kodu. Do tego rodzaju testowania wykorzystujemy narzędzie o nazwie Cypress, które naśladuje zachowanie użytkownika z naszą aplikacją internetową i rozszerzeniem Google Chrome. Ten zestaw testów działa przy każdym pull requeście, aby zapewnić, że nowy kod nie psuje naszego interfejsu użytkownika. Chcemy także zablokować wydania, jeśli nasz zestaw Cypress nie zadziała na naszym głównym branchu produkcyjnym.
Czego szukamy w tradycyjnym testowaniu
Jednym z problemów, z którymi się borykaliśmy, jest to, że niektóre z naszych testów mogą się nie powieść, ale nie z powodu problemów związanych z interfejsem użytkownika lub kodem. Jak Cypress pomaga w takich przypadkach? Mamy Cypress, który działa jako użytkownik, którego zachowanie możemy zdefiniować. Istnieje wiele zmiennych, które mogą spowodować, że Cypress powie nam, że wystąpiła awaria, ale z perspektywy użytkownika nic nie wydaje się być nie tak.
Na przykład może istnieć test, który mówi: "Przejdź do tej części aplikacji internetowej > Dodaj nową kartę Guru > Oczekuj, że zobaczysz stan po utworzeniu". Jeśli stan ładowania utworzenia karty będzie trwał o milisekundę za długo i Cypress zacznie szukać stanu po utworzeniu zanim tam będzie, ten test może się nie powieść (jednak w większości przypadków, ten test przejdzie). Jeśli przechodzi raz przy pull requeście, możemy zmergować kod, który czasami może sprawiać problemy. Ale nie będziemy wiedzieć, czy tak jest; zdany test nie jest gwarancją, że kod jest prawidłowy.
Tego rodzaju sytuacja obniża niezawodność naszego pokrycia testowego. W rezultacie, gdy pojawia się awaria testu w naszym pipeline wdrożeniowym, musimy zweryfikować, czy jest to problem z UI — czy z testem. Aby to naprawić, zaczęliśmy myśleć o sposobach, w jakie moglibyśmy wykryć, czy test może mieć problemy przed przystąpieniem do naszej gałęzi kodu produkcyjnego.
Jak testy obciążeniowe pomagają
Wprowadzenie testów obciążeniowych. Testy obciążeniowe to proces używany do testowania czegoś w bardziej rygorystycznych lub ekstremalnych warunkach. Są także czasami nazywane testami obciążeniowymi lub testami wydajnościowymi, w zależności od metody lub konkretnego obszaru, który jest testowany.
W Guru używamy testów obciążeniowych jako części naszego zestawu Cypress dla wszelkich nowych lub zmodyfikowanych testów, które dodawane są do naszego kodu. Zanim te testy mogą zostać scalone, uruchamiamy je kilka razy z rzędu i wszystkie muszą przejść, aby przejść do następnego kroku w naszym potoku budowy CircleCI.
Ten krok następuje bezpośrednio przed uruchomieniem całego zestawu testów Cypress. Zaletą tej kolejności jest to, że jeśli nasz krok testowania obciążeniowego wywołuje awarię, możemy oznaczyć cały test jako awarię wcześnie. Pominięcie reszty zestawu pozwala nam zaoszczędzić czas i zmniejszyć liczbę cykli potrzebnych do zapewnienia, że nowo wprowadzone testy są tak niezawodne i odporne na awarie, jak ich potrzebujemy.
Aby znaleźć pliki, których szukamy, używamy git diff na bieżącym branchu i podajemy wynik jako parametr do narzędzia o nazwie cypress-repeat, które pozwala nam uruchamiać te testy dowolną określoną liczbę razy, skutecznie dodając testy obciążeniowe jako krok w naszym zestawie testów end-to-end.
Wynik
Wprowadzenie tej zmiany w naszych planach testowych przyniosło całkiem pozytywne rezultaty. Dla nas dodanie testów obciążeniowych może skrócić czas potrzebny na znalezienie niezawodnych testów o 30 minut. Poprawia także czas reakcji przy dodawaniu nowej funkcjonalności. Ponieważ nowo dodane testy są teraz uruchamiane jako pierwsze, pozwalają nam zweryfikować stabilność przed kontynuowaniem procesu budowy.
Ogólnie nasze ciągłe skupienie się na ulepszaniu naszych procesów testowych zwiększa zaufanie całego zespołu inżynieryjnego do szybkiego wprowadzania nowych funkcji. Szybciej naprawiamy błędy i ułatwiamy pracę w całej naszej bazie kodów. Mamy nadzieję, że ten wpis pomoże innym użytkownikom Cypress w tworzeniu lepszych testów i całym zespołom w budowaniu bardziej efektywnie.
