Jak testujesz oprogramowanie wrażliwe na czas?

Przez wrażliwy na czas rozumiem na przykład skrypt, który działa tylko raz w miesiącu lub skrypt, który działa w sposób ciągły, ale daje określony wynik tylko raz w miesiącu. Oczywiście możesz przeprowadzić test jednostkowy dla wielu przypadków, ale są wyjątki (w moim rozumieniu).

Ostatnim przykładem, na jaki natknąłem się, było skonfigurowanie zadania crona do uruchomienia od drugiego do ostatniego dnia każdego miesiąca. Wymagało to użycia skryptu powłoki z kartą cron, aby uzyskać prawidłowy dzień miesiąca dla crona, na przykład:

1 0 [shell command] * * [my script]

Nie byłem zaznajomiony ze skryptem i ogólnie ze skryptami powłoki, więc nie miałem dobrego sposobu na przetestowanie go, poza czekaniem na koniec miesiąca i sprawdzeniem, czy skrypt został wykonany poprawnie (właściwie moim rozwiązaniem było znalezienie współ- pracownik, który dużo więcej wiedział o skrypcie cron i powłoce).

Jestem więc ciekawy, czy istnieją jakieś przydatne obejścia do testowania skryptów wrażliwych na czas.

Oprócz testów jednostkowych istnieją dwie inne strategie konfigurowania testów automatycznych w celu rozwiązania problemu specyficznego dla systemu operacyjnego:

• Wirtualizacja : Konfigurujesz kilka obrazów systemu operacyjnego (na przykład przy użyciu VMWare ) z dokładnie wymaganymi konfiguracjami, konfigurujesz sposób automatycznego pobierania pliku binarnego w celu przetestowania (zwykle przez zamontowanie specjalnego katalogu w przestrzeni maszyny wirtualnej), a następnie uruchom test.

Lub:

• Oprzyrządowanie : Ręcznie dodaj specjalne ifwarunki do swojego programu, które sprawią, że program będzie się zachowywał inaczej. W systemie Unix można to zrobić, sprawdzając, czy ustawiona jest pewna zmienna środowiskowa, np FOOBAR_TEST_TIME_WITH_T=500. Twoje zautomatyzowane testy użyją wtedy różnych ustawień zmiennych środowiskowych i różnych zmiennych środowiskowych, aby wykonać to, czego potrzebujesz.

Możesz również linkować do różnych bibliotek, jeśli twoje interakcje mogą być wyrażone na poziomie biblioteki, co możesz potraktować jako wirtualizację (jeśli „biblioteka” to jądro systemu operacyjnego) lub jako technikę instrumentacji. Można używać obu tych terminów, chociaż termin „wirtualizacja” używany dziś prawie zawsze oznacza coś w rodzaju VMWare. Biblioteka specjalnie do zwracania wartości standardowych lub ponownego uruchamiania określonych interakcji byłaby próbą próbną lub pośrednią .

Istnieją również automatyczne narzędzia instrumentacyjne, które mogą przepisać pliki binarne, aby uzyskać inne pożądane efekty, takie jak pełny system plików.

Ogólnie rzecz biorąc, Twoim celem jest znalezienie błędów. Aby sprawdzić, czy występują dziwne przypadki, takie jak przepełnienie systemu plików, najłatwiej i najskuteczniej jest po prostu ręcznie oprzyrządować program, rzadko podejmując trasę wirtualizacji lub ręcznej konfiguracji maszyny.

Najbardziej efektywny - zmień datę maszyny, na której testujesz. Ustaw go na chwilę przed uruchomieniem i sprawdź, kiedy się uruchamia i czy działa poprawnie. Nie zawsze jest to jednak możliwe, jeśli w grę wchodzi wiele maszyn lub jeśli wymagane są zasoby, na które firma nie ma kontroli. Upewnij się jednak, że robisz to przez wiele miesięcy, i upewnij się, że zmieniasz rok kilka razy, aby przetestować luty.

Nie wiem o twoim skrypcie, ale próbuję użyć jakiegoś parametru, w którym mogę ustawić datę. W twoim przypadku, jeśli nie podano daty, domyślnie do końca miesiąca. W swoim kodzie weź parametr date i uruchom, jeśli dzisiaj są dwa dni wcześniej. Nie tylko będziesz mógł go przetestować (podać datę za dwa dni), ale także uruchomić następnego dnia, na wypadek, gdyby coś uniemożliwiło jego uruchomienie w normalnych okolicznościach (awaria zasilania, wyłączenie serwera itp.).

Ponieważ wspomniałeś o crontabie, zakładam, że działasz w środowisku nix. W takim przypadku uważam, że warto poświęcić chwilę na sprawdzenie libfaketime:
http://www.code-wizards.com/projects/libfaketime/

Dzięki magii LD_PRELOAD możemy ładować niestandardowe wersje funkcji bibliotecznych, o ile są one zgodne z interfejsem. Libfaketime ładuje wersje wywołań systemowych czasu, które pozwalają dostosować ich zachowanie za pomocą zmiennych środowiskowych. Możesz zmusić time () do zwrócenia zakodowanej wartości lub przesunięcia w stosunku do bieżącego czasu, bez wpływu na innych.

Nie trzeba wiele testować crona, ponieważ jest on prawie testowany („test produkcyjny”) od wielu pokoleń. Oczywiście, jeśli pracujesz ze skryptem powłoki, możesz ustawić datę / godzinę na maszynie wirtualnej.

Preferowanym sposobem radzenia sobie z tym jest „kpienie z zegara”, przy użyciu jednej sztuczki programistycznej lub innej, aby sfałszować czas. W skryptach powłoki można użyć składni $ {: -}, aby użyć daty ustawionej w zmiennej środowiskowej i cofnąć się do rzeczywistego czasu, jeśli nie został on wymuszony.

W innych językach używamy fałszywych bibliotek lub budujemy abstrakcję przez całą dobę.

Zegar próbny jest dobry, ponieważ można go zautomatyzować zamiast ręcznie konfigurować test. Jest to bardzo duża korzyść, jeśli chodzi o późniejszą modyfikację skryptu / kodu i możesz łatwo stwierdzić, czy nadal działa, czy nie.