20210213・14_アウトプット（オリジナルアプリ／テスト駆動開発／イフゼンルールの実装）
2/13行ったこと 10時間30分
昨日のアウトプット...1時間40分
和田卓人さんの動画を見て「テスト駆動開発」の意味を履き違えていたことに気づけた…50分
テスト駆動開発を実践しながらイフゼンルールの実装…8時間
👉7割くらい進んだ。アソシエーションしたら保存されなくなった💦（何故😭）
2/14行ったこと 11時間35分
引き続きテスト駆動開発をしながらのイフゼンルールの実装…9時間35分
👉できたー！！！（嬉しい）ランディングページ…2時間
新しい発見について（テスト駆動開発）
↓和田卓人さんのこの動画をたまたま朝見つけて視聴。
（分かりやすく、勘違いに気づけたため、見て本当によかった✨😣）
動作する、きれいなコードへ
50 分でわかるテスト駆動開発資料より（和田卓人さん）
「動作する、きれいなコード」をゴールとした時に２つの道がある。
左上を通るルートだと「（コードは動くかまだわからないけれど）きれいに書こう」と考えて進める形。右下を通るルートだと「あとで綺麗にしよう、とりあえず動くようにしよう」と考えて進める形。私は後者のルートで今まで進めていたことに気がついた。
そして和田さんのおっしゃる通り「あとで綺麗にしよう、とりあえず動くようにしよう」で進めた際に、「後できれいにすることはない」呪いはその通りだと思った。涙
何故ならば、和田さんのおっしゃる通り、上記で作っているとリファクタリング時に「動かなくなるかもしれない」という恐怖でコードを書き換えることができないため。
でも、昨日のテクニカルなコードで記述できるんだと感動を覚えたこともあり、冗長なコードではなく、きれいに書けるようになりたいと思った。
この恐れを解消してくれるのがテスト駆動開発と知った。
テスト駆動開発をする流れ
50 分でわかるテスト駆動開発の資料より（和田卓人さん）
ついつい「動く」ことに注力してしまい、後回しになってしまいがちなリファクタリング。
「リファクタリングは繊細」という言葉が印象に残った。非常に大事なのにも関わらず、後回しにされがちなため。
テスト駆動開発とは、上記の図の通り「レッド🔴」→「グリーン🟢」→「リファクタリング🟠」の回転を、機能ごとに進めることと理解。
黄金のサイクル
50 分でわかるテスト駆動開発の資料より（和田卓人さん）
テスト駆動開発は以下の黄金サイクルだと理解。
（１） その実装において達成したいことは何か？（一つずつ見極めて、実装する）
（２） その実装を想定したテストを記述。（まだ実装していないので「レッド🔴」になる）
（３）テストをクリア出来るよう（つまり動くよう）実装する。（グリーン🟢）
（４）クリア出来るようになったら、リファクタリングをする。（リファクタリングしてもテストが通るようにする。🟠）
👉動作するきれいなコードで一つの機能の完成！（１）に戻り、次の機能へ。
実際のデモ
50 分でわかるテスト駆動開発の資料より（和田卓人さん）
正常系と純正常系がある。（今回で言えば、数字を返すことが正常系で、３と５の場合には特定の値で返すのが純正常系）
文字から必要な要件を抽出し、優先順位を決める。
文字通りの実装とは限らないため、本当に実装したいことは何なのか言葉の意図を捉える。（今回で言えば「返す」とは最後にプリントすることだ、等仕様に落とし込むということ）
予想通り落ちることも大事（そのことによって、テストがまず通っていて正しいことが証明できるため。）
今何をやっているのか明確にするだけでなく、テストコードのテストがきちんと仕留められているかの確認もできる。
仕様を示すなら日本語でOK。分かりやすさが一番。（検証→実行→前準備だと、ギアを下げることが出来る）
仕様からテストコードの意図がわかるように実装する。
テストは増やすことより減らすことの方が１００倍難しい。（テストコードを作る人は、必要最小限に減らす責任がある。）
TDDのメリットとして、テストを書くには要素の粒度も考えないといけないため、結果としてコミットの粒度が揃えられる。
自分なりにいざ実践！
オリジナルアプリで試してみよう。
習慣カウントにおいて、イフゼンルールを設定できることは「これがないとアプリとして成り立たない」と考える要素の１つであった。
しかし、カリキュラムで習った内容ではないため、どう実装したらいいのか分からなくて（以前も失敗して）チャレンジの実装だった。
TODOに落とし込む
達成したいこと
イフゼンルール（それぞれ１２文字以内）投稿・編集することができ、データベースに保存できること。
保存した内容を習慣カウントのページで見ることができること。
当初考えた仕様
遷移（新規作成）
習慣カウントのページからイフゼンルールを投稿できる画面に遷移できること
食事、睡眠、運動、学び、マインドごとに入力ができること
それらのルールが保存されること（保存されない場合には入力画面のままになること）
保存されると、習慣カウントページにいくこと
習慣カウントページでは保存したカレントユーザーのイフゼンルールが表示されていること
遷移（編集）
習慣カウントページからイフゼンルールを投稿できる画面に遷移できること
投稿時のデータが残っていること
それらのルールの一部を編集し更新できること（更新されない場合には入力画面のままになること）
更新されると、習慣カウントページにいくこと
習慣カウントページでは、更新後のイフゼンルールが表示されていること
保存
表示されるスペースに限りがあるので１２文字以内で保存すること（１３文字以上はエラー）
ユーザーIDも保存していること
TODOに落とし込んだあと、実際に行ってみた仕様の順番（一つ一つテストが出来るか確認しながら実装し、コミットした内容）
習慣カウントのページから習慣カウントページへ遷移できるよう編集。
イフゼンルールを入力し、DBへ保存できるよう実装。
12文字以内でイフゼンルールが設定するよう（バリデーションがかかるよう）実装。
イフゼンルールについて空だと保存できないよう（バリデーションがかかるよう）実装。
イフゼンルールをhabitsページに反映させるよう実装。（イフゼンルールを入力しないとhabitsページでnilエラーが出ることが判明したため、ログイン後、まずイフゼンルールを設定してから、習慣カウントページへ行くように仕様変更を行った。）
新規登録後は設定ページへ、ログイン後は編集ページへ遷移できるよう実装。
実装に苦慮したところ
上記の５が上手くいかなくて苦慮した！！！😭
上手くいかなかったこと：その１
アソシエーションを組み、インスタンス変数を使って他のビューに表示させたい。
データベースに保存する必要はないのに「保存不可」とエラーになってしまう。
その１：解決策
belongs_to :habit, optional: trueのoptional: trueが必要だったー！「運び方」に必死で、「運ばない」と明示する思考に至らなかった！
オプション知っていたのに出てこなかった！なるほどー😭
上手くいかなかったこと：その２
無事に、習慣カウントページに反映できるようになった！
なのに、テストコードを実行するとログインしたタイミングでエラーになってしまう。
その２：解決策
反映されているにも関わらずテストコードでエラーが起きる背景として、テストコードと開発環境のDBは別だったことを知った！！！
環境開発のDBと同じにしたら、全く同じエラーが出た。
テストコードが通らない＝実際のブラウザでも上手くいかないことを実感できた。テストコード恐るべし。
また、エラーに苦しんだけど、結果ひっかかると言うことは、きちんとテストコードに捉えられていたんだなと嬉しかった。
実装にテスト駆動開発を意識してやってみて、感じたこと
メリット
無駄なコメントアウトが減る（次のコミット時に使うかも・・と心配で残してしまっていた。いらないコメントを消すことも大事な一つだと思うのでリファクタリングがちょっと前進！３〜５ヶ月後にはテクニカルなコードにリファクタリング出来るようになりたいと思った）
心配性な自分にとって安心しながら進められる（ここまではテスト通っている！という確証を持てるため）
無駄な「どこでバグ起きたんだっけ？」と戻ることが減った（一つずやっているため）
「これテストコードの実力身につけたらめっっちゃ楽しいやつ！」と感じた。
ゲーム感覚になる（レッドグリーンリファクタリング通った！嬉しい！よし次！）
コミットの内容が分かりやすい。（１コミットでどの機能まで出来たのか明確になった。今までは〇〇の作成というような自分の主観でコミットしており、結果「それいらなかったわ〜」ってなるとリザーブや
rails dで削除を行うという汚いコミット履歴だった・・）
デメリット
- そもそもこれを仕様に落とした際のテストコードって・・？と時間がかかる。 👉でもこれは身につけられれば仕様をきちんと理解&テストコードをかけるようになると思うので実践していくのみ！
結論
- テストコードをきちんとかける＝仕様をコードに落とし込む道筋が出来ている＝段取りが出来ていると感じたため、もっとテストコードに関しても、実装に関しても身につけていきたい！とTDDをやって感じたことだった。（性に合っており、この開発方法面白い。）
ふと感じた疑問
- 全くやったことない機能ってTDDだとすごく時間がかかる？？？ただ、仕様をテストコードに落とし込む＝一つ一つの機能を捉える＝その部分を捉えられていないとそもそも実装できないという意味だから、逆に進むのかな？（その辺りってベテランとエンジニアさんってどうしてるんだろう？と思った）
感想
テストコード＝大事と理解していたけれど機能が実装終わった後にテストコードを書くものだと思っていた。
そうではなく、機能ごとに失敗するのも予測したところから始めていき、リファクタリングまで終わったら次のフェーズに移行するということが理解できた。
岡山さんがカジュアル面談の時に教えてくれたTDDという単語が頭のどこかで引っかかっていて（気になる、多分理解できてないという気持ち）と、今朝見た動画によって、ヤフーカンファレンスでテストコードがあることによって大胆に挑んでいけるという意味や、Ray wow FMでテスト駆動開発大切にしていること、チェリー本、Rails速習実践ガイドのテストコードの大事さを仰っている意味が一気に繋がって、「そういう意味だったのかー！」と思った。
rspecしか知らないため、和田さんのデモでやっていたような本当に一つ一つの機能を試せるテストコードも気になった👀Railsのこと調べた。こういうのもあるんだって思ったので一つずつ試してみたいと思った。
今日で、ユーザーインタビューをもとに「この機能をつけたい」と自分が願った基本機能が全て実装できた！！！思いが機能として形になるって本当に嬉しい。
あとはランディングページ！！！あと一息頑張るぞ☺️
覚書（12/29計画の見直し）
（１）やるべきこと （２）やりたいこと （３）やれること
（１）やるべきこと
- 卒業要件の完成
（２）やりたいこと
追加実装を学ぶためのミニアプリ作成
オリジナルアプリの作成
PHPの勉強
面白そうだから参加したい・見たい（済：やめ太郎さんのキータ表彰・yahooイベント）
読書
（３）やれること
メンタル：楽しみながら、ゲーム感覚でいく🎮😎
時間で区切り（達成すればよし）
- 1日 15分以上勉強する
追加実装のミニアプリを作り、引き出しを増やす
| 優先順位 | 内容（機能） | 締め切り | 達成度 |
|---|---|---|---|
| 1 | AWS S3 | 12/18 | 完了(フリマアプリ)に実装) |
| 2 | AWS EC2 | 12/24 | 完了(フリマアプリに実装) |
| 3 | ウィザード形式 | 12/27 | 完了 |
| 4 | SNS認証 | 12/28 | 完了 |
| 5 | 複数条件検索 | 12/29 | 完了 |
| 6 | タグ付 | 12/31 | 完了 |
| 7 | 画像プレビュー | 1/2 | 完了※フォーク |
| 8 | 複数枚写真OK | 1/4 | 完了※7に追加実装 |
| 9 | コメント機能(即時更新) | 1/8 | 完了 |
| 10 | クレカ登録 | 1/10 | 完了 |
| 11 | パンくず | 1/14 | 完了 |
| 12 | 日本語エラー | 1/18 | 完了 |
身に付ける力（直近）
PHP7
Docker
