DynamicRChecker (Jack2)
Beschreibung
Der DynamicRChecker dient dazu, den vom Studierenden erzeugten Output mit dem erwarteten Output zu vergleichen. Dazu wird innerhalb des Checkers ein Testfall definiert, in dem der Code hinterlegt wird, der den zu erwarteten richtigen Output generiert. Dieser wird dann nach der Einreichung des Studierenden mit dem, vom Code des Studierenden, generierten Output verglichen. Optional kann je nach Bedarf der vom Studierenden übergebene Output über eine sog. postprocessingFunction
modifiziert werden.
Der Post Code
Grundsätzlich ist es möglich, benutzerdefinierten Post Code in Aufgaben zu hinterlegen. Über den Tag postCode
können dazu entsprechende Funktionen definiert werden. Die wichtigsten Anwendungsfelder zur Verwendung von Post Code sind:
- Code über mehr als eine Zeile: Ist der Code im Tag
expectedOutput
länger als eine Zeile - Postprocess-Funktion: Soll der vom Studierenden übergebene Output modifiziert werden, muss eine sog. Postprocess-Funktion definiert werden. Dazu wird innerhalb des Tags
postCode
eine Funktion mit dem Namenpostprocess
definiert, in der die benötigte Modifikation deklariert wird. Zusätzlich muss im
Die Tags der DynamicChecker-Datei
- metaInf:
- numberOfInputArgs: Anzahl an Input-Argumenten (in der Regel
1
) - outputType: Output-Typ (in der Regel
double
) - preCode: Hier steht immer
testFunc <- function(){
. - postCode: Unter diesem Tag wird, wenn benötigt, der Post Code definiert. Dazu können hinter
}
die benötigten Funktionen definiert werden.
- numberOfInputArgs: Anzahl an Input-Argumenten (in der Regel
- testcases: Hier können verschiedene Testfälle definiert werden.
- testcase: Innerhalb dieses Tags ist der entsprechende Testfall zu definieren.
- feedback:
- postprocessingFunction (optional): Wird eine postprocess-Funktion benötigt, so ist hier postprocess (= der Name der Funktion) einzutragen
- input:
- penalty: Die Anzahl an Punkten, die beim falschen Lösen der Aufgabe abgezogen werden sollen.
- expectedOutput: Hier sollte der R-Code hinterlegt werden, der genau den R-Output ausgibt, der vom Studierenden erwartet wird. Es können auch Zufallszahlen, die in der exercise-Datei definiert wurden, innerhalb dessen verwendet werden.
- errorFeedback: Hier kann ggf. Feedback angegeben werden, wenn die eingereichte Lösung des Studierenden als falsch evaluiert wird.
- ...: Wenn nötig, können hier weitere Testfälle definiert werden.
- testcase: Innerhalb dieses Tags ist der entsprechende Testfall zu definieren.
Beispiele
Beispiel 1
Im vorliegenden Beispiel wird exemplarisch eine postprocess-Funktion definiert. Diese wählt den ersten Eintrag des vom Studierenden übergebenden R-Objekts aus, wandelt es in die Klasse numeric
um und rundet es auf den ganzzahligen Teil herunter.
XML-Datei
<?xml version="1.0" encoding="iso-8859-1"?>
<checkerconfiguration>
<metaInf>
<numberOfInputArgs>1</numberOfInputArgs>
<outputType>double</outputType>
<preCode>testFunc <- function(){</preCode>
<postCode>}
postprocess <- function(w){
round(as.numeric(w[1]))
}</postCode>
</metaInf>
<testcases>
<testcase>
<feedback></feedback>
<postprocessingFunction>postprocess</postprocessingFunction>
<input></input>
<penalty>100</penalty>
<expectedOutput>1</expectedOutput>
<errorFeedback>Leider nicht richtig!</errorFeedback>
</testcase>
</testcases>
</checkerconfiguration>