[🔝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/メモとして書いた系|メモとして書いた系]]