Toekomstig werk

[pdawyndt]

Toekomstig werk

[pdawyndt]

ontbrekende features voor TESTed

Dit is een oplijsting van nice to haves en ideeën uit andere judges.

• domeinspecifieke taal als frontend voor testplan (eventueel meerdere DSLs voor verschillende types oefeningen)
• aanbieden van oefeningen in meerdere natuurlijke talen
  • feedback aangepast aan geselecteerde natuurlijke taal
  • naamgeving aangepast aan geselecteerde natuurlijke taal
  • boilerplate aangepast aan geselecteerde natuurlijke taal (en programmeertaal)
• tijds- en geheugenmetingen (per context)
  • Tijds
  • Geheugen
• analyse van tijds- en geheugencomplexiteit (asynchroon: feedback wordt later toegevoegd)
  • Tijds
  • Geheugen
• pretty printing voor (samengestelde) types: lijsten, sets, dictionaries, files, 2-dimsionale lijsten (zie #350)
  • kan helpen bij het vergelijken van verwachte en gegenereerde resultaten (diff)
  • verkorte weergave van grote datastructuren (met mogelijkheid om die volledig te zien)
• statische code-analyse
  • introspection: examine classes, functions and keywords to know what they are, what they do and what they know (e.g. check if a function is defined recursively, check if for loop has been used, check if code contains at least three comment blocks) (zie #392)
• optionele contexten/testgevallen: als de context of het testgeval niet ondersteund wordt in een bepaalde programmeertaal, dan wordt die niet uitgevoerd, in plaats van meteen aan te geven dat de oefening de programmeertaal niet ondersteunt (zie #50)
• speciale soorten testgevallen:
  • testgevallen die niet getoond worden in de feedback (maar wel uitgevoerd)
  • testgevallen die niet uitgevoerd worden (maar wel getoond)
  • testgevallen waarvan het verwachte resultaat niet getoond wordt (om het antwoord niet weg te geven)
  • misschien worden bovenstaande enkel gebruikt om iets anders te tonen dan wat er uitgevoerd wordt
• compilatie eerst globaal (batchcompilatie), dan per tab (tabcompilatie - bestaat nog niet) en dan per context (contextcompilatie) uitvoeren; extra tussenstap levert tijdswinst op als bv. een functie niet geïmplementeerd werd (typisch getest in een afzonderlijke tab)
• bij het uitvoeren van de context zorgen dat de ingediende oplossing zo goed mogelijk afgeschermd wordt van:
  • andere testcode
  • bestanden voor TESTed en van andere contexten
• keten van partiële evaluatie (#43)
• parallelle uitvoer van beoordelingen, niet enkel van ingediende oplossingen
• parallelle uitvoering van alle contexten, niet enkel van contexten binnen eenzelfde tab (zie #329)
• alle beoordeelde contexten tonen, als status “niet beoordeeld” ondersteund wordt door Dodona (zie issue bij Dodona)
• linting parallel uitvoeren met testen van juistheid (en eventueel andere types checks) (zie #330)

[pdawyndt]

ontbrekende features voor Dodona

• beperking ondersteunde programmeertalen per oefening (liefst zoveel mogelijk geautomatiseerd, manueel door ontwikkelaar waar mogelijk)
• lesgever kan programmeertalen inperken (per cursus, reeks, oefening)
• gebruiker kan programmeertaal selecteren
• programmeertaal bijhouden per ingediende oplossing (voor opnieuw beoordelen, weergave en statistieken)
• natuurlijke taal bijhouden per ingediende oplossing (zelfde redenen als voor programmeertalen)
• aanpassen syntax highlighting van editor aan geselecteerde programmeertaal
• beschrijving van oefening past zich aan (e.g. terminologie gegevenstypes, voorbeelden) aan geselecteerde programmeertaal
• beschrijving van voorzieningen per programmeertaal (zou ook voor individuele judges nuttig zijn); oa. versie programmeertaal, oplijsting van beschikbare packages/libraries/modules, ... (eventueel ook OS voor judges); ik denk dat deze info voor alle gebruikers mag beschikbaar zijn (en uiteraard in alle ondersteunde natuurlijke talen)
• bij gebruik van het partieel outputformaat voor de feedback, de afgewerkte contexten zo snel mogelijk rapporteren aan gebruiker (interactievere gebruikerservaring)
• partieel outputformaat uitbreiden zodat een onderdeel van de feedback (tab, context, testgeval, test) later terug kan bezocht worden, bijvoorbeeld om bijkomende informatie toe te voegen; kan bijvoorbeeld geïmplementeerd worden door een optionele ID toe te voegen aan de onderdelen van de feedback
• dynamisch gegenereerde boilerplate voor een oefening op basis van gegeven natuurlijke taal en programmeertaal
• afzonderlijke threads voor verschillende types feedback (correctheid, linting, complexiteitsanalyse, ...); onderscheid maken tussen synchrone en asynchrone threads voor weergave feedback