[🔝TOP](https://www.notion.so/shinofara-1a690b35713b45bf8ea599bfa73fb7df?pvs=21) > [[Tags/メモとして書いた系|メモとして書いた系]] - 目次 📝 メモ 🏷️ タグ 🗞 登場した用語まとめ ## 📝 メモ [[リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog|リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog]] を読んだ事でふと思った事。中身は関係ないです。 また合わせて、以下の記事なども少し関連しています。 - [[失敗から学ぶAPIファースト - API first learning from failure|失敗から学ぶAPIファースト - API first learning from failure]] - [[APIシナリオテストを書くべき10の理由|APIシナリオテストを書くべき10の理由]] - [[Terminology/APIファースト|APIファースト]] - [[モダンなテストレベル設計（ユニットテスト～システムテスト等をどう設計するか）の原則|モダンなテストレベル設計（ユニットテスト～システムテスト等をどう設計するか）の原則]] - [[APIテストはいつやるの？今でしょう！|APIテストはいつやるの？今でしょう！]] Unit、Integration、E2Eは、どこがどれくらい大事という話ではなく、APIに対するRequest / Responseのテストが揃っている事で、仕様を満たしているか、APIのリクエストごとのパフォーマンスはどうかだけではなく、コードを読まなくても（APIスキーマなどでコメントなどが充実している事で）APIが何をしているのか把握しやすくもなるよなーと それにリファクタリングするときが来たとしても、スキーマを変更するレベルではなくスキーマは変わらず言語や実装に変更を行う場合、仕様を満たすかどうかの確認もしやすくなる。 FrontendでのIntegrationやE2Eでは、とてもコスパが悪いがAPIのテストではいうほどコスパは悪くないだろうし、あるとないとでは全然ちがうなーと最近おもっている ## 🏷️ タグ #### タグ |Name|関連ページ数| |---|---| |[[Tags/メモとして書いた系\|メモとして書いた系]]|48| ## 🗞 登場した用語まとめ #### 用語 |Name| |---| |[[Terminology/リファクタリング\|リファクタリング]]| |[[Terminology/APIファースト\|APIファースト]]| [🔝TOP](https://www.notion.so/shinofara-1a690b35713b45bf8ea599bfa73fb7df?pvs=21) > [[Tags/メモとして書いた系|メモとして書いた系]]