Tip of the day: testiranje

Nekada na važnim natjecanjima nije bilo full feedbacka pa smo nervozno čekali rezultate tumarajući po hodnicima, koji su uglavnom dolazili isprintani (rezultati, ne hodnici) za svakog natjecatelja posebno – ishodi po pojedinim primjerima. I danas je slična situacija na županijskom i na HONI-ju gdje nema feedbacka, ali nekada je tako bilo i na državnom (koje se zvalo DMIH), na HIO-u, IOI-u i svugdje. Full feedback pojavio se, ako se ne varam, na IOI-u 2010. Na CEOI-u 2013. u Primoštenu još uvijek ga nije bilo, a na državnom je uveden 2015. gdje je ključnu ulogu odigrao Ante Đerek, između ostalog motiviran e-mail prepiskom nakon žalbi sa županijskog. U jednom od tih mailova Stjepan Glavina napisao je poznatu rečenicu: “Tradicionalni tip natjecanja mora nestati.”

Ovakvi incidenti su razlog zašto mislim da tradicionalni tip natjecanja (HONI, državno, CEOI, IOI prije 2010.) mora nestati. A nisam jedini koji tako misli [1]. Bodovanje je vrlo nepravedno. “Manje” kriva rješenja znaju dobivat više bodova od “više” krivih. Zna se desit i da točna rješenja s malim bugom dobiju manje bodova od potpuno krivih, ili čak nula bodova. Faktor (ne)sreće je prevelik. Drame s bugovima se događaju na svakom takvom natjecanju.

Prije full feedbacka, testiranje rješenja “s brutforsom i generatorom” bila je standardna stvar koju su jači natjecatelji tijekom natjecanja radili na svim zadatcima gdje je to imalo smisla. Jednom sam komentirao da nerado testiram jer volim misliti da sam riješio zadatak, barem tih nekoliko sati, umjesto da si testiranjem srušim rješenje. “Kurdija, to je i ideja”, odgovorio mi je Žužić odmahujući glavom u nevjerici.

Full feedback ima i određenih mana. Neki misle da je njime djelomično izgubljen važan dio natjecanja – spomenuto testiranje, te da rezultati dobiveni odmah “na pladnju” nisu nešto što je inače realno. S organizacijske strane ima više posla – zadatci moraju biti teži nego inače (jer natjecatelji zbog feedbacka troše manje vremena i manje griješe), s više parcijala da se dobije dobra disperzija bodova (koja se prije lakše dobivala zbog raznih neotkrivenih bugova), a greška u evaluaciji ili testnim primjerima košta više nego prije jer utječe na tijek natjecanja.

Osim na onim natjecanjima gdje još uvijek nema feedbacka (mislim da i Codeforces ulazi u tu kategoriju), danas testiranje koristimo i onda kada nam evaluator kaže da rješenje ne valja, ali ne znamo zašto pa moramo naći primjer na kojemu pada. Errichto dobro objašnjava kako se to radi:


Ugrubo i sažeto, evo bash skripte kakvu sam nekada koristio (njegova je malo drugačija):

echo > o1  # napravi prazan prvi output
echo > o2  # napravi prazan drugi output
while diff o1 o2; do     # dok su outputi jednaki
    ./gen.py > t         # generiraj random primjer t
    ./test.exe < t > o1  # o1 = rjesenje(t)
    ./brute.exe < t > o2 # o2 = brutfors(t)
    printf '.'           # ispisi tocku za svaki testirani primjer
done

Poziva se iz Linux terminala:

bash testiraj.sh

… ili (nakon postavljanja chmod +x testiraj.sh):

./testiraj.sh

Update: sad uočavam da sam riječ testiranje u dvama nedavnim postovima (ovom i ovom) koristio u značenju evaluacija tj. isprobavanje na službenim testnim primjerima, dok se u ovom postu testiranje odnosi na stress-testing rješenja za vrijeme natjecanja kada službeni testni primjeri još nisu dostupni. Tu dvoznačnost mogao bih otkloniti tako da u prethodnim postovima svugdje napišem evaluirati umjesto testirati, ali to mi se ne da i vjerojatno je i ovako jasno o čemu se radi.

Jedna misao o “Tip of the day: testiranje

Komentiraj

Popunite niže tražene podatke ili kliknite na neku od ikona za prijavu:

WordPress.com Logo

Ovaj komentar pišete koristeći vaš WordPress.com račun. Odjava /  Izmijeni )

Google photo

Ovaj komentar pišete koristeći vaš Google račun. Odjava /  Izmijeni )

Twitter picture

Ovaj komentar pišete koristeći vaš Twitter račun. Odjava /  Izmijeni )

Facebook slika

Ovaj komentar pišete koristeći vaš Facebook račun. Odjava /  Izmijeni )

Spajanje na %s