* マンガログサービスマンガ読んだ！！のガヤガヤ会

• モブプロをするため、以下を準備しておいてください
• Zoom
• VS Code + VSCode Live Share

• 宿題
• パスカルで統一する
• 今回気づいたことで方向性を咀嚼して、再度決める。が、変わらないかも。
• →別の話だけど10回やったし振り返り的なことをしても良いかも。KPT。

• 思考メモ
• →ローカルで楽なテストにしていくことがイメージ出来ていない。
• →ローカル環境にないものはなにか？一番はDB。
• →それ以外はTwitterとかFacebookとメール？これはスルー出来るようになってないかも。
• →DBはmigrationでローカルに作ってしまうことは結構簡単。localDBとか
• →あとは実データ。少ない方が軽くはなる。が、軽いデータにするメリットはもちろんあるがテスト的にはあんまないかも
• →ローカル開発環境にするのはDBをどうするかだけ？
• →例えば現状の9つのUIテストをローカルに変えたら、より簡易なテストに出来るのか？
• →理想はSeleiniumなどを使わなくても一瞬で合否が分かるテストにしたい。恐らくユニットテスト。
• →マンガ一覧ページに行っても落ちないことと同等なユニットテストが書けるのか？
• →画面遷移ということに関するとSelenium以外では書けない気もする。
• →DBを書き込みのない読み込むだけのテストの方が簡易に出来そうだけど。
• →大分前に話した4つの段階のテストがヒントかも
• →1.DBのデータが正しいか→2.WebAPIが正しいか→これは全データを一度試したが例外はなかった。
• →BlazorのテストbUnitを使えないか？
• →より問題が表面化しやすい、起動が軽いなどのUIをテスト用に作るというのはあるかも。担保とのバランス。
• →これもまだゴールがイメージ出てきていないが、データが正しいかはもう少しテストでカバーしたい。
• →スクレイピングで書き込む時に例外が出て、直してみたいなこともたまにやっているのでそこをDBテストでカバーできない？

• 今回のテーマ
• リファクタリングを続ける
• →class名を考える
• →ローカル開発環境を用意するか
• →ページオブジェクトにするか
• 必要なテストを増やす。
• →ページネーションのテスト、読んだボタンを押したテスト

• 今後のテーマ
• 全データクレンジングテスト。段階は4つ。先ずはAPIのメソッドを全テスト
• パフォーマンステスト
• E2Eテスト
• インフラコード化
• WebAPI→GraphQL

• 終了後 詳しくはブログに書く予定です