test-driven-developmentlisted

Testgetriebenes Vorgehen als Voreinstellung für alle Softwareprojekte dieses Nutzers: erst den Test bauen und ihn rot nachweisen, dann die Funktionalität — immer zwei Runden, nie eine. Auch dann, wenn der Test in der eigenen Umgebung gar nicht ausgeführt werden kann; dann wird der Rot-Nachweis ausdrücklich angefordert. Enthält außerdem, wie eine bestehende Testsuite per Mutationstest auf ihre Wirksamkeit geprüft wird und wie man Tests baut, die nicht denselben blinden Fleck haben wie der Code. Nutze diesen Skill bei jeder neuen Funktion, bei jedem gemeldeten Fehler, bevor du eine Zeile Produktivcode schreibst, und wenn zu klären ist, ob ein bestehender Test überhaupt etwas prüft.
f-reiser/claude-skills · ★ 0 · Testing & QA · score 72

Install: claude install-skill f-reiser/claude-skills

# Testgetrieben arbeiten Voreinstellung für alle Softwareprojekte dieses Nutzers. Immer ZWEI Runden, nie eine. ## Runde 1 — der Test, und der Nachweis, dass er rot ist 1. Verstehen, was die Funktion leisten soll (bzw. was der gemeldete Fehler ist). 2. Den Test schreiben, der genau das prüft. 3. **Den Test rot sehen.** Nicht vermuten, dass er rot wäre — laufen lassen. 4. Erst melden „Test steht und schlägt fehl", dann weiter. Ohne Schritt 3 ist der Test wertlos. Ein Test, der noch nie rot war, prüft möglicherweise gar nichts. ### Wenn die Umgebung fehlt Manchmal lässt sich der Test hier nicht ausführen — Excel/VBA, eine proprietäre Toolchain, Hardware, eine fremde Cloud. Dann **nicht stillschweigend weiterbauen**, sondern: - den Test ausliefern, - ausdrücklich schreiben, **welcher** Test **mit welcher Meldung** fehlschlagen MUSS, - den Nutzer den Rot-Nachweis führen lassen und auf sein Ergebnis warten, - erst danach die Funktionalität bauen. Will der Nutzer den Zwischenschritt nicht, sagt er das — dann beides in einem Aufwasch, aber mit der Erwartung ausdrücklich dokumentiert. ## Runde 2 — die Funktionalität So lange bauen, bis der Test grün ist. **Nicht den Test anpassen, damit er passt.** War der Test falsch, ist das ein eigener Befund und wird als solcher benannt. ## Bei einem gemeldeten Fehler Dieselbe Reihenfolge, verschärft: zuerst die Prüfung schreiben, die den Fehler **am echten Artefakt des Nutzers** rot macht — seiner Datei, seinem Datensatz, seinem Log.