サービス

ジャンル

職種：エンジニア

職種：ビジネス職

職種：デザイナー

職種：バックオフィス

職種：その他職種

技術

<h2 id="はじめに">はじめに</h2>

<p>こんにちは、プラットフォーム事業本部の平岩(<a href="https://twitter.com/_rock619" target="_blank">@_rock619</a>)です。</p>

<p>ユーザーレビュー基盤では現在リプレイスを進めており、バックエンドAPIをGoで開発しています。私たちのチームでは今回Goを初めて書くメンバーが多かったため、当初テストの書き方で戸惑うことがありました。そこで今回は、GoでAPIのテストを書く際に押さえておきたい点を私たちが参考にした情報とともにご紹介できればと思います。</p>

<h2 id="テストフレームワーク">テストフレームワーク</h2>

<p>他の言語では事実上の標準となっているテストフレームワークが多くの場合あると思います。RubyのRSpecなどがその一例です。 しかし、Goではそのようなフレームワークを使うことは推奨されず、むしろ使わないのが一般的です。 公式FAQ(<a href="https://golang.org/doc/faq#testing_framework" target="_blank">Where is my favorite helper function for testing?</a>)にその理由が書かれています。</p>

<p>個人的には、FAQの通りテストフレームワークは使わずに<a href="https://golang.org/pkg/testing/" target="_blank"><code>testing</code></a>パッケージで十分だと思います。しかし、値のアサーションに使う<a href="https://godoc.org/github.com/stretchr/testify/assert" target="_blank"><code>stretchr/testify/assert</code></a>など、一部のパッケージに関しては補助的に使っても問題ないと考えています。</p>

<p>公式FAQ(<a href="https://golang.org/doc/faq#assertions" target="_blank">Why does Go not have assertions?</a>)によれば、Goにアサーションがない理由は適切なエラーハンドリングとエラーレポーティングについて考えなくなってしまうからです。 適切なエラーハンドリングとはエラー発生時にクラッシュしてしまうのではなく動作を続けることであり、適切なエラーレポーティングとは大量のトレースを追わなくてもよくなるように内容が直接的で明確であることとあります。</p>

<p>テストの場合、適切なエラーハンドリングとエラーレポーティングによって得たいものは、テストが通らなかった場合に原因の特定が容易であることだと言えます。</p>

<p>この点に関して、差分の表示は補助的にパッケージを使ったほうが分かりやすくなる場合もあります。具体的には、JSONの文字列やフィールドが多い構造体などの比較の場合です。</p>

<p>それに加え、後述するSubtestでテストケース名を明示しそれぞれのケースの情報を補うことで、原因の特定を容易にするという目的は達成できると考えています。</p>

<p>前述のFAQ(<a href="https://golang.org/doc/faq#testing_framework" target="_blank">Where is my favorite helper function for testing?</a>)では他の問題点も述べられています。 テストフレームワークは標準ですでにある機能を再開発するようなミニ言語を作ってしまう傾向にあり、Goだけでなくフレームワークの理解も要求することになってしまう点です。</p>

<p>この点に関しても、<code>stretchr/testify/assert</code>のような一部のパッケージなら問題ないと考えています。なぜなら、値の比較でしか使わないため追加の知識はほとんど要求せず、Goの標準から外れたテストの書き方や実行コマンドを強制されることもないからです。</p>

<p>とはいえ、テストフレームワークを使わないにしてもテストの書き方には指針が欲しいですし、統一されていてほしくもあります。 標準パッケージでも使用されていて一般的な書き方として、Table Driven Testとそれに加えてSubtestがあります。</p>

<h2 id="Table-Driven-Test">Table Driven Test</h2>

<p>Table Driven Testとは、それぞれの行が入力と期待する出力を含んだテストケースになっているテーブルを作り、それをループして実行する形式のテストです。 Goの場合、入力と出力をフィールドとして持った構造体のスライスを定義し、forでループして実行する形になります。</p>

<p>利点としては、以下の点などが挙げられると思います。</p>

<ul>
	<li>テストケースの追加がしやすい</li>
	<li>それぞれのテストケースの入力と出力がまとまって書かれるため可読性が高い</li>
</ul>

<p>ループするため実行時の行数からではどのテストケースで失敗したのか区別できないので、どのケースか特定できる情報を出力することが必要になります。</p>

<p>以下のコードはGo公式のBlog<a href="https://blog.golang.org/subtests" target="_blank">Using Subtests and Sub-benchmarks</a>にあるサンプルコードです。</p>

<pre>
<code>func TestTime(t *testing.T) {
    testCases := []struct {
        gmt  string
        loc  string
        want string
    }{
        {"12:31", "Europe/Zuri", "13:31"},  // incorrect location name
        {"12:31", "America/New_York", "7:31"}, // should be 07:31
        {"08:08", "Australia/Sydney", "18:08"},
    }
    for _, tc := range testCases {
        loc, err := time.LoadLocation(tc.loc)
        if err != nil {
            t.Fatalf("could not load location %q", tc.loc)
        }
        gmt, _ := time.Parse("15:04", tc.gmt)
        if got := gmt.In(loc).Format("15:04"); got != tc.want {
            t.Errorf("In(%s, %s) = %s; want %s", tc.gmt, tc.loc, got, tc.want)
        }
    }
}</code></pre>

<h2 id="Subtest">Subtest</h2>

<p>また、それに加えてSubtestを使うことができます。これにより、以下の利点があります。</p>

<ul>
	<li>明示的にテストケース名を与えられるためテストケースをより説明的にできる</li>
	<li>テストケースの特定のサブテストだけ実行できる</li>
	<li>平行実行ができる</li>
</ul>

<p>Table Driven Testで挙げた<a href="https://blog.golang.org/subtests" target="_blank">Using Subtests and Sub-benchmarks</a>の例がSubtestを使うように修正されたものが以下です。</p>

<pre>
<code>func TestTime(t *testing.T) {
    testCases := []struct {
        gmt  string
        loc  string
        want string
    }{
        {"12:31", "Europe/Zuri", "13:31"},
        {"12:31", "America/New_York", "7:31"},
        {"08:08", "Australia/Sydney", "18:08"},
    }
    for _, tc := range testCases {
        t.Run(fmt.Sprintf("%s in %s", tc.gmt, tc.loc), func(t *testing.T) {
            loc, err := time.LoadLocation(tc.loc)
            if err != nil {
                t.Fatal("could not load location")
            }
            gmt, _ := time.Parse("15:04", tc.gmt)
            if got := gmt.In(loc).Format("15:04"); got != tc.want {
                t.Errorf("got %s; want %s", got, tc.want)
            }
        })
    }
}</code></pre>

<h2 id="テストのパッケージ名">テストのパッケージ名</h2>

<p>テストコードのパッケージは、対象と同じパッケージか<code>_test</code>と付けた別パッケージかのどちらかにできます。別パッケージにする利点としては、以下の2点があります。</p>

<ul>
	<li>循環参照を避けられる</li>
	<li>テストコードがパッケージの利用法のドキュメントに近づく</li>
</ul>

<p>exportされていない変数などは呼ぶことができなくなりますが、テスト中で使いたい変数などをexportするコードをテスト対象のパッケージに用意するという方法で回避が可能です。</p>

<p>この手法に関しては<a href="https://twitter.com/tenntenn" target="_blank">@tenntenn</a>さんの<a href="https://tech.mercari.com/entry/2018/08/08/080000" target="_blank">Go Fridayこぼれ話：非公開（unexported）な機能を使ったテスト #golang - Mercari Engineering Blog</a>で詳細に説明されています。</p>

<h2 id="テストの関数名">テストの関数名</h2>

<p>テストの関数名には<code>TestXxx</code>の形式にしないと実行されない以外、規則は特にありません。しかし、私たちは関数のテストは関数名が<code>Function</code>の場合は<code>TestFunction</code>、メソッドのテストは型名が<code>Type</code>で、メソッド名が<code>Method</code>の場合は<code>TestType_Method</code>と、統一しています。これはテストコードに書くことができるExampleと命名規則をそろえるためです。</p>

<p>Exampleについては<a href="https://github.com/budougumi0617" target="_blank">@budougumi0617</a>さんの<a href="https://budougumi0617.github.io/2018/08/30/go-testing2018-examples/" target="_blank">Goのtestingを理解する in 2018 - Examples編 #go - My External Storage</a>を参考にしていただければと思います。</p>

<h2 id="テストしやすいコード">テストしやすいコード</h2>

<p>さて、基本的なテストの書き方が分かっても、そもそもテストしやすいようにコードが書かれていないとかなり苦労することになります。</p>

<p>テストしやすいコードを書く方法については、<a href="https://twitter.com/deeeet" target="_blank">@deeet</a>さんの<a href="https://talks.godoc.org/github.com/tcnksm/talks/2016/12/golang-tokyo/golang-tokyo.slide" target="_blank">テストしやすいGoコードのデザイン</a>が明確に言語化されていてとても良いため、ぜひ読んでいただきたいです。個人的にも何度も読み返しています。</p>

<h2 id="interfaceを使ったモック">interfaceを使ったモック</h2>

<p>外部のサービスなどに依存する処理を単体でテストすることを可能にするため、よく使われるテクニックとしてinterfaceを使った依存のモック化があります。</p>

<p>これについては、まず<a href="https://twitter.com/deeeet" target="_blank">@deeet</a>さんの<a href="https://deeeet.com/writing/2016/10/25/go-interface-testing/" target="_blank">Golangにおけるinterfaceをつかったテスト技法 | SOTA</a>で基本を押さえるのがいいと思います。</p>

<p>それに加えて、structへのinterfaceの埋め込みを利用して部分的に実装を入れ替えるパターンを利用するとより柔軟なテストを記述できます。この手法については<a href="https://twitter.com/haya14busa" target="_blank">@haya14busa</a>さんの<a href="http://haya14busa.com/golang-how-to-write-mock-of-interface-for-testing/" target="_blank">Golangにおけるinterfaceをつかったテストで mock を書く技法</a>を読むのが良いと思います。</p>

<h2 id="テストの前後にはさむ処理">テストの前後にはさむ処理</h2>

<p>テストの前後に処理をはさみたい場合、以下での<code>setup()</code>のように後処理用の関数を返す関数を使うパターンがあります。後処理用の関数が唯一の戻り値の場合は<code>defer setup()()</code>とも書けて一見スマートに見えますが、個人的には明示的に受け取って呼び出した方が分かりやすいと感じます。</p>

<pre>
<code>func TestFunc(t *testing.T) {
    teardown := setup()
    defer teardown()

    // ...
}

func setup() func() {
    // 前処理
    return func() {
        // 後処理
    }
}</code></pre>

<p>また、パッケージ全体でのテストの前後に処理をはさむこともできます。<code>TestMain(m *testing.M)</code>を定義し<code>m.Run()</code>の前後に記述します。以下の例では<code>os.Exit()</code>を使う都合上<code>defer</code>を使っていません。</p>

<pre>
<code>func TestMain(m *testing.M) {
    teardown := setup()
    ret := m.Run()
    teardown()
    os.Exit(ret)
}</code></pre>

<h2 id="DB関連のテスト">DB関連のテスト</h2>

<p>DBがからむ処理については、<code>docker-compose</code>で開発環境を構築しているため、ローカル、CIでDBのコンテナを立ててテストしています。</p>

<p>もちろん、<a href="https://godoc.org/github.com/DATA-DOG/go-sqlmock" target="_blank"><code>sqlmock</code></a>などを使い、DBを使わずにテストする方法もあります。しかし、例えば<code>sqlmock</code>では発行されるクエリが意図したものであるところまでしか担保できないという難点があります。</p>

<p>そのため、テストの実行に時間がかかる欠点はあるものの、動作を保証できる範囲が増える利点の方が上回ると考え、DBを実際に使ってテストする方法を選択しています。</p>

<h2 id="HTTPリクエストレスポンスのテスト">HTTPリクエスト・レスポンスのテスト</h2>

<p>APIから意図したレスポンスが返ってくるかのテストには、<a href="https://golang.org/pkg/net/http/httptest/" target="_blank"><code>net/http/httptest</code></a>の<code>ResponseRecorder</code>を使っています。&nbsp;<code>ResponseRecorder</code>は<a href="https://golang.org/pkg/net/http/" target="_blank"><code>net/http</code></a>の<code>ResponseWriter</code>を実装しており、<code>ResponseRecorder.Body</code>は<code>*bytes.Buffer</code>なので、レスポンスボディをあとから<code>ioutil.ReadAll</code>などで取り出すことができます。</p>

<p>もっともシンプルな例は<a href="https://golang.org/pkg/net/http/httptest/#example_ResponseRecorder" target="_blank"><code>ResponseRecorder</code>のExample</a>にありますが、より詳しくは<a href="https://twitter.com/__timakin__" target="_blank">@__timakin__</a>さんの<a href="https://medium.com/@timakin/go-api-testing-173b97fb23ec" target="_blank">GoのAPIのテストにおける共通処理 &ndash; timakin &ndash; Medium</a>が参考になるかと思います。</p>

<h2 id="さいごに">最後に</h2>

<p>私の所属するプラットフォーム事業本部 Customer Decision Support Teamでは、一緒に働いてくれる仲間を探しています。 それぞれの得意分野を活かしながら、みんなでフロントエンドからインフラまでフルスタックを目指しているチームです。 少しでもご興味のある方はぜひご応募ください！</p>

<div data-oembed-url="https://dmm-corp.com/recruit/">
<div>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 52.5%; padding-top: 120px;"><iframe allowfullscreen="" src="//if-cdn.com/lYoH0j6?app=1" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" tabindex="-1"></iframe></div>
</div>
<script async="" charset="utf-8" src="//if-cdn.com/embed.js"></script></div>

<p><a href="https://dmm-corp.com/recruit/" target="_blank">dmm-corp.com</a></p>


DMMにおけるユーザーレビュー基盤の変革（Goのテスト技法編）

シェア