本記事は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をちゃんとやらなかったり、関数をコピペしたりしだすと「書いてるだけ」状態になる
- 単体テストもどうにかする仕組みが欲しくなる
以上、DreddとTDDを使ってTODOアプリケーションを作り続けることのススメでした。
-
言語習得のためにTODOアプリケーションを作り続ける、というアイデア自体は同僚のSicut_studyさんから教えてもらったもの。 ↩︎
-
README > NOTESにもある通り、テストしたいサーバーが何らかのContaier上で動作している場合、localhostでは接続が出来ない可能性がある。Dockerの場合は'http://host.docker.internal:8080' と指定してあげると良い。 ↩︎
Discussion