Sourcegraph: Goアプリのテスト

http://pivotallabs.com/tech-talk-sourcegraph/

1 comment | 1 point | by WazanovaNews 2年以上前 edited


Jshiike 2年以上前 | ▲upvoteする | link

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 #テスト

Back