Strategia testowania (i wybór edge case'ów)

Przypuśćmy, że mamy do zrobienia system do cyklicznego sprawdzania (i zapisywania) jakichś transakcji z zewnętrznego serwisu (np. systemu bankowego).

  1. Transakcje są zapisywane w kolejności, w jakiej są tworzone i generalnie jest to struktura listy, można pobrać X elementów, zaczynając od Y-tego (;)) elementu (zerowy element to najnowsza transakcja).
  2. Transakcje są różnych typów (przychodzące, wychodzące) i nie ma możliwości filtrowania.
  3. Każda transakcja ma swój unikalny ID (TXID) oraz czas.
  4. Każda transakcja ma też pole tzw. potwierdzeń (w skrócie mówiąc co jakiś czas jest sprawdzana poprawność tej transakcji, że nie jest to jakiś przekręt typu podwójnie wydana kwota), przyjmuje się, że transakcja nabiera ważności po np. 6 potwierdzeniach).

Ogólnie algorytm byłby taki:

  • zaczynając od początku listy odczytuj kolejne elementy po jednym,
  • jeśli element jest odpowiedniego typu i ma odpowiednią ilość potwierdzeń - zapisz do bazy,
  • kontynuuj, dopóki nie napotkasz elementu spełniającego warunek stopu (żeby za każdym razem nie przelatywać do końca listy).

I teraz 2 problemy:

  1. Jaki będzie najlepszy warunek stopu? Pierwsze naiwne rozwiązanie to: za każdym razem jak napotkasz pasujący, niezapisany element to zapisz, jako warunek stopu użyj ostatnie zapisane TXID. Przy tym rozwiązaniu może się okazać, że po pierwsze nie zapiszemy niektórych transakcji, po drugie - czasem się zdarzy transakcja podwójnie zaksięgowana.

  2. Jakie przypadki (kombinacje transakcji na liście) testować? Takie oczywiste to pusta lista, listy z pojedynczymi transakcjami (jedna nie takiego typu, jedna bez potwierdzeń, jedna już wcześniej zapisana, jedna nowa). Ale co dalej? Bo można sobie testować różne kombinacje po 2, 3, 4 transakcje i robi się tego naprawdę dużo, nawet eliminując pewne niemożliwe przypadki (jak to, że np. wcześniej na liście pojawi się transakcja z 6 potwierdzeniami a po niej taka z 1 czy 2).