Sysdate a testy jednej aplikacji

Dawno dawno temu ....

...zasiedliśmy do testów Jednej Aplikacji. Zadanie bojowe - przetestować Zamknięcie Miesiąca. Wprawdzie nie ta data, do końca miesiąca jeszcze trochę, ale przecież jako IT - mamy swoje sposoby.

Zmieniamy datę na serwerze! Jest pierwszy sukces, zagięliśmy czasoprzestrzeń i voila - mamy Ostatni Dzień Miesiąca. Można zaczynać testy.

Ruszyły!

Trochę to trwało zanim się wykręciły. W sumie to trwały parę godzin. Ale w końcu  wszystko się kończy. Sprawdzamy wyniki.... I niestety dramat :) Wyniki kompletnie od czapy.

Zagłębiamy się więc w kod szukając przyczyny. Nic nie znaleźliśmy. Ponawiamy więc testy. 

Jeszcze tylko zmiana daty na serwerze i .... ruszyły!

Cierpliwie wyczekaliśmy końca procesu. Z nadzieją weryfikujemy wyniki. Niestety, znów pudło.

Znów zanurzamy się w kod, znów nic z naszej analizy nie wynika. Dodajemy jakieś dodatkowe logowania. I po raz kolejny - zmiana daty, start testów...

Dotarliśmy do tej granicy w pracy programisty, gdzie pozostaje tylko wykrzyknąć NIEMOŻLIWE! 

A jednak wyniki nie kłamią. Coś jest nie tak...

Trwaliśmy w takim stuporze dobre kilka dni, kompletnie nic nie rozumiejąc. Aż któregoś dnia odebraliśmy telefon od Zespołu Administratorów, którzy w krótkich, żołnierskich słowach zaprotestowali przeciwko naszym zmianom daty na serwerze. Bo ciągle muszą ją przywracać na właściwą i się już zmęczyli!

Tia..... My zmienialiśmy datę na potrzeby testów a Admini ją przywracali... A kilka dni testów szlag trafił...

Gdy puściliśmy testy, uprzednio uzyskując od Adminów gwarancję, że tym razem nie będą zmieniać daty - nagle okazało się, że cały proces przeszedł bezbłędnie.

Jednak szkoda straconego czasu...

Czy takich sytuacji można uniknąć?

Jest wiele możliwości :)

Jednym z oczywistych sposobów jest po prostu uzgodnienie zmiany daty z osobami korzystającymi z tych samych serwerów. Jednak często na jednym serwerze prowadzone są jednocześnie różne testy, czasem różnych systemów i zmiana daty tylko na potrzeby jednego testu może być trudna do uzgodnienia. 

W niektórych firmach w ogóle temat zmiany daty na serwerze nie wchodziłby w grę! 

Także może to oznaczać naprawdę duże trudności w przetestowaniu często kluczowych funkcjonalności...

Takim sytuacjom możemy i powinniśmy ZAPOBIEGAĆ  wcześniej, w czasie projektu technicznego i developmentu. Jedyną rzeczą, jaką musimy zrobić - to pozbyć się z naszego kodu SYSDATE. Co najlepsze  to nie jest trudne!

Jak pozbyć się SYSDATE?

Pierwszym krokiem jest pozbycie się KAŻDEGO*  SYSDATE z naszego kodu.

Ponieważ jednak nasze procesy potrzebują informacji o dacie - przekażemy tę informację za pomocą parametru wejściowego. Do procedur dodajemy odpowiedni parametr pdCurrentDate typu DATE  z wartością DEFAULT SYSDATE.

Dzięki takiej konstrukcji w bardzo prosty sposób będziemy mogli przeprowadzać testy DLA DOWOLNEJ DATY bez żadnego problemu i bez konieczności zmiany daty na serwerze. Po prostu w parametrze wejściowym pdCurrentDate podamy datę, dla której chcemy uruchomić proces.

A co najważniejsze - na systemie produkcyjnym system będzie korzystał z bieżącej daty dzięki ustawieniu wartości domyślnej na SYSDATE.

* Ponieważ od każdego wyjątku jest reguła należy przyznać, że nie każdy SYSDATE jest zły.  SYSDATE perfekcyjnie się nadaje do zadań audytowych czy logów. Jeśli chcemy wiedzieć kiedy dokładnie jakiś rekord został dodany czy zmodyfikowany - nie ma nic lepszego niż SYSDATE.  W takich miejscach SYSDATE możemy spokojnie pozostawić.  Pozbywamy się tych SYSDATE'ów, na których oparte są nasze procesy funkcjonalne. 

Na jedną jednakże rzecz warto zwrócić uwagę - w powyższej sytuacji data systemowa i data przetwarzania mogą się różnić. Dlatego na potrzeby późniejszej analizy warto logować obie daty - i datę SYSDATE, by wiedzieć, kiedy został dany błąd/log zapisany do bazy w czasie rzeczywistym oraz datę przetwarzania - czyli za jaką datę był uruchamiany nasz proces.

A do tego całkiem w gratisie dostajemy lepszą wydajność systemu :)

Miłego kodowania i testowania!