Partiële evaluaties met orakel

[niknetniko]

Uit de e-mail:

Een speciaal geval is van geprogrammeerde evaluatie, die je een "orakel" zou kunnen noemen.
Voorbeeld: oefening waarbij de leeftijd van een persoon moet berekend worden (op vandaag), gegeven de geboortedatum van die persoon. Daarbij kan dus de verwachte waarde niet statisch in het testplan zitten, maar het kan wel berekend worden door een orakel. Dit orakel kan nu al vervat zitten in de geprogrammeerde evaluatie, maar het zou eventueel ook kunnen:

• ​berekend worden in het testplan (dynamisch testplan), dus voorafgaand aan het genereren van de testcode
• berekend worden door het orakel en geëvalueerd worden door TESTed als het resultaat een ondersteund datatype heeft (zoals in dit geval een integer); met andere woorden, de geprogrammeerde evaluatie bestaat er dan enkel in om op basis van de input (geboortedatum) de verwachte output (leeftijd) te genereren en die terug te geven aan TESTed, die dan op zijn beurt de gelijkheid van de verwachte waarde (gegenereerd door het orakel) en de gegenereerde waarde (door de ingediende oplossing) kan controleren

In die zin werkt het "orakel" eerder op dezelfde manier als de uitvoeringsomgeving, dan als de evaluatieomgeving, want ze moet enkel resultaten afleveren (hetzij voor integratie in het testplan of voor gebruik in de evaluatiestap van TESTed). Voor wie het testplan opstelt, zou dat betekenen dat een (deel van een) voorbeeldoplossing moet aangeleverd worden (in een programmeertaal die door TESTed ondersteund wordt.

[niknetniko]

Ik heb dit opgenomen als een alinea bij future work, bij een paragraaf over een ander mechanisme dat al beschreven staat in future work: het combineren van evaluatievormen.

Dat combineren bestaat er uit dat het mogelijk zou zijn om bijvoorbeeld een resultaat met meerdere evaluatiemethodes te evalueren, bijvoorbeeld gedeeltelijk met een geprogrammeerde evaluatie en gedeeltelijk met een ingebouwde evaluatie. Toon ik dit schreef in de tekst had ik een scenario als volgt in het hoofd: een functie die een Date-object als returnwaarde heeft. Dit kan niet geëvalueerd worden met een ingebouwde of zelfs geprogrammeerde evaluatie; dit moet met een programmeertaalspecifieke evaluator.

Bij het combineren zou het mogelijk zijn om bijvoorbeeld het Date-object met een programmeertaalspecifieke evaluator om te zetten naar een string (bijvoorbeeld in ISO-formaat), waarna TESTed die string wel kan evalueren en vergelijken met een verwachte waarde.

De orakelevaluatie past ook in het systeem van combinaties: hierbij wordt de verwachte waarde berekend door een programmeerde evaluator, waarna TESTed de verdere evaluatie doet.

Dit brengt mij bij de redenen dat ik het bij future work gezet heb:

• Het toevoegen van orakelevaluatie als afzonderlijk modus lijkt mij redelijk wat werk en vooral veel toegevoegde interne complexiteit aan TESTed, terwijl dat maar in een beperkt aantal gevallen gebruikt zal worden.
• Het implementeren van de combinaties is nog maar theoretisch; ik heb nog totaal niet nagedacht over hoe dat er zou moeten uitzien (in zowel testplan als evaluatiecode).

Bovendien is het zoals het al in de e-mail staat al mogelijk om dit te doen met een geprogrammeerde evaluatie (zowel de geproduceerde als verwachte waarde kunnen overschreven worden), zij het dat het wat meer werk zal zijn, omdat de volledige evaluatie dan in de geprogrammeerde evaluator zal moeten gebeuren.

[pdawyndt]

Combinatie kan er in bestaan dat verschillende "uitvoerkanalen" door verschillende componenten van TESTed geëvalueerd worden. Bv. returnwaarde in een geprogrammeerde evaluatie en aangemaakte bestanden en resultaat op stdout door TESTed zelf. Of kan dat nu al?

[pdawyndt]

Zou een gedeelde evaluatie van verschillende componenten zoals je die hierboven beschrijft, kunnen geïmplementeerd worden als het dynamisch herschrijven van het testplan?

[niknetniko]

Combinatie kan er in bestaan dat verschillende "uitvoerkanalen" door verschillende componenten van TESTed geëvalueerd worden. Bv. returnwaarde in een geprogrammeerde evaluatie en aangemaakte bestanden en resultaat op stdout door TESTed zelf. Of kan dat nu al?

Dit kan nu al, de evaluators worden per test gespecificeerd en een test is voor één uitvoerkanaal.
Ik bedoel het gebruiken van meerdere evaluatoren voor hetzelfde uitvoerkanaal.

Zou een gedeelde evaluatie van verschillende componenten zoals je die hierboven beschrijft, kunnen geïmplementeerd worden als het dynamisch herschrijven van het testplan?

Die twee zaken (combinaties van evaluatoren en het dynamisch testplan) zullen zeker invloed hebben op elkaar: in het dynamisch testplan willen we misschien mogelijk maken dat een evaluator beslist over het verdere verloop van het testplan (e.g. mag nu gestopt worden of niet, hoeveel keer moet de testcase nog uitgevoerd worden).
Ik denk wel niet dat een van beide voldoende is om de andere overbodig te maken. Bijvoorbeeld een dynamischer testplan alleen maakt bijvoorbeeld de orakelevaluatie niet mogelijk.

[pdawyndt]

Voorstel van combinatie keten van partiële evaluaties, met orakel:

1. orakel (vult selectie van verwachte waarden aan in testplan; zelfde context als bij ingediende oplossing, eigen generatie van testcode, eigen verzameling van resultaten (Partiële evaluaties met orakel #43); moet dus uitgevoerd worden voor het uitvoeren van de context voor de ingediende oplossing
2. programmertaalspecifieke evaluatie: status + massages + verwachte’/gegenereerde’ uitvoer uitvoer (kan tijdens evaluatie omgezet worden)
3. geprogrammeerde evaluatie: status + massages + verwachte’’/gegenereerde’’ uitvoer
4. generieke evaluatie: status + massages + verwachte’’’/gegenereerde’’’ uitvoer

Stappen 1, 2 en 3 zijn optioneel. Elke stap krijgt resultaten van vorige stap door, en kan die dus gebruiken en/of overschrijven. Als status al bepaald is in een stap, dan worden volgende stappen niet meer uitgevoerd en kan feedback gegenereerd worden. Eventueel ook nog een extra generieke evaluatie tussen stappen 2 en 3 toelaten. Stap 4 uitsplitsen in evaluatie van type en inhoud.

[pdawyndt]

Orakel kan generiek zijn (als resultaat kan gesteriliseerd worden om in het testplan opgenomen te worden), of programmeertaalspecifiek (waardoor voor elke ondersteunde programmeertaal een orakel moet geschreven worden).