Jak w Twojej firmie podchodzicie do tematu testowania?

1. Jaki(e) rodzaj(e) testów?
2. Czy mierzycie pokrycie kodu testami (%)?
3. Jaki typ projektu/projektów?
4. Jaka technologia?

1. Jednostkowe i integracyjne. W innym projekcie mamy trochę hybrydę taką.
2. Nie
3. Webowe, enterprise
4. .NET Core

1. Integracyjne i częściowo jednostkowe (kluczowe części systemu)
2. Nie
3. Webowe, SaaS
4. Python

1. jednostkowe, funkcjonalne, integracyjne
2. tak (nawet osobiście to wprowadziłem) - pierwszy pomiar dał średni wynik 68%
3. klient + serwer + frontend
4. C++, JavaScript React

1. Żadne.
2. const COVERAGE = 0.0;
3. Web
4. PHP

1. Jednostkowe, integracyjne
2. Nie
3. Backend dla strony i aplikacji mobilnej
4. JVM (java+kotlin)

1. W innych projektach słyszałem o integracyjnych, w moim tylko jednostkowe
2. Mierzymy w charakterze ciekawostki, wynosi 20-30%
3. Enterprise webapka
4. ASP.NET

1. 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.
2. W jednostkowych 42%, ale tu jest sporo rzeczy, których jednostkowo nie ma sensu testować.
3. Mikroserwisy, API, narzędzia konsolwe
4. .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ą.

1. Jednostkowe, integracyjne, e2e (selenium, cypress, ...), wydajnościowe (Gatling, wrk, ...), security, A/B
2. Nie
3. Mikroserwisy, backend pod www i apki
4. JVM (Java, Kotlin) i inne

euro2012spoko napisał(a):

1. 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

2. Czy mierzycie pokrycie kodu testami (%)?

Oficjalnie, w ramach buildów to nie, chociaż chcemy to wprowadzić.

3. Jaki typ projektu/projektów?

API webowe, mikroserwisy, wymieniona wcześniej architektura event-driven.

4. Jaka technologia?

.Net Core, Azure

euro2012spoko napisał(a):

1. 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

2. Czy mierzycie pokrycie kodu testami (%)?

W naszym projekcie nie

3. Jaki typ projektu/projektów?

Enterprise / web / backend / ogólnie "uchmurowianie" i "umikroserwisowianie"

4. Jaka technologia?

JVM (Gosu / Java / Kotlin / Groovy), Python, inne

1. 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
2. Nie
3. Ecommerce średni i duży
4. 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.

@Belka:

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.