これについては2通りの考え方があります。一つは、「古典学派」と言われるグループの考え方で、一つのテストシナリオを「単体」として扱います。DBやファイル出力、外部システムへのメッセージ送信などの「共有依存」については、そのまま使うと他のテストシナリオに影響を与えてしまうため、モックを使用します。もう一つは、「ロンドン学派」と言われるグループの考え方で、一つのクラスを「単体」として扱います。こちらは共有依存だけでなく、すべての「協力者オブジェクト」をモックに置き換えることで、対象のクラスの振る舞いのみに着目します。本書では、良いテストを構成する4本の柱を示していますが、ロンドン学派の考え方だとテストコードが実装の詳細に依存しすぎてしまい、4本の柱のうちの一つであり、かつ最も重要な特性とされる「リファクタリング耐性」を損なってしまうため、古典学派の考え方を推奨しています。古典学派のスタイルで記述する単体テストは、DDDで言うところの、最も上位層のドメインサービスやエンティティなどを対象として扱うテストのことだと自分は理解しています。 ちなみに、4本の柱とは以下のことです。<ul><li>リファクタリング耐性</li><li>退行からの保護</li><li>迅速なフィードバック</li><li>保守のしやすさ</li></ul>このうち迅速なフィードバックとは、テストをした際に結果がすぐに返ってくる、つまり実行時間が短いという性質を示します。単体テストでは共有依存を使わないため、この性質については必然的にほぼ満たされた状態になります。 テスト結果と実際の振る舞いの組み合わせパターンは、以下の4パターンがあります。（下図を参照）<ul><li>テストが成功し、かつ実際の振る舞いも正しい場合、それは仕様を満たしているということなので真の陰性です。</li><li>逆に、テストが失敗し、かつ実際の振る舞いも正しくない場合、それはテストが正しくコードの不正を検出しているということなので、真の陽性です。</li><li>テストが成功しているのにもかかわらず、実際の振る舞いが正しくない場合は偽陰性となり、テストがコードの不正を検出できていないということで、多くの場合退行からの保護が十分にできていないということになります。</li><li>テストが失敗しているのにもかかわらず実際の振る舞いが正しい場合は偽陽性となり、テストが壊れた状態を意味します。これはテストが実装の詳細に依存してしまっており、リファクタリングによって依存関係が破壊されるのが原因です。</li></ul>以上から、良いテストとは偽陰性と偽陽性の可能性を極力排除したものであることがわかります。またそのためには、4本の柱のうちの2本、つまり退行からの保護とリファクタリング耐性を兼ね備えたテストであることが必要であることもわかります。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/e2658b277e13430d83249fe040047550/fact.png" alt="">

古典学派とロンドン学派

どこまでを「単体」とすべきか

すべてのコードは以下の図の4つのエリアのうちのどこかに位置します。綺麗にコードの役割分担ができていれば、右上以外のエリアにすべてのコードが属するようになります。そのようなコードは、テストコードも簡潔に書けるため4本の柱の一つである、保守のしやすさを備えたテストになります。このうち、テストに価値をもたらすのは左上と、右下に位置するコードです。左下に関してはシナリオ内でテストするか、場合によっては全くテストしなくても問題になることはほとんどありません。ロジックが単純なため間違える可能性が低く、かつドメインにおける重要性も低いためです。左上は単体テストで確認し、共有依存はすべてモックに置き換えます。右下は統合テストで確認し、外部から直接参照できる共有依存はモックに置き換えます。外部から直接参照できない共有依存の代表はDBであり、インターフェースを退行から保護する必要性がないためモックに置き換える必要がありません。その場合、事前準備フェーズで他のテストケースに影響が出ないように状態をリセットする必要があります。なおテストの種類には他にもE2Eテストがあります。E2Eテストはユーザの視点で行うテストであり、外部から直接参照できる共有依存も含めて全てのオブジェクトをそのまま扱います。E2Eテストに関しては外部に影響を与えてしまうことが避けられないため、個人的にはテストコードとして実装することは困難だと思います。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/10f5d472a5154f45a601dcf1acbe1f1e/codetype.png" alt="">下の図は「テスト・ピラミッド」と呼ばれる図で、プロジェクトの理想的なテスト構成を表しています。上に行けば行くほどユーザの視点に近くなります。下に行けば行くほど横の広がりが大きくなりますが、これはテストの数の多さを表しています。つまり、単体テスト＞統合テスト＞E2Eテストの順でテストの数が多くなるべきだ、ということを意味します。先程も述べたように、単体テストではドメインモデル・アルゴリズムに位置するコードをテスト対象とするため、ロジックは複雑ですが協力者オブジェクトの数は少ないです。一方統合テストやE2Eテストの場合、対象はコントローラに位置するコードとなるため、先ほどとは反対にロジックは単純で協力者オブジェクトの数は多いです。そのため、単体テストはケース数が多くなり、統合テストやE2Eテストはケース数が少なくなるべきです。ただし、ドメインのロジックがほとんどないようなアプリケーションの場合、単体テストとそれ以外のテストは数がほとんど同じになるか、場合によっては単体テストがないこともありえます。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/1a91e4f2ff7a4d8d9d563a1b909740b5/unit_test.png" alt="">

テストピラミッド

どこまでをテストするのか

上記でも触れましたが、モックの使用についての指針は以下です。<ul><li>共有依存ではない依存はモックを使用しない</li><li>共有依存でも外部に直接公開されない依存（DBなど）はモックを使用しない</li></ul> モックを使用する場合でも、どのオブジェクトに対してモックするか、が問題になってくると思います。例えば、API呼び出しを行う場合、<ol><li>使用している言語のAPIライブラリ</li><li>APIライブラリをラップして対象アプリケーションに特化して使いやすくしたオブジェクト</li><li>2を更にラップして特定のリソースに特化して使いやすくしたオブジェクト(Repositoryのような使い方をする)</li></ol>というように複数のオブジェクトが関わっていた場合、どのオブジェクトをモック対象とすべきでしょうか？（以下の図は自分で描いたイメージ図です）<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/4e44f0d080c447269a5b9c67230c6213/co-dependency.png" alt="">まず、3の場合、上記の中では最も不安定であり、リファクタによってテストが壊れやすいです。また経由するコード量も最も少ないため、退行からの保護も十分に得られません。そう考えると1が最も適切なように思えますが、本書では2が最適であると論じられています。ライブラリは対象アプリケーションだけでなくさまざまなアプリケーションで使われている汎用的なものです。一方で対象アプリケーションに特化したオブジェクトは当然対象アプリケーションのみで使用しており、プロジェクトメンバーのみで保守できるため成長をコントロールできます。ライブラリが変更された場合にも影響が2の層内で収まるようになるので(腐敗防止層)、この層のインターフェースは保護すべきです。そのため、2をモックの対象とすることで、3に比べてリファクタリング耐性も得られますし、インターフェースが変更されればテストが失敗するため、退行からの保護も得られるようになります。

共有依存との境界

何をモックにすべきか

細かいトピックですがテストコードあるあるだと思います。インプットからアウトプットを組み立てるロジックを書いていると実装をしているような気分になってきて、意味のあるテストになっているのか不安に思うことがあると思います。そもそもアウトプットをインプットから組み立てるときの心理としては、導出できるものは極力導出すべし、というエンジニア脳があると思います。この場合で言えばアウトプットはインプットから導出できます。実際、仮にアウトプットを直書きするとインプットを少し変更しただけでテストが壊れるようになってしまいまうため、エンジニアとしてはある意味正常な脳の働きだと思います。しかし本書ではむしろ直書きを推奨しています。インプットからアウトプットを導出するコードはどうしてもプロダクションコードに似てきてしまうためです。それでも本来であれば退行からの保護は得られるはずですが、単なるコピペのようなコードであった場合失敗に向き合うのではなくその場しのぎでテストコードを修正してしまう恐れがあるためとのことです。個人的には、全てのアウトプットを直書きにすべしとは思いません。場合によってはコード量が膨大になってしまい、それこそ保守がしづらいコードになってしまう場合があると思うためです。簡潔に書けるのであれば直書きすべきですし、そうでないならロジックで組み立てるのもありだと思います。ただその場合も、極力プロダクションコードには似ないようにしたほうがいいと思います。別解を探すような感覚で、ロジックを実装することになります。

アンチパターン

テストコードでロジックを書いてはいけないのか

今回は、テストコードについて掘り下げてみました。1つの記事にしたら書くことが沢山あってかなり時間がかかってしまいました。ただそれだけこの本の内容が濃かったということだと思います。今回具体的なコードを挟まなかったため抽象的な話になってしまいましたが、本書ではコードも交えながら説明しているためわかりやすいです。繰り返しになりますが、大変おすすめの本ですので興味を持った方はぜひ読んでいただければと思います。 今回得た知見を実践に活用し、そこで更に得られたフィードバックがあれば、また別の記事にしようと思います。 最後までご覧いただきありがとうございました。

まとめ

<a href="https://www.amazon.co.jp/%E5%8D%98%E4%BD%93%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E8%80%83%E3%81%88%E6%96%B9-%E4%BD%BF%E3%81%84%E6%96%B9-Vladimir-Khorikov/dp/4839981728" target="_blank" rel="noopener noreferrer">単体テストの考え方/使い方</a>

参考文献

さいごに

単体テストのベストプラクティス

コードレビューでは、まず最初にコードが要求を満たす動作をすることが重要視されます。その上で、外部サービスの特異な動作やセキュリティ機構の考慮、不具合発生時の検知可能性、将来的な修正の困難さ、パフォーマンス問題などについても指摘が行われます。 指摘を行う際には、以下のようなタグを用いてコメントをカテゴライズします。<ul><li>must: 修正が絶対に必要な場合</li><li>imo: 自身の意見や思考を伝える場合</li><li>nits: 細部の指摘や軽微な修正を提案する場合</li><li>q: 質問をする、または不明な点を問い合わせる場合</li></ul> これらのタグは、レビューのプロセスで「心理的安全性」を保証するために重要な役割を果たします。 心理的安全性とは、ハーバード大学のエイミー・エドモンソン氏が提唱した概念で、チームメンバーが自身のミスを認め、改善のために積極的に発言する環境を指します。 コメントタグは、心理的安全性を保証するための3つの要素、すなわち「発言できる環境を作る」「自分がミスをしている可能性を認める」「好奇心を持つ」に対して以下のように貢献します。<ul><li>発言できる環境を作る: コメントタグを使用することで、自分の意見や感情を明確に表現できます。これにより、意見交換のハードルが下がります。</li><li>自分がミスをしている可能性を認める: 強い意志を示すタグ（例えば「must」）を使用することで、自分の認識のズレに気づく機会を得ることができます。</li><li>好奇心を持つ: 「imo」や「q」のようなタグを使用することで、他人のコーディングスタイルやコードの背景について理解を深めることができます。これは新たな視点を提供し、自身のスキルや知識を拡張する機会を提供します。</li></ul>

コードレビューにおけるコメントタグの使用は、チーム内の心理的安全性を強化する重要な手段です。これらのタグは、レビュアーが自分の意見を明確に表現し、レビュイーがフィードバックを適切に理解しやすくする役割を果たします。 また、タグの使用は、チームメンバーが自分のミスを認め、新たな視点を探求する環境を作り出します。これらの要素はすべて、心理的安全性の確保とチームの健全性に寄与します。

コメントタグの活用による効果的なコミュニケーションとチームの健全性

コードレビューにおけるフィードバックの分類と心理的安全性の強化

<ol><li>URLにケバブケースを使う: URLは読みやすさとSEOの観点からケバブケース（例：my-example-url）を使用します。</li><li>パラメータにキャメルケースを使う: パラメータはJavaScriptとの親和性を保つためにキャメルケース（例：myExampleParameter）を使用します。</li><li>コレクションを指す名前は複数形にする: リソースの集合を表す名前は複数形にします（例：users、products）。</li><li>URLはコレクションで始まり、識別子で終わる: URLの構造は一貫性を保つために、コレクション名で始まり、特定のリソースを識別するIDで終わるようにします。</li><li>リソースURLに動詞を使わない: リソースのURLは名詞を使用し、HTTPメソッド（GET、POST、PUT、DELETE）で操作を表現します。</li><li>非リソースURLには動詞を使う: リソースではなく操作を表すエンドポイント（例：/resetPassword）では、動詞を使用します。</li><li>JSONのプロパティにキャメルケースを使う: JSONのプロパティ名はJavaScriptとの親和性を保つためにキャメルケースを使用します。</li><li>モニタリングのためのエンドポイントを実装する: サービスの健康状態を監視するために、/health、/metricsなどのエンドポイントを実装します。</li><li>リソース名にテーブル名を使わない: データベースのテーブル名をそのままリソース名にするのではなく、ビジネスロジックに基づいた名前を使用します。</li><li>API設計ツールを使う: API設計とドキュメンテーションを助けるツール（例：Swagger、Postman）を活用します。</li><li>バージョンに単純な序数を使う: APIのバージョン管理には単純な序数（v1、v2など）を使用します。</li><li>レスポンスにリソースの総数を含める: リスト形式のレスポンスには、リソースの総数を含めることで、ページネーションなどの処理を容易にします。</li><li>limitパラメータとoffsetパラメータを受け入れる: ページネーションを実装するために、リクエストで取得するリソースの数（limit）と開始位置（offset）を指定できるようにします。</li><li>fieldsクエリパラメータを使う: 必要なフィールドのみをレスポンスに含めることで、データの転送量を削減します。</li><li>URLに認証トークンを渡さない: セキュリティの観点から、認証トークンはヘッダーに含めるか、POSTリクエストのボディに含めます。</li><li>コンテンツタイプを有効にする: サーバーはリクエストのコンテンツタイプを憶測せず、明示的に指定します（例：application/json）。</li><li>CRUD機能にHTTPメソッドを使う: CRUD（Create、Read、Update、Delete）操作はそれぞれHTTPメソッド（POST、GET、PUT/PATCH、DELETE）に対応します。</li><li>ネストされたリソースURLにリレーションを使う: リソース間の関係を表すために、ネストされたURLを使用します（例：/shops/2/products）。</li><li>CORSをサポートする: クロスオリジンのリクエストを許可するために、CORS（Cross-Origin Resource Sharing）をサポートします。</li><li>セキュリティを強化する: すべてのエンドポイントにHTTPSを適用し、データの安全性を保証します。</li><li>エラーハンドリングを適切に行う: クライアントが無効または不正なリクエストを行った場合、適切なエラーメッセージとともに4xx HTTPエラーコードを返します。</li><li>ゴールデンルールを守る: フラットはネストより良い、単純は複雑より良い、文字列は数字より良い、一貫性はカスタマイズより良い、という原則を守ります。</li></ol>

これを読む前から意識していたこともあるかもしれませんが、再度これを読んで意識できると品質が上がること間違いなしです！ これらのベストプラクティスを実践することで、API設計スキルを向上させ、アプリケーションのパフォーマンスとユーザーエクスペリエンスを向上させることができます。 それでは、皆さんがこれらのベストプラクティスを活用して、素晴らしいAPIを設計することを願っています！

これ意識して！

API設計スキルをブラッシュアップするための22のベストプラクティスの記事を読んだのでご紹介

OpenAPIを<a href="https://swagger.io/" target="_blank" rel="noopener noreferrer">Swagger</a>とか<a href="https://redocly.com/" target="_blank" rel="noopener noreferrer">Redoc</a>でブラウザに表示させながら、書き換えもしたいし、リアルタイムに変更を見たいし、さらにはHTMLを書き出したい時だってあるよね。 そんな時はこの構成でホットリロードとバンドルをしちゃえば運用コスト低めで叶えることができるよね。

tl;dr

はい、いきなり愚痴が出てしまいました。 そうなんです、OpenAPIをゼロから書く時って割とファイル量が多く、着手から10分後くらいには途方もなさを感じてメンブレ必至です。 既存APIの実装からOpenAPI形式で仕様を書き出すツール等ありますが、初期整備として仕様書を書く際はゼロから書かなければいけないケースが大半かと思います。 前述していますが、OpenAPIは細かい仕様を書くことができる。だからこそ、完成度の高い仕様書を作成するとなると必然的にファイル量は増えてしまいます。

ゼロから書いていくのは割と辛い。

何かしらの仕様に変更や誤りがあったり、単純に誤字していることに気が付いたり。 いざ実装を進めていると、細かいことにも気が付くようになり、多少なり仕様書を書き換えることがあります。 「仕様書を見ていつつも、書き換えもしたい」そんなニーズです。

ちょっと修正したい時だってある。

これはOpenAPIの強みの一つなので、僕にとってファイル分割は必ず採用したいものです。（というより、OpenAPIを一つのファイルで書ききるのは鬼の所業…。） そして、分割されたファイルを一つにバンドルしておきたい。一つのファイルにまとまっていると、何かと便利です。 例えば、<ul><li>ファイルのPath指定による<code>$ref</code>はSwaggerだと上手くいくが、Redocだと上手く参照できずエラーになる。</li><li>OpenAPIをHTMLにしてチーム内で見れるようにホスティングしたいが、分割されていると上手くHTML出力ができない。</li></ul>みたいなケース。（使っているツールに依る部分もあるかと思います。） こんなケースをカバーするためにも、一つのファイルになっていると恩恵を受けることがあります。

ファイル分割は絶対にしたい。でもバンドルもしたい。

OpenAPIに対する悩み

前置きが長くなってしまいました。さて、前述のお悩み解決に対処する方法です。 ポイントはズバリ二つ。<ol><li>ホットリロード</li><li>分割されたファイルのバンドル</li></ol>

以下の内容で構成していきます。今回はDockerでRedocとして表示させるので、Redocの公式イメージを使います。 <ul><li>Docker<ul><li><a href="https://hub.docker.com/r/redocly/redoc/" target="_blank" rel="noopener noreferrer">Redoc公式イメージ</a></li><li>OpenAPIを編集するための作業スペース</li><li>開発中に表示させて確認する</li></ul></li><li>JavaScriptスクリプト<ul><li>OpenAPIのウォッチャー<ul><li><a href="https://github.com/paulmillr/chokidar" target="_blank" rel="noopener noreferrer">paulmillr / chokidar</a></li></ul></li><li>バンドラー<ul><li><a href="https://github.com/WindomZ/swagger-merger" target="_blank" rel="noopener noreferrer">WindomZ / swagger-merger</a></li></ul></li></ul></li><li>OpenAPI</li></ul>

Dockerでレンダリング & ホットリロード & バンドル

<pre><code>/
├── compose.yaml # Docker Compose
├── docker
│&nbsp; &nbsp;└── redoc
│&nbsp; &nbsp; &nbsp; &nbsp;├── Dockerfile
│&nbsp; &nbsp; &nbsp; &nbsp;├── bundle.ts # バンドラー
│&nbsp; &nbsp; &nbsp; &nbsp;└── start.sh # Docker EntryPoint
└── api_docs/ # 分割されまくったOpenAPIたち
 &nbsp; &nbsp;├── components/
 &nbsp; &nbsp;│&nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;├── parameters/
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;├── path/
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;└── query/
 &nbsp; &nbsp;│&nbsp; &nbsp;├── requestBodies/
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;└── xxx/
 &nbsp; &nbsp;│&nbsp; &nbsp;├── responses/
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;└── xxx/
 &nbsp; &nbsp;│&nbsp; &nbsp;├── schemas/
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;├── xxx.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;└── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;└── securitySchemes/
 &nbsp; &nbsp;│&nbsp; &nbsp; &nbsp; &nbsp;├── xxx.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp; &nbsp; &nbsp;└── index.yaml
 &nbsp; &nbsp;├── paths/
 &nbsp; &nbsp;│&nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;└── xxx/
 &nbsp; &nbsp;│── tags
 &nbsp; &nbsp; │&nbsp; └── xxx.yaml
 &nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;└── openapi.yaml # バンドルされたOpenAPI</code></pre>

ディレクトリ構成

<pre><code>version: "3.8"

	services:
	 redoc:
	 build:
	 context: .
	 dockerfile: ./docker/redoc/Dockerfile
	 volumes:
	 - ./docker/redoc/bundle.ts:/app/bundle.ts
	 - ./docker/redoc/start.sh:/app/start.sh
	 - ./api_docs:/usr/share/nginx/html/docs # Redoc公式イメージでは '/usr/share/nginx/html/' 配下にOpenAPIを置く必要がある
	 ports:
	 - 9000:80</code></pre>

compose.yaml

<pre><code># Redoc公式イメージをベースに
FROM redocly/redoc:v2.0.0
	
WORKDIR /app
	
# ホットリロードにnpmパッケージを使用するためnpmインストール
RUN apk add --no-cache npm
	
# npmパッケージをコンテナ内でしようするための設定
ARG NODE_MODULE_PATH=/node
RUN npm config set prefix=${NODE_MODULE_PATH}
ENV PATH $PATH:${NODE_MODULE_PATH}/bin
ENV NODE_PATH ${NODE_MODULE_PATH}/lib/node_modules
	
# レンダリングするOpenAPIのPath　（Redoc公式イメージの環境変数）
# ファイル分割された '$ref' が含まれていると上手く参照できずエラーになる
# そのため、バンドル前の 'index.yaml' は使わず、バンドルされたファイルを指定する
ENV SPEC_URL docs/openapi.yaml
	
# ホットリロードに使用するnpmパッケージ群をインストール
RUN npm i -g \
 forever \
	ts-node \
	chokidar \
	swagger-merger
	
# EntoryPointにShellスクリプト指定
ENTRYPOINT [ "sh", "start.sh" ]</code></pre>

docker/redoc/Dockerfile

<pre><code># RedocのNginxを立ち上げる
# 'docker/redoc/Dockerfile'の 'ENTRYPOINT' で公式イメージの ' ENTRYPOINT ' は上書きされてしまったので再定義
# '&amp;' を付けてバックグラウンドプロセスにして、後述のバンドラーのプロセスと並走できるようにする
source /usr/local/bin/docker-run.sh &amp;
	
# バンドラー実行
ts-node bundle.ts</code></pre>

docker/redoc/start.sh

<pre><code>// 'ts-ignore' 連発。非常に良くないので反面教師で。。。
// @ts-ignore
const chokidar = require("chokidar") // ウォッチャー
// @ts-ignore
const swaggerMerger = require("swagger-merger") // バンドラー

const rootPath = "/usr/share/nginx/html/docs/" // OpenAPIが置かれているPath
const rootFile = `${rootPath}index.yml` // OpenAPIのルートファイルPath
const mergedFile = `${rootPath}openapi.yml`　　// バンドルしたOpenAPIを吐き出すPath
	
chokidar
 .watch(rootPath, { ignored: mergedFile })
 .on("all", (event: string, path: string) =&gt; {

 // ウォッチャーの検知したイベントをログに出力
 console.log(event, path)

 // OpenAPIをバンドル
 swaggerMerger({ input: rootFile, output: mergedFile })
 .then(() =&gt; {
 	 console.log("ReBundled OpenAPI")
 })
 	.catch((err: object) =&gt; {
	 console.error(err)
	 })
	})</code></pre>

docker/redoc/bundle.ts

この悩みに対処しよう

<ul><li>レンダリング<ul><li>Dockerを立ち上げればRedocをブラウザで確認することができます。</li><li>API実装中には必須だと思います。</li></ul></li><li>ホットリロード<ul><li>OpenAPIを書き換えたらRedocもそのタイミングで更新されます。<ul><li>表示を確認しながらサクサク書くことができます。</li></ul></li><li>「変な表示になってないかな？」「API実装中だけどちょっと修正しとこ。」ができます。</li></ul></li><li>バンドル<ul><li>OpenAPIを書き換えたら一つのOpenAPIとしても書き出されます。</li><li>これさえあれば色んな用途で柔軟に使い回せます。</li></ul></li></ul>

これで何が起こるか (まとめ)

今回はOpenAPIにまつわる開発体験の向上を軸にご紹介しました。割と良くある構成なのかな？とも思いますし、ツールの選定によってはもっとシンプルにすることができるかと思います。 もっと良い構成をご紹介できるように、チャンスがあれば色々試していきたいと思います。 最後まで読んでくださりありがとうございました！では！ﾉｼ

BuildersIO produced by YOKU

#開発ドキュメントの記事一覧

単体テストのベストプラクティス

コードレビューにおけるフィードバックの分類と心理的安全性の強化

API設計スキルをブラッシュアップするための22のベストプラクティスの記事を読んだのでご紹介

OpenAPIの運用コスト下げたい。

【Go言語】go mod tidy, go generateでエラーが発生した時の対処法

【React】React Hook Formでフォーム分割して送信時にデータ結合する

【Laravel】JWT認証機能の実装

#開発ドキュメント の記事一覧

単体テストのベストプラクティス

コードレビューにおけるフィードバックの分類と心理的安全性の強化

API設計スキルをブラッシュアップするための22のベストプラクティスの記事を読んだのでご紹介

OpenAPIの運用コスト下げたい。

#開発ドキュメントの記事一覧