Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- howto:git:classroom50:bewertung [2026/08/17 08:51] – Sync aus BZZ-Commons/pygrader50 (v2.1.2) admin
+++ howto:git:classroom50:bewertung [2026/08/25 10:06] (aktuell) – Veraltet - Inhalt jetzt unter github.com/BZZ-Commons/pygrader50/docs admin
@@ Zeile 1: / Zeile 1: @@
-====== Classroom 50: Wie bewertet wird ======
-Die Bewertung macht [[https://github.com/BZZ-Commons/pygrader50|pygrader50]] —
-pytest für die Funktion, pylint für den Stil. Beides zählt zur Note.
-===== Die drei Konfigurationsdateien =====
-Format wie bisher in den BZZ-Templates, es ändert sich nichts am Inhalt:
-^ Datei ^ Inhalt ^
-| ''unittests.json'' | welche Tests laufen, mit Timeout und Punkten |
-| ''lint.json'' | welche Dateien gelintet werden und wie viele Punkte das gibt |
-| ''pylintrc'' | pylint-Konfiguration |
-<code javascript unittests.json>
-[
-  { "name": "test_ggt", "function": "test_ggt", "timeout": 10, "points": 2 }
-]
-</code>
-<code javascript lint.json>
-{ "files": ["main.py"], "ignore": [], "max": 5 }
-</code>
-Vorlage: [[https://github.com/BZZ-Commons/pygrader50/tree/main/examples/bundle|examples/bundle]]
-im pygrader50-Repository.
-===== Wo die Dateien gesucht werden =====
-**Pro Datei**, in dieser Reihenfolge:
-  - ''<CLASSROOM>/autograders/<SLUG>/'' im Config-Repo (das //Bundle//). Von der Lehrperson kontrolliert, für Lernende nicht editierbar.
-  - ''.github/autograding/'' im Studi-Repo. Der bisherige Ort, bleibt als Fallback.
-  - ''$PYGRADER50_CONFIG_DIR'' — nur für lokale Entwicklung.
-Fehlt beides, wird eine **0/0**-Abgabe aufgezeichnet und im Log gewarnt. Der Job
-wird dabei absichtlich nicht rot: Eine Aufgabe ohne hinterlegte Bewertung ist ein
-Konfigurationsstand, kein Infrastrukturfehler.
-<WRAP center round tip 90%>
-Der Fallback auf ''.github/autograding/'' erlaubt einen Rollout in Ruhe: Die
-Templates funktionieren unverändert weiter, während die Bundles nach und nach
-ins Config-Repo wandern.
-</WRAP>
-==== Ein Bundle anlegen ====
-<code>
-classroom50/
-└── <CLASSROOM>/
-    └── autograders/
-        └── <SLUG>/
-            ├── unittests.json
-            ├── lint.json
-            └── pylintrc
-</code>
-Nach dem Push bündelt der Workflow ''publish-pages'' den Ordner zu
-''autograders/<SLUG>.tar.gz''; der Runner entpackt ihn und pygrader50 liest von
-dort.
-<WRAP center round important 90%>
-**Kein ''autograder.py'' und keine ''tests.json'' in diesen Ordner legen.**
-Beides hat Vorrang vor dem Klassen-Default und würde damit die BZZ-Bewertung —
-und insbesondere das Linting — für diese Aufgabe abschalten.
-</WRAP>
-===== Punkte =====
-==== Unittests ====
-Ein Eintrag pro Testfall. ''passed'' heisst: volle Punktzahl erreicht. Jeder
-Fall läuft als **eigener** pytest-Aufruf mit eigenem Timeout, damit ein
-hängender Test die übrigen nicht mitreisst.
-==== Linting ====
-Ein einziger Eintrag ''Linting'':
-<code>
-Punkte = pylint-Note / 10 * max
-passed = Punkte > 0
-</code>
-Eine Konventionsmeldung kostet also **Punkte**, färbt den Commit-Status aber
-nicht rot. Ohne diese Regel wäre praktisch jeder Commit rot.
-Bei wenigen Statements und einem ''E…''-Fehler wird die pylint-Note negativ und
-auf 0 geklemmt. ''Linting: 0'' ist in dem Fall korrekt, kein Defekt.
-==== Rundung ====
-''result.json'' verlangt **ganze Zahlen**, es wird gerundet. Der exakte Wert
-steht im Feedback-Text.
-===== Beispiel-Feedback =====
-<code>
-### classroom50 autograde: 0/7
-## Unittests
-| name     | feedback        | expected | actual | points | max |
-| -------- | --------------- | -------- | ------ | ------ | --- |
-| test_ggt | Assertion Error | 8        | None   | 0      | 2   |
-**0.00/2.00 Points (0.00%)**
-</code>
-Die Spalten //expected// und //actual// stammen aus dem pytest-Hook
-''pytest_assertrepr_compare'', der vor dem Lauf ins Checkout kopiert wird.
-===== Warum nicht die deklarativen Tests von Classroom 50 =====
-Classroom 50 bringt mit ''tests.json'' einen deklarativen Weg mit. Die BZZ
-benutzt ihn bewusst nicht:
-  * Der Runner löst eine aufgaben-eigene ''tests.json'' **vor** dem Klassen-Default auf. Eine Aufgabe mit deklarativen Tests bekommt also kein Linting mehr.
-  * Im deklarativen Pfad wäre entweder die proportionale Lint-Note **oder** der grüne Commit-Status zu haben, nie beides: Der Interpreter setzt ''success'' nur, wenn //alle// Zeilen ''passed'' sind, und vergibt das Flag selbst.
-Pro Aufgabe lässt sich beides nicht mischen — pro Klasse schon. Deshalb stehen
-alle Aufgaben auf ''"autograder": "default"''.
-===== Was pygrader50 bewusst nicht tut =====
-  * **Keine Zusatzfelder in ''result.json''.** CLI und Dashboard von Classroom 50 parsen strikt; alles Menschenlesbare gehört in den Release-Text.
-  * **Kein ''$GITHUB_OUTPUT''.** Status und Zusammenfassung leitet der Runner selbst aus ''result.json'' ab — ein Kanal weniger, der auseinanderlaufen kann.
-  * **Kein ''pip install -r requirements.txt''** aus dem Studi-Repo. pygrader50 bringt eigene Abhängigkeiten mit, exakt gepinnt in seiner ''pyproject.toml''. Das hält die Bewertung reproduzierbar: eine neue pylint-Version verschiebt die Lint-Punkte erst, wenn jemand den Pin hochzieht und einen neuen Tag setzt.
-===== Lokal ausprobieren =====
-<code bash>
-cd /pfad/zum/studi-repo
-CLASSROOM=<CLASSROOM> \
-ASSIGNMENT=<SLUG> \
-SUBMISSION_TAG=submit/2026-08-13T12-00-00Z-abc1234 \
-OWNER=anna \
-python -m pygrader50
-cat release-body.md
-</code>
-Ohne ''RUNNER_TEMP'' entfällt die Bundle-Suche, es zählt also
-''.github/autograding/'' im Checkout. Details: [[.:cli|CLI-Referenz]].