本記事はUzabase Advent Calendar 2023の3日目の記事です
職場環境上、私は様々な言語に触れる機会が比較的多いため(Uzabaseには半年~一年のスパンでチームを移動する制度がある)、その分言語習得をする機会も多い。
そこで「動くものを作りながら覚えるタイプ」の筆者は、(主にサーバー側で使用する)言語の習得を楽にするため、予め作成したTODOアプリケーション用のAPIドキュメントを元に、Dreddを通してエンドポイントに対するE2Eテストをコンスタントに実行し続け、TODOアプリケーションとしての振る舞いを満たすアプリケーションを作成する、ということをやっている。
※APIドキュメントを元にMock的なものを作る&E2Eを用意すればフロント側も同様のことができそうだが、筆者はまだ試していない
ちなみにTODOアプリケーションである理由は、一々アプリケーションの振る舞いを考えるのが面倒なのと、一度APIドキュメントを作成してしまえば使いまわすことが可能なため。[1]
Dreddとは
"Dredd"は、ソフトウェア開発の文脈では、API（Application Programming Interface）のテストとドキュメンテーションを自動化するためのツールの1つです。Dreddは、APIのエンドポイントをテストし、実際の動作がAPIの仕様と一致しているかどうかを確認します。
Dreddについての説明はChatGPT先生に任せた。
実際にやってみる
必要なものは、Dredd本体と特定の振る舞いを定義したAPIドキュメントだけ。
2つとも以下のリポジトリに入っているので、参考にしていただきたい。
使い方はREADMEに書いてあるとおりだが、一応ここでも説明すると
- リポジトリをクローン
- ディレクトリルートで'make build'を実行
- ディレクトリルートで'make test-api url={テストしたいサーバーのルートエンドポイント}'を実行
⇡を上から実行していけば、予め筆者が作成したTODOアプリケーション用のAPIドキュメントスキーマ定義にしたがってDreddがエンドポイントのレスポンスを検証してくれる。[2]
Good
- E2Eだけではあるが既にテストが書かれている状態なので、RED > GREEEN > REFACTORのリズムで高速に開発を進めることができる
- ドキュメントで定義したアプリケーションの振る舞いを完全に覚えてしまえば、アプリケーションの構造に集中してプログラミングを進めることができる
- 自動化は神
More
- アプリケーションの構造ではなく振る舞いに興味がある人は飽きる気がする
- フロントエンドもテストしたくなる
- REFACTORをちゃんとやらなかったり、関数をコピペしたりしだすと「書いてるだけ」状態になる
- テストファーストでTDD風に設計するための機構であることを留意しない全てが無駄になる
以上、読んでいただきありがとうございました。
-
言語習得のためにTODOアプリケーションを作り続ける、というアイデア自体は同僚のSicut_studyさんから教えてもらったもの。 ↩︎
-
README > NOTESにもある通り、テストしたいサーバーが何らかのContaier上で動作している場合、localhostでは接続が出来ない可能性がある。Dockerの場合は'http://host.docker.internal:8080' と指定してあげると良い。 ↩︎
Discussion