You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
📑 User Story: TDD Specification for Flashcard CRUD Operations
Value Proposition
As a Lead Developer / Test Engineer I want to define the test specifications for the remaining API methods (POST, PATCH, DELETE) In order to provide Elena and Karsten a clear roadmap and ensure high code quality through TDD.
Description
Nachdem die Testumgebung steht und die GET-Route stabil läuft, definieren wir nun die Anforderungen für die vollständige CRUD-Funktionalität.
Dieses Ticket beinhaltet das Schreiben von "roten" Tests (failing tests), die als technischer Vertrag für die kommende Implementierung dienen. Ziel ist es, dass Elena und Karsten lediglich den Code schreiben müssen, bis die von mir definierten Tests "grün" werden.
Acceptance Criteria
1. POST /api/flashcards (Erstellen)
Test: Liefert Status 201 und das erstellte Objekt bei validen Daten zurück.
Test: Liefert Status 400, wenn Pflichtfelder (question oder answer) im Body fehlen.
2. PATCH /api/flashcards/[id] (Update)
Test: Liefert Status 200 und das aktualisierte Objekt bei Erfolg.
Test: Liefert Status 404, wenn die ID nicht in der Datenbank existiert.
3. DELETE /api/flashcards/[id] (Löschen)
Test: Liefert Status 200 oder 204 nach erfolgreichem Löschen.
Test: Liefert Status 404, wenn die zu löschende ID nicht gefunden wurde.
4. Code Quality & Handover
Neue Tests werden mit it.todo() markiert oder in einem separaten Branch gepusht, um den main Branch stabil zu halten.
Kommentare im Test-Code geben Hinweise auf Mongoose-Besonderheiten (z.B. { new: true } bei Updates).
Tasks
Neuen Feature-Branch feature/api-tdd-specs erstellen.
flashcards.test.js um describe-Blöcke für POST, PATCH und DELETE erweitern.
Notwendige Mongoose-Methoden (create, findByIdAndUpdate, findByIdAndDelete) in der mock-factory vorbereiten.
Test-Logik (Arrange-Act-Assert) für jedes Szenario implementieren.
Failing Tests pushen und das Team (Elena & Karsten) informieren.
Note from the Test Engineer: > "Wir bauen hier die Leitplanken. Elena und Karsten müssen dann nur noch Gas geben, ohne aus der Kurve zu fliegen."
📑 User Story: TDD Specification for Flashcard CRUD Operations
Value Proposition
As a Lead Developer / Test Engineer
I want to define the test specifications for the remaining API methods (POST, PATCH, DELETE)
In order to provide Elena and Karsten a clear roadmap and ensure high code quality through TDD.
Description
Nachdem die Testumgebung steht und die
GET-Route stabil läuft, definieren wir nun die Anforderungen für die vollständige CRUD-Funktionalität.Dieses Ticket beinhaltet das Schreiben von "roten" Tests (failing tests), die als technischer Vertrag für die kommende Implementierung dienen. Ziel ist es, dass Elena und Karsten lediglich den Code schreiben müssen, bis die von mir definierten Tests "grün" werden.
Acceptance Criteria
1. POST /api/flashcards (Erstellen)
questionoderanswer) im Body fehlen.2. PATCH /api/flashcards/[id] (Update)
3. DELETE /api/flashcards/[id] (Löschen)
4. Code Quality & Handover
it.todo()markiert oder in einem separaten Branch gepusht, um denmainBranch stabil zu halten.{ new: true }bei Updates).Tasks
feature/api-tdd-specserstellen.flashcards.test.jsumdescribe-Blöcke für POST, PATCH und DELETE erweitern.create,findByIdAndUpdate,findByIdAndDelete) in dermock-factoryvorbereiten.