トラブル切り分けの成功時に何をやったのかの記録～formの送信先間違えてたよ編～

#前置き
最近Djangoアプリの開発を趣味でやっています。
初心者につき、トライ１に対してエラー１０くらいの試行錯誤中で、なかなか完成しないですが
本日2021年11月3日、文化の日は丸一日エラーと向き合っていたのでせっかくなので記録しておくことにしました。
自己満足記事かつQiitaの投稿テストも兼ねています

#事象
メニューの自動化アプリを作っていますが、メニューの作成の際に
ModelFormのsave()メソッドが何をやっても効かない。
一方でサインアップで使うユーザーの方のsave()メソッドは正常に作動する。

#予定していた処理の流れ
１．ユーザーがログイン状態でメニュー登録画面に移動
２．リクエストがGETであればテンプレートでハンドリングしてform.as_pでメニューのフォームを出す(urls.py->views.py->templates/myapp/menu_settings_create.html)
３．ユーザーが入力して送信ボタンを押すとviews側で受けてDBに登録し、登録完了画面にページ遷移する

#やったこと
##ググって同様の事例がないか確認
キーワード「Django Modelform save できない」とかでググってみた。
同様の事例は見当たらなかった。

##同様の処理でうまくいっている箇所との比較確認
これに数時間かけたが、同じ書き方にしても何故かできない。

##送信データの確認

POSTで送っているデータそのものがおかしい可能性を考えた。
そうなったときにDjango側でどう確認すればよいのかわからなかったのとWireshark覚えたてで使いたかったのでWiresharkを使用。
予想に反してPOSTでちゃんとデータが送れていた。(画像の下半分の"testgohan3"のところ)

##受信側DBの確認
DBの受信している箇所をロギングしてみた。
この人の記事を参考にしてみた。
https://qiita.com/fumihiko-hidaka/items/0f619749580da5ad9ce5

画像は最終的にうまくいったときのものだが、デフォルトでこのようにrunserverしてあるターミナルの標準エラー出力にDB書き込み時のログが出るようになる。（それとmanage.py shell実施時にも出る）

そして確認の結果、このログが問題の箇所では出ていない事がわかった。
すなわち、POSTしているデータは正しいのだが、DBに書き込み処理が走っていない事がわかった。

##POST送信指定箇所の確認
views.pyは穴があくほど確認していたが、テンプレートのhtmlの方の確認があまりできていなかった。
そして、formactionの指定先がviewsで受ける宛先と異なっていることに気づいたので、修正

#結果
formactionの指定をviewsで受ける宛先と同じにしてうまくいった。

#まとめ
凡ミスではあったが、アプリ開発のコードは量が多いゆえ色々と見落としが発生するのも仕方ない。
焦らずに一個一個確認していくことが大事。
（本当は凡ミスをしないのが一番良い）