Sourcegraphは、Goで書かれたオープンソースのソースコードサーチエンジン。GitHub、Google Code等を検索し、表示されたコード上でfunction名などをクリックすると、そのドキュメントと他の利用事例のコードが確認できます。現在は、Go / Python / JavaScript / Rubyをサポートしていて、近々Javaもカバーするようになるようです。APIの公開は準備中とのこと。

同社のQuinn Slackが、Goアプリのテストをテーマに講演しています。

最初の構成

• データストア: DBへのSQLクエリを構築し、データに対するアルゴリズムも実行。
• HTTP API: データストアからデータを取得。HTTPキャッシュの役割を担う。
• webフロントエンド: APIからデータを取得し、HTMLテンプレをレンダリングする。

以前のテスト

• DBに接続して、fixtureでデータ作成
• APIエンドポイントにhttp.Getコール
• HTTPレスポンスボディをパース
• 期待する結果と比較

問題点

• 遅い: DBにinsertして、テストケース毎にクエリを実行している。
• リファクタリングしづらい: ルーティングやパラメータがstringで指定されている。
• 煩わしい定型コードが多い: テストコードを新たに用意する度にミスを誘発しやすい。

その後、コードや要件の変更が続いて、

• APIクライアントが必要になった。
• 機能とテストの追加で、テストの実行時間が長くなった。
• ルーティング設定が増えて大変。SourcegraphからGitHubなどへまたぐ設定になるので複雑。
• HTTP API経由だけでなく、バックエンドは直接データストアにアクセスする必要がでてきた。
• 外部のAPI利用者がHTTP APIをモックできるようにしたくなってきた。

改善策として、

• Go HTTP APIクライアントアプリをつくった。
  • 以前は、APIを利用するのはAngularJSウェブフロントエンドだけだったが、現在では、Goウェブフロントエンドを含め社内外複数が利用できるマイクロサービスアーキテクチャになった。
  • テストにおいて、HTTPリクエストを手動で発行しなくてよくなった。
• HTTP APIクライアントとデータストアで提供している類似のGoインターフェースをまとめた。
  • 以前は、API http.HandlerがSQLクエリを直接発行していたが、現在では、HTTP APIクライアントと同じインターフェースを実装したデータストアを、API http.Handlerが呼び出す仕組みに変更した。
• ルーティング設定の定義情報を集約。
  • ルーティング設定とhandlerのマウントを分離した。URLの生成とルーティング設定で、同じルーティングを使うようになったので、ミスが減った。
• 統合したインターフェースのモックを用意した。
  • 以前は、APIテストでは、ルーティング / HTTP handler / SQL生成 / DBクエリをまとめてテストするかたちだったが、現在では個別にテストできるようになり、テスト全体が1秒以内に完了できるようになった。
  • 例えば、データストアのRepoServiceをモックして、HTTP APIクライアントが、API http.Handlerをテストできるようになった。

その効果をまとめると、

• 包括的に3階層全てのテストできるようになった。
• 重複コードが減った。
• DBとのやりとりがなくなったので、スピードアップした。
• テストの疎結合、並列処理を実現。
• 特定のコンポーネントをターゲットとした単体テストができるようになった。
• 外部API利用者側のライブラリのテストをサポートできるようになった。

ビデオではサンプルコードとともに説明してますので、ご確認ください。

#sourcegraph #golang #テスト