#testowanieoprogramowania #programowanie Elo mirki. jakich tooli do automatycznych testów używacie waszych firmach? Mój menagemnet przyszedł i chce spróbować czegoś nowego. Co jest dobre a czego sie lepiej wystrzegać? toole/ biblioteki/ komabjany cokolwiek. python / C# / code-less / cokolwiek co sie nadaje do testowania
@sunshine_flower: dostosowanych do projektu. Jak aplikacja jest w TS-ie to wlatuje cypress, jak java i nie ma nacisku na testy UI to rest assured. No generalnie trzeba dostosowywać do sytuacji i unikać rozwiązań typu nagrywarki testów
@sunshine_flower: Desktop a embedded to dwa różne światy i różne narzędzia. Już w samym embedded testy integracyjne i systemowe mogą używać różnych narzędzi (i HW). TS+LV jest solidnym wyborem i jeżeli się szuka alternatywy, to można skończyć na jakimś rozwiązaniu "homebuilt" i zamienić stare problemy na nowe :).
@stary_kon: not my call :) szukamy czegoś co można pożenić za pomocoą jakiś interfaców/ symulatorów. PyTest, Xunit, KAtaloon studio i inne tego typu wynazki
@sunshine_flower: w czyn pisana jest apka? Jak integracyjne / e2e to cypress, playwright, webdriverio, selenium webdriver, musisz przejrzeć dokumentacje i trade offy by wiedzieć czego nie zautomatyzujesz w danym narzędziu i na tej podstawie powoli możesz wybierać narzędzie.
Moim zdaniem istotne też wsparcie developerów, czyli w jakim języku oni piszą, pod to wybierać narzędzie, bo wtedy sami czasami mogą wskoczyć w testy i coś poprawić jak popsują, a dodatkowo masz
@sunshine_flower cypress i playwright do e2e - każde z tych narzędzi ma ograniczenia wiec warto poczytać o różnicach. Jeśli nie są one problemem to zdecydowanie wybralbym playwrighta. Kiedyś w projekcie mieliśmy również robot framework do e2e oraz desktop, sprawdził się.
@sunshine_flower: Wydaje mi się, że da się karmić LV z pythona ale na LV się nie znam. Jeżeli musicie używać I/O i dodatkowego HW (w szczególności NI) to bym zostawił TS do testów e2e. Do integracyjnych to starałbym się za wszelką cenę uniknąć redundancji i szukałbym sposobu na fault injection. Może jakieś XCP +python (lub LV). Można pomyśleć nad emulowaniem sprzętu, wtedy otwierają się nowe możliwości.
@sunshine_flower: Zależy od projektu. Znikają ograniczenia związane z HW. Testy już nie trwają kilka tygodni. Możliwość wprowadzenia rozsądnego CI. Do tego tylko uzupełniające testy integracyjne i e2e by złapać problemy na pograniczu HW i SW. Dobra emulacja jest często jednak bardzo trudna. Niesety tutaj już trzeba samemu określić stosunek kosztów do zysków pod to co się testuje. Inaczej to będzie wyglądać dla IOT, inaczej dla Automotive a jeszcze inaczej dla
@Zwierzak24: true
Selenium WebDriver, wspomniany Cypress
TS+LV jest solidnym wyborem i jeżeli się szuka alternatywy, to można skończyć na jakimś rozwiązaniu "homebuilt" i zamienić stare problemy na nowe :).
Jak integracyjne / e2e to cypress, playwright, webdriverio, selenium webdriver, musisz przejrzeć dokumentacje i trade offy by wiedzieć czego nie zautomatyzujesz w danym narzędziu i na tej podstawie powoli możesz wybierać narzędzie.
Moim zdaniem istotne też wsparcie developerów, czyli w jakim języku oni piszą, pod to wybierać narzędzie, bo wtedy sami czasami mogą wskoczyć w testy i coś poprawić jak popsują, a dodatkowo masz
Jeżeli musicie używać I/O i dodatkowego HW (w szczególności NI) to bym zostawił TS do testów e2e. Do integracyjnych to starałbym się za wszelką cenę uniknąć redundancji i szukałbym sposobu na fault injection. Może jakieś XCP +python (lub LV).
Można pomyśleć nad emulowaniem sprzętu, wtedy otwierają się nowe możliwości.
Niesety tutaj już trzeba samemu określić stosunek kosztów do zysków pod to co się testuje. Inaczej to będzie wyglądać dla IOT, inaczej dla Automotive a jeszcze inaczej dla