[RUBY] Erstellen Sie eine Bulletin Board-API mit Zertifizierungsberechtigung im Rails 6 # 7-Update und zerstören Sie die Implementierung

← Erstellen einer Bulletin Board-API mit Zertifizierungsberechtigung in Rails 6 # 6 zeigen, Implementierung erstellen

Implementierung des Update-Tests

Implementieren Sie die verbleibenden 2 Aktionen, aktualisieren und zerstören Sie sie.

Update ist ein Update-Prozess. Wenn Sie es erstellen können, ist es ähnlich, sodass es nicht hängen bleiben sollte.

spec/requests/v1/posts_controller.rb

...

+  describe "PUT /v1/posts#update" do
+    let(:update_param) do
+      post = create(:post)
+      update_param = attributes_for(:post, subject: "update_Probandentest", body: "update_Körpertest")
+      update_param[:id] = post.id
+      update_param
+    end
+    it "Der normale Antwortcode wird zurückgegeben" do
+      put v1_post_url({ id: update_param[:id] }), params: update_param
+      expect(response.status).to eq 200
+    end
+    it "subject,Körper kehrt korrekt zurück" do
+      put v1_post_url({ id: update_param[:id] }), params: update_param
+      json = JSON.parse(response.body)
+      expect(json["post"]["subject"]).to eq("update_Probandentest")
+      expect(json["post"]["body"]).to eq("update_Körpertest")
+    end
+    it "Fehler werden zurückgegeben, wenn der Parameter ungültig ist" do
+      put v1_post_url({ id: update_param[:id] }), params: { subject: "" }
+      json = JSON.parse(response.body)
+      expect(json.key?("errors")).to be true
+    end
+    it "Die Antwort 404 wird zurückgegeben, wenn die ID nicht vorhanden ist" do
+      put v1_post_url({ id: update_param[:id] + 1 }), params: update_param
+      expect(response.status).to eq 404
+    end
+  end
...

Wie üblich ist der Controller nicht implementiert, daher ist der Test Moos.

Implementierung des Updates

app/controllers/v1/posts_controller.rb

...

     def update
-      # TODO
+      if @post.update(post_params)
+        render json: { post: @post }
+      else
+        render json: { errors: @post.errors }
+      end
     end
...

Auch hier besteht keine Notwendigkeit, darüber zu sprechen. Dies sollte den Test bestehen.

Implementierung des Zerstörungstests

spec/requests/v1/posts_controller.rb

...

+  describe "DELETE /v1/posts#destroy" do
+    let(:delete_post) do
+      create(:post)
+    end
+    it "Der normale Antwortcode wird zurückgegeben" do
+      delete v1_post_url({ id: delete_post.id })
+      expect(response.status).to eq 200
+    end
+    it "Eins weniger und kehrt zurück" do
+      delete_post
+      expect do
+        delete v1_post_url({ id: delete_post.id })
+      end.to change { Post.count }.by(-1)
+    end
+    it "Die Antwort 404 wird zurückgegeben, wenn die ID nicht vorhanden ist" do
+      delete v1_post_url({ id: delete_post.id + 1 })
+      expect(response.status).to eq 404
+    end
+  end
...

Bestätigen Sie im Gegensatz zum Zeitpunkt der Veröffentlichung, dass die Anzahl der Datensätze im Hinrichtungstempel um 1 verringert wurde. Als Punkt, Es bedeutet, delete_post vor der Erwartung aufzurufen.

Wie bereits erwähnt, wird let verzögert ausgewertet. Wenn also vor "delete" kein "delete_post" vorhanden ist, wird ein Datensatz mit "delete_post.id" in "erwarten" erstellt und ein Datensatz mit "delete v1_post_url" gelöscht. Mit anderen Worten, + 1-1 = 0 im Erwartungsblock, und die Anzahl der Datensätze ändert sich nicht.

Daher wird ein Datensatz vor dem Erwarten generiert, und wenn das Löschen im Erwarten ausgeführt wird, wird er zum Datensatz -1.

Implementierung von zerstören

app/controllers/v1/posts_controller.rb

...

     def destroy
+      @post.destroy
+      render json: { post: @post }
     end
...

Das ist auch sehr einfach. Diesmal ist es kurz, aber wenn Sie den nächsten Samen hinzufügen, wird er zu lang, also ist es das.

Fortsetzung

→ Erstellen einer Bulletin Board-API mit Zertifizierungsberechtigung mit Rails 6 # 8-Seed-Implementierung

[Zur Serialisierungstabelle]