- Jaki(e) rodzaj(e) testów?
- Czy mierzycie pokrycie kodu testami (%)?
- Jaki typ projektu/projektów?
- Jaka technologia?
- Jednostkowe i integracyjne. W innym projekcie mamy trochę hybrydę taką.
- Nie
- Webowe, enterprise
- .NET Core
- Integracyjne i częściowo jednostkowe (kluczowe części systemu)
- Nie
- Webowe, SaaS
- Python
- jednostkowe, funkcjonalne, integracyjne
- tak (nawet osobiście to wprowadziłem) - pierwszy pomiar dał średni wynik 68%
- klient + serwer + frontend
- C++, JavaScript React
- Żadne.
-
const COVERAGE = 0.0;
- Web
- PHP
- Jednostkowe, integracyjne
- Nie
- Backend dla strony i aplikacji mobilnej
- JVM (java+kotlin)
- W innych projektach słyszałem o integracyjnych, w moim tylko jednostkowe
- Mierzymy w charakterze ciekawostki, wynosi 20-30%
- Enterprise webapka
- ASP.NET
- U mnie jest 5 warstw testów (serio takiej nomenklatury używają). 0 to jednostkowe, 1 to testy mocków, 2 to takie normalne integracyjne/systemowe sprawdzające współpracę z innymi systemami.
- W jednostkowych 42%, ale tu jest sporo rzeczy, których jednostkowo nie ma sensu testować.
- Mikroserwisy, API, narzędzia konsolwe
- .NET Core
W mojej firmie testy są bardzo ważne i dość mocno cisną w tym kierunku. Chyba że zespół zdecyduje że nie są ważne, to wtedy nie cisną.
- Jednostkowe, integracyjne, e2e (selenium, cypress, ...), wydajnościowe (Gatling, wrk, ...), security, A/B
- Nie
- Mikroserwisy, backend pod www i apki
- JVM (Java, Kotlin) i inne
euro2012spoko napisał(a):
- Jaki(e) rodzaj(e) testów?
- Trochę testów jednostkowych, ale tylko tam gdzie to naprawdę naszym zdaniem ma sens- np. testowanie jakichś walidatorów, a więc wywoływanie tej samej metody (jednostki) z rożnymi danymi wejściowymi.
- Coś co nazywamy* behavioral tests*- nie mylić z testami stosującymi Gherkin, chociaż to również stosujemy do pewnego stopnia. Mianowicie w tych testach "behawioralnych" skupiamy się na logice biznesowej (procesie) pod testem, i staramy się ograniczyć wszelkie mockowanie/fake'owanie do minimum aby nie tworzyć niepotrzebnego "szumu" w kodzie. Tak więc mamy jakąś klasę bazową która podmienia wszelkie zewnętrzne zależności takie jak bazy danych, inne serwisy itp.Reszta pozostaje bez zmian i np. przy testowaniu procesu który jest inicjowany requestem do API testujemy ten proces właśnie razem z wykonaniem requesty do API, ale jest to API odpalane w pamięci w ramach testu, wykorzystując do tego
TestHost
dostępny w ASP Core. Mamy architekturę event-driven a więc handlery obsługujące eventy również są testowane na zasadzie że w pamięci "wysyłamy" event który jest kierowany do handlera. Następnie skupiamy się na rezultacie operacji- jakie eventy zostały wyemitowane po obsłużeniu eventu inicjującego. Ogólnie duży nacisk kładziemy na to żeby pisać kod sprawdzający to CO testujemy, a nie JAK to robimy. Innymi słowy unikamy pisania masy mocków zanim w ogóle zaczniemy coś testować. - Aktualnie trwają pracę nad zautomatyzowanymi testami UI, ale od tego mamy dedykowaną osobę
- Planujemy niedługo wprowadzić testy integracyjne
- Czy mierzycie pokrycie kodu testami (%)?
Oficjalnie, w ramach buildów to nie, chociaż chcemy to wprowadzić.
- Jaki typ projektu/projektów?
API webowe, mikroserwisy, wymieniona wcześniej architektura event-driven.
- Jaka technologia?
.Net Core, Azure
euro2012spoko napisał(a):
- Jaki(e) rodzaj(e) testów?
UT, IT, E2E, behawioralne, security, wydajnościowe, statyczna analiza kodu - poniekąd też jest formą testowania. Obiły mi się o uszy automatyczne testy UI. Zestaw może się lekko zmieniać od projektu do projektu
- Czy mierzycie pokrycie kodu testami (%)?
W naszym projekcie nie
- Jaki typ projektu/projektów?
Enterprise / web / backend / ogólnie "uchmurowianie" i "umikroserwisowianie"
- Jaka technologia?
JVM (Gosu / Java / Kotlin / Groovy), Python, inne
- Tylko manualne w szerokim zakresie, pen testy, obciążeniowe + teraz trochę automatyzacji jeden z testerów chce przeprowadzić z użyciem Selenium ale to bardziej oddolna inicjatywa i chyba nawet management o tym jeszcze nie wie. Testów jednostkowych brak
- Nie
- Ecommerce średni i duży
- PHP
Reasumując o ile w innych obszarach raczej nie odbiegamy od Javy/C# to testujemy dalej na produkcji ;-)
U nas testy są bardzo ważne, wymaganie jest, by przy każdym jenkinsowym runie wszystkie testy były na zielono. W praktyce nie zawsze się to udaje, ale nie jest to temat bagatelizowany. Oprócz tego jasno określone (i wysokie) progi total coverage i modified code coverage.
U nas testy są bardzo ważne, wymaganie jest, by przy każdym jenkinsowym runie wszystkie testy były na zielono. W praktyce nie zawsze się to udaje, ale nie jest to temat bagatelizowany.
Co przez to rozumiesz? Macie testy które nie przechodzą a i tak robicie deployment?
Aventus napisał(a):
Co przez to rozumiesz? Macie testy które nie przechodzą a i tak robicie deployment?
Wytwarzamy narzędzia na desktopy, więc w świat idą tylko buildy releasowe, które muszą się błyszczeć i lśnić, więc nie ma mowy o releasie z failującymi testami. Tak samo ma się sytuacją z jakimiś milestonowymi buildami, albo RCkami. Nasz kod jest również reużywany w innych devzespołach w firmie, ale wtedy budujemy się tylko, jeżeli jesteśmy OK z testami.
Zarejestruj się i dołącz do największej społeczności programistów w Polsce.
Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.