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.
To wszystko, od praktyk po podejście brzmi bardzo nieprofesjonalnie.
Na b2b w życiu bym się nie wypłacił za takie zabawy na prodzie.
Jeżeli wprowadzasz do kodu zmianę, której zadaniem jest spowodowanie, że ten kod inaczej się zachowuje podczas testów, niż na produkcji, to testy testują kod "testowy", a nie "produkcyjny". W dodatku masz jakąś nie pokrytą testami logikę, która decyduje jak kod powinien się zachować podczas testów. W twoim przypadku błąd poleciał, jak rozumiem właśnie na tej logice.
Postaw jakieś środowisko testowe (nie ważne, czy trwałe, czy ulotne), wrzuć tam dane produkcyjne z poprzedniego miesiąca i niech się kręci. Jak coś się wywali na produkcji, to patrzysz co to było, dopisujesz test/dane, naprawiasz kod i puszczasz.
Jeżeli system ma przekazać coś dalej, to mockujesz ten serwis dalej, żeby dane nie poszły tam gdzie nie mają iść podczas testu (bo pisząc system do odpalania rakiet, pewnie nie chcesz testowo odpalać rakiet.
lambdadziara napisał(a):
Tez Wam sie zdarzaja bledy tego typu?
Staram się robić, co mogę, by do takich sytuacji nie dopuszczać, niestety coraz częściej muszę to zrobić wbrew woli zespołu, w miarę jak bylejakość staje się wszechobecna.
Tzn podczas w bledu w tescie, "naprawiamy blad" i w ten sposob naprawilismy test ale tym samym spowodowalismy blad w realnym prrocesie.
To świadczy o oderwaniu testów od rzeczywistości. Nie powinno być tak, że jakiś efekt jest pożądany w testach a na produkcji jest nieakceptowalny lub odwrotnie.
Znaczy, na pewnym poziomie testów to się zdarza i nie powoduje tragedii, natomiast w przypadku smoke / e2e testów na środowiskach nie-produkcyjnych, a już tym bardziej dla danych testowych na środowisku produkcyjnym, taka sytuacja zdecydowanie nie powinna mieć miejsca.
Pomijając obniżoną wartość samych testów, stwarza poważne ryzyko wywałki spowodowanej wprost wprowadzeniem takich rozgraniczeń i stwarza potencjalnie pole do nadużyć.
Np zrobilismy testy integracyjne dla projektu, do tego specjalny obiekty w bazie takie "testowe", zeby mozna bylo odroznic i jakos analizowac testowe uruchomienia.
Te testy nie powinny mieć styczności z bazą produkcyjną. W bazach testowych przygotowywanie sobie zestawów danych pod konkretne scenariusze jest stosunkowo normalne - przy czym najlepiej, jeśli te dane są populowane w ramach setupu testów, w przeciwnym razie popsucie danych, które ktoś, kiedyś dodał do bazy może wam wszystko wysypać.
Doszlo do bledu podczas testow i "naprawilismy kod" - np dodalismy filtr do querki, zeby pobieral obiekty prawdziwe i testowe, niestety filtr byl niedoskonaly
Rozumiem, że to był jakiś dodatkowy where w zapytaniu - co tam można było zrobić niedoskonale? Ale znowu, dane produkcyjne i testowe do testów integracyjnych nie powinny żyć w jednej bazie. Nawet konta testowe z danymi testowymi, używanymi do weryfikacji produkcji, powinny być traktowane na równi z prawdziwymi danymi produkcyjnymi, w przeciwnym razie będziesz mieć sytuacje takie jak teraz.
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")
Należy jak najprędzej zaprzestać traktowania danych testowych i produkcyjnych odrębnie, z odrębnymi regułami i logiką, za to w jednej bazie. Od tego bym zaczął.
Jeśli nie ma jak rozdzielić bazy, nie ma budżetu by postawić prawdziwy staging / preprod, to zaorać testową logikę, oprzeć się na produkcyjnej i założyć konta testowe, które będą traktowane na równi z produkcyjnymi pod każdym względem, i na nich testować prawdziwą logikę i reguły, a nie testowe.
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.
Zgłoś defekt i opisz, co się dzieje, jakie przyczyny podejrzewasz itd. Jeśli wywaliła się produkcja, to powinno zostać potraktowane priorytetowo, powinien być zgłoszony lub automatycznie zainicjowany incydent, po czym należałoby przeprowadzić analizę Post Mortem / Root Cause Analysis i ustalić w toku takiej analizy, co doprowadziło do wywałki i jak nie dopuścić do powtórki. Wtedy masz bardzo solidny biznesowy powód, by to naprawić, bo jesteś w stanie wykazać dlaczego to działanie jest niezbędne.