Tez Wam sie zdarzaja bledy tego typu? Tzn podczas w bledu w tescie, "naprawiamy blad" i w ten sposob naprawilismy test ale tym samym spowodowalismy blad w realnym prrocesie. Np zrobilismy testy integracyjne dla projektu, do tego specjalny obiekty w bazie takie "testowe", zeby mozna bylo odroznic i jakos analizowac testowe uruchomienia. Doszlo do bledu podczas testow i "naprawilismy kod" - np dodalismy filtr do querki, zeby pobieral obiekty prawdziwe i testowe, niestety filtr byl niedoskonaly - i chociaz test kazdego dnia dzialal program nigdy sie nie wywalal, to jak sie okazalo, wywalil sie dla prawdziwych danych (przez to, ze te mialy obiekt "nietestowy")
Znowu wywalilam proda i nie wiem w jaki sposob to wytlumaczyc, zeby mialo rece i nogi... Bo to dzialalo wczesniej i nie ma za bardzo uzasadnienia biznesowego dla zmian.
W jakim rodzaju testu?
Masz regression testy w projekcie? Najlepszy check czy czegoś nie zepsuliśmy.
Masz jedną baze na prod + testy?
Testy integracyjne jak dobrze kojarze raczej nie powinny polegać na rzeczywistej bazie danych, raczej jakieś zamockowane, testcontainers się sprawdza, kiedyś działałem z jakimś H2 w in-memory runtime.
Korges napisał(a):
W jakim rodzaju testu?
Masz regression testy w projekcie? Najlepszy check czy czegoś nie zepsuliśmy.
caly program to jest pewien biznesowy proces ktory sie wykonuje automatycznie raz na miesiac. I ja zrobilam test typu - triggerowanie tego procesu codziennie dla testowych danych, zeby wiadomo bylo, ze dziala. Dane testowe sa takie same jak realne oprocz tego "typu" (pola w bazie), ktore jest inne, zeby mozna bylo filtrowac testowe wykonania. Ten test ujawnil pewien problem w kodzie i dodalam filter do querki, ktory rozwiazal problem i takze wszystkie testowe "typu" byly wylapywane przez co dane testowe byly zawsze ladowane bez problemu. Ale ten filter byl zbyt sztywny i blokowal niektore prawdziwe dane.
Cóż no, dla mnie to brzmi jak brak warstwy regression tests gdzie jedyne co wrzucasz/przygotowujesz to baze danych z danymi i odpalasz na najnowszym kodzie/buildzie sprawdzając czy jest oczekiwany(obecny działający kod) rezultat.
Pomyłki się zdarzają, nikt nie jest nieomylny. Możesz zwalić na to że brakuje takiej warstwy jak w każdym porządnym projekcie ;)
Inna kwestia że jak piszesz oni chcą wykonywanie testów codziennie na PROD.
Jak dla mnie... zrzut bazy powinien być która nie jest podpięta do PROD (albo jakaś druga schema SNAPSHOT) i na niej odpalasz 'testowy' scenariusz E2E bez zabawy w dane testowe... Tylko od razu operacja na real data bez babrania się w testowe rowy... Co najwyżej kolumna na każdym rekordzie że mamy SNAPSHOT czy coś takiego, jesli chcesz wyłączyć jakieś integracje. (a raczej property do ustawienia w konfiguracji)
Nic z tego nie rozumiem 
lambdadziara napisał(a):
Ale ten filter byl zbyt sztywny i blokowal niektore prawdziwe dane.
No to chyba jasno znaczy o tym że takie podejście zgrzyta - spróbujmy teraz dowiedzieć się czemu.
Jak rozumiem - jest jakiś proces, który odpala się raz na miesiąc. Ma jakieś dane wejściowe. Rozumiem, że dla testów został on włączony z innymi danymi wejściowymi. Pytanko - one są mu dostarczane z zewnątrz (np. to co go uruchamia mu je przekazuje jako parametry uruchomieniowe) czy po prostu się go włącza i on sam je fetchuje skądś?
Zdarzyło się parę razy, na przykład okazało się że był błąd i kod rzucał wyjątkiem którego nie powinno być, poprawiliśmy to po czym na produkcji okazało się że w innym miejscu jest catch który zmienia flow kodu w przypadku błędu i teraz w pewnych przypadkach wyjątek na którym ten kod w zasadzie polegał nie działa.
Raz projekt się zepsuł po naprawieniu błędów lintera. Różne cuda się zdarzają jak projekt nie jest dobrze przetestowany. Ogólnie każda zmiana może potencjalnie wprowadzić błąd nawet przy stosowaniu TDD jak widać po tym forum.
Testy i dane testowe na produkcji to jest proszenie się o kłopoty.
Dla mnie priorytetem byłoby jak najszybsze wycofanie się z takiego rozwiązania.
Dane testowe sa takie same jak realne oprocz tego "typu" (pola w bazie), ktore jest inne
Ja to rozumiem tak, że dla teoretycznej tabeli zamówień w produkcyjnej bazie mielibyśmy wpisy:
| id_klienta | numer_zamowienia | data | kwota_gr | typ |
| 9876 | WZX-222333 | 2024-10-16 | 50000 | normalne |
| 9876 | WZX-222333 | 2024-10-16 | 50000 | testowe |
To jest śliska sytuacja, ponieważ bardzo łatwo można doprowadzić np. do zamówienia od dostawcy produktów za 1000, podczas gdy nasz klient chce kupić za 500, i kto wtedy pokryje różnicę?
Poza tym, w przypadku procesu wykonywanego raz na miesiąc sprawdzanie go codziennie wcale nie gwarantuje poprawności, ponieważ sposób działania procesu może zależeć od czasu wskazywanego przez zegar systemowy aplikacji albo bazy danych. Proces może zawierać np. warunek w SQL odnoszący się do pierwszego lub ostatniego dnia m-ca i wtedy prawidłowe działanie 30 września wcale nie musi oznaczać prawidłowego działania 1 października. Testy musiałyby się wykonywać na środowisku z przestawioną datą, a zatem nie na produkcji.
Bo to dzialalo wczesniej i nie ma za bardzo uzasadnienia biznesowego dla zmian.
Jak to nie ma? Przecież jest:
requirement byl jasny - zeby te testy (codzienne wykonywania) uruchamialy sie na PROD
Można ten wymóg wskazać jako powód do wprowadzenia modyfikacji w czymś, co "wcześniej działało".
Dane testowe sa takie same jak realne oprocz tego "typu" (pola w bazie),
A co jak ktoś zrobi selecta bez uwzględnienia tego? Takie podejście wprowadza tylko zamieszanie. W pewnych sytuacjach może to mieć sens np.
- aplikacja działa dla wszystkich userów i ich obecność nie wpływa na działanie kodu związanego z innymi userami
- testowy user to po prostu zwykły normalny user
W innych przypadkach jedyne co robisz to umyślne budowanie legacy
Zdarzyło mi się w jednym projekcie, dałem branch w kodzie, który, żeby naprawić test, mutował environment, nie zadbałem o usunięcie go po teście, bo i tak nie miał prawa zadziałać na produkcji.... 
Tez Wam sie zdarzaja bledy tego typu? Tzn podczas w bledu w tescie, "naprawiamy blad" i w ten sposob naprawilismy test ale tym samym spowodowalismy blad w realnym prrocesie.
Mogło mi się zdarzyć na początku kariery. Ale teraz jeśli test zwraca błąd, to raczej staram się dociec dlaczego, a nie dostosowywać kod pod ten test na ślepo. I albo wychodzi, że jest faktyczny błąd w procesie, albo, że jest błąd w teście.
No i takie robienie danych testowych na prodzie jak opisałaś to zły pomysł. Dodanie testu integracyjnego nie powinno w żaden sposób psuć proda, najlepiej w ogóle nie powodować zmian w kodzie produkcyjnym (poza może refaktorem dla ułatwienia testowania).
requirement byl jasny - zeby te testy (codzienne wykonywania) uruchamialy sie na PROD
Próbowałbym pomysłodawcy wytłumaczyć czemu to jest zły pomysł. Jeśliby się upierał, to mimo to starałbym się maksymalnie odizolować te testy od produkcyjnych rzeczy. Choćby dając im oddzielnego użytkownika w bazie z ograniczonymi uprawnieniami. A najlepiej oddzielną instancję aplikacji (wdrożona na serwer PROD, więc teoretycznie spełnia wymaganie 
) z taką konfiguracją, że żaden efekt uboczny wpływający na prawdziwych klientów nie miałby prawa się zadziać (np. wysyłka maili).
U mnie to środowisko nazywa się pre-prod i zawiera kopię danych z bazy produkcyjnej jak i całą konfigurację środowiska (dzięki ci Terraform i Ansible). Zwykle jest to snapshot sprzed kilku godzin więc dane są w miarę świeże. Jak si coś popsuje na pre-prodzie to się robi terraform destroy i potem terraform apply :P
Polecam ten styl pracy.
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.