DeNA Testing Blog

Make Testing Fun, Smart, and Delighting End-Users

SWETの新メンバーから見て驚いたこと、そこから生まれたDIライブラリ不使用宣言

はじめまして!4/1よりSWETに加わった@Kuniwakです。 今回は、私がSWETに入って驚いたことと、そしてSWETだからこそ生まれたものについてお話しします。

まずKuniwakはどんな人?

開発を高速化させるテストや静的検査を生業としています。主に、以下のような記事やスライドを書いています。

では、こんな私がSWETという自動テストのエキスパートのチームで働くことになって驚いたことを紹介します。

SWETに入って驚いたこと

SWETに入って驚いたのは、テストに関連するトピックについてどなたも一家言をもっていたことです。例えば、以下のようなやりとりが実際にありました。

Kuniwak:Mockライブラリ1やDIライブラリ2は必要だと思いますか?いずれもライブラリに頼らずにシンプルに書ける気がします。皆さんはどういうご意見をお持ちでしょうか。

A さん:Mockはライブラリに頼りたいですね。自前でMockのコード書くとMock自体のテストとかが必要になって面倒なことになると思います。

B さん:複数のプログラミング言語にまたがるような組織では、それぞれの言語に対するメンバーの習熟度にもばらつきがありますから、既存の文献やコード資産を参考にできるデファクトなライブラリを使った方がいいという視点もありますね。

C さん:Mockライブラリに限らず、他のライブラリと同じようにメンバーの学習コストやメンテナンスの継続性、利用者数などから考慮するといいのではないでしょうか。

D さん:この記事3でも言われているように、Mockライブラリがパワフルになりすぎて濫用しがち、という話はありますね。個人的な経験で言えば、テストではStub/Spy/Fake4で十分だと思っていて、あまり無理にライブラリは使わない感じですね。

このやりとりでは、会話しているメンバーのいずれもMock/DIライブラリについての深い経験をもっていることに感動しました。また、だからこそそれぞれが違った意見をもっているのだと感じます。このような議論のできる環境は、自動テストのエキスパートで構成されるSWETでなければなかなか巡り会えないのではないでしょうか。

さらに、このような素晴らしい議論ができたことで、以下のとても重要な知識を得られました。

  • Mock/DIライブラリの不必要派は1人じゃない

    今まで、Mock/DIはライブラリを使うのが当たり前というのがよく聞く意見で、私のようにライブラリを不必要と思う派閥はいないのかもしれないと思っていました。しかし、Dさんのように私と同じライブラリの不必要派は一定数存在することがわかりました。

  • Mock/DIライブラリの必要性の議論では無条件の合意をとれない

    ここに書ききれなかったやりとりの中で、Mock/DIライブラリを必要だと思うかどうかは経験してきた言語/プロジェクトの性質によって左右されることがわかりました。例えば、これまで私はJavaScriptやSwiftといった変化の著しい言語を同時に複数を相手にしてきたため、ライブラリの恩恵よりも負の側面を強く感じていたことに気づきました。逆に、このような環境でなければライブラリの恩恵の側面を強く感じたとしても不思議ではありません。つまり、Mock/DIライブラリを使うべきかどうかは言語やプロジェクトに依存するのです。

  • Mock/DIライブラリを使わない選択肢を解説する文献が少ない

    これはBさんとCさんの意見からうかがえる事実です。このやりとりをするまで、文献の少なさを気にしたことがありませんでした。

このやりとりのあと、私はすぐにここで得た知識を活かす機会を思いつきました。私が声をあげることで、本来ライブラリを使わなくてもよい状況でライブラリを無理に使ってしまう問題を減らせると思ったのです。そこで、「バニラDI宣言(Vanilla DI Manifesto)」と「バニラMock宣言」を書くことにしました。

メンバーとの議論から生まれた「バニラDI宣言」と「バニラMock宣言」

バニラDI/Mock宣言とは、状況に応じてライブラリを使わないことを選ぼう、ということを表明した宣言です。このバニラという表現は、何も手が加えられていないという意味でよく使われるものです。ライブラリを使わずに言語本来の自然な書き方で実現していくという方針にぴったりだと思い、この名前をつけました。なお、以降では既に公開済みのバニラDI宣言の方を中心に解説していきます(バニラMock宣言は鋭意準備中です)。

さて、そもそもライブラリを使わないでDIを実現できるのでしょうか?この疑問にお答えするために、バニラDI宣言には各言語のコードサンプルを付属させました。例えば、JavaScriptにおけるバニラDIは次のように表現できます:

// これらは依存先コンポーネントです。後述のコンポーネント内で使われます。
class X {}
class Y {}

// これは依存元コンポーネントです。X と Y への依存をもっています。
class Z {
  constructor(dependency) {
    this.dependency = dependency;
  }

  doSomething() {
    const {x, y} = this.dependency;
    // x と y を使って処理をします。
  }
}

// すべての依存先コンポーネントは、依存元コンポーネントの
// 初期化時に束縛します。
const z = new Z({
  x: new X(),
  y: new Y(),
});

z.doSomething();

ご覧の通り、DIをコンストラクタ引数への指定だけで実現しています(この方法はコンストラクタ注入と呼ばれます)。とても単純な仕組みであることがよくわかると思います。また、静的型検査のある言語でもどのように表現されるのか見てみましょう。例えば、Swiftでは次のようになります:

// これらは依存先コンポーネントです。後述のコンポーネント内で使われます。
class X {}
class Y {}


// これは依存元コンポーネントです。Xと Yへの依存をもっています。
class Z {
    typealias Dependency = (
        x: X,
        y: Y
    )
    private let dependency: Dependency


    init(dependency: Dependency) {
        self.dependency = dependency;
    }


    func doSomething() {
        let (x, y) = self.dependency;
        // x と y を使って処理をします。
    }
}


// すべての依存先コンポーネントは、依存元コンポーネントの
// 初期化時に束縛します。
let z = Z(dependency: (x: X(), y: Y()));

z.doSomething();

静的型検査のある言語でも同様の書き方で実現できることがわかります。 さて、どうして私はこのようなバニラDIを好むのでしょうか。その理由は以下の6点です:

  • 実装が単純
  • 簡単に利用できる
  • 依存するライブラリはゼロ
  • 初心者に対しても可読性が高い
  • 多くの言語で実用可能
  • 悪い設計だとすぐに破綻する

このうち上の5つは自明だと思いますが、私が特に強調したいのは最後の「悪い設計だとすぐに破綻する」ということです。では、破綻のスメルが出ている具体例を見てみましょう。

バニラDIが可視化する設計の破綻

まず、コンストラクタの引数が多くなってきたケースです。たとえば次のようなクラスがあったとします:

class SomethingGreatService {
    private let foo: Foo
    private let bar: Bar
    private let fooBar: FooBar
    private let baz: Baz
    private let qux: Qux
    private let quux: Quux


    init(foo: Foo, bar: Bar, fooBar: FooBar, baz: Baz, qux: Qux, quux: Quux) {
        self.foo = foo
        self.bar = bar
        self.fooBar = fooBar
        self.baz = baz
        self.qux = qux
        self.quux = quux
    }
}

クラス定義もだいぶつらそうですが、それよりつらいのはコンストラクタの呼び出し側です。たとえば以下のようになるかもしれません:

let service = SomethingGreatService(
    foo: Foo(),
    bar: Bar(
        corge: Corge()
    ),
    fooBar: FooBar(
        grault: Grault(
            garply: Garply()
        )
    ),
    baz: Baz(
        waldo: Waldo()
    ),
    qux: Qux(),
    quux: Quux(
        plugh: Plugh()
    )
)

特にSomethingGreatServiceを対象としたユニットテストでは繰り返しこのクラスを作成することになることが多く、テストを書いている途中でうんざりすることになります5。これに対して、DIライブラリを使えば呼び出し側の記述をかなり省略できます。この点だけを見れば、DIライブラリの方が優れているという印象を受けることでしょう。しかし、バニラDIでは異なる見方をします。

バニラDIでは、このような状況を設計破綻のスメルとみなします。今回のスメルは次の2つの可能性のいずれかを示唆しています:

  • SomethingGreatServiceの責務過多
  • 依存対象であるFooBar等の抽象度の不足

そして、それぞれへ対応する解決策は次のようになります:

  • SomethingGreatServiceの責務を分割
  • 依存対象の関係を整理してこれらをまとめた新コンポーネントを作成

さて、これらの解決策によって先ほどの引数が多いという問題も同時に解決できます。前者の責務分割では、SomethingGreatServiceが複数のコンポーネントへ別れますから、それぞれのコンポーネントへコンストラクタ引数が分散されます。後者の依存物の整理では、直接の依存が新コンポーネントを通しての間接的な依存へ変わりますから、直接の依存であるコンストラクタの引数は少なくなります6

このように、バニラDIでは設計の破綻が書きづらさや面倒さとなってすぐに可視化されます。これらを取捨選択して解決していく過程で、自然と適切な責務の分割や抽象化へと導かれるのです。これこそがバニラDIの最大の利点の1つだと私は考えています。

終わりに

この記事では、私から見てSWETに入って驚いたこと、そしてテストに関するエキスパートが集結しているSWETでなければ思いもつかなかったバニラDI/Mock宣言について紹介しました。バニラDI/Mock宣言についてご質問やご意見等ある場合は、お気軽にissueKuniwakまでお問い合わせください。では、弊社主催であるiOS Test Nightの運営スタッフとしてお会いできることを楽しみにしております。


  1. Mockライブラリとは、テストケースの実行に必要な偽のコンポーネントをつくりやすくするライブラリです。JavaScriptではSinon.JS、SwiftではCuckoo、Pythonではunittest.mockが有名です。

  2. DIライブラリとは、Dependency Injectionをやりやすくするライブラリです。JavaScriptではInversifyJS、SwiftではDIKitが有名です。

  3. t-wadaさんと家永さんの対談記事:「希薄化したTDD、プロダクトの成長のために必要なものは?〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談(6)

  4. これらはすべてテスト用の偽のオブジェクトのことです。Stubとは、テスト対象のコンポーネントへの入力をテスト用の入力へ差し替えるためのオブジェクトです。Spyはテスト対象のコンポーネントからの出力を記録するためのオブジェクトです。Fakeはテスト対象からの依存対象を簡易的に代替するオブジェクトです。それぞれを詳しく知りたい場合はxUnit Test Patternsを読むことをお勧めします。

  5. このつらさを解消するためにデフォルト引数を使うこともできますが、一般的にこれはあまりよい選択ではありません。デフォルト引数は何がデフォルトとして使われても問題のないケースでのみ使うべきだからです。もし、デフォルト引数を変えたら壊れてしまうような場合は、定義元を読まない限りわからない暗黙の期待を埋め込んでいるということを意味します。このような暗黙の期待は可読性を損ないます。つまり、呼び出し側が特定の振る舞いを期待する場合は明示的に引数に指定する方がよいのです。今回のケースでは何がデフォルトとして使われても構わないとはいえないので、デフォルト引数を使わない方がよいでしょう。

  6. 素直に考えると、新コンポーネントを作成しても依存している数には変わりないと思うかもしれません。しかし、実際はそうなりません。まず、抽象コンポーネントを定義することでStub/Spy等のテストダブルを書きやすくなります。テストダブルは依存物を必要としないですから、テスト内では間接的な依存を意識しなくてすむようになります。また、テスト外の場合でも、SomethingGreatServiceを内部的に利用するクラスが既に作成済みの依存物を保持していることが多く、テスト内と同様に間接的な依存は見えなくなります。もし、間接的な依存が見えてしまう場合はカプセル化が不十分であることを示唆しています。

Puppeteerによるフルページスクリーンショットを画像遅延読み込みに対応させる

こんにちは、薦田です(@toshiya_komoda)。 今回はChromeブラウザのブラウザテスト自動化ツールであるPuppeteerに関するTipsを紹介します。

Puppeteerによるフルページスクリーンショット

Puppeteerは、Chrome DevTools ProtocolのNode.jsクライアントであり、Chrome DevToolsチームがメンテナンスしています。 その主な用途の1つにブラウザ自動テストが挙げられます。 PuppeteerはChromeの操作に特化しており、操作対象がChromeに限定されるもののSeleniumにはない便利なAPIを利用できます。

Puppeteerで利用できる便利なAPIの1つに、フルページスクリーンショットがあります。 フルページスクリーンショットとは、ウェブページの上端から下端までを1つなぎの画像としてスクリーンショットを撮ったものです。

例えば、以下の画像はフルページスクリーンショットの例です。DeNA Testing Blogの過去の記事です。

DeNA Testing Blog記事のフルページスクリーンショット

Seleniumでもスクリーンショットを取得可能ですが、取得対象の領域がviewportに制限されます。 このためSeleniumでフルページスクリーンショットを実現しようとすると、スクロールしながら複数枚のスクリーンショットを撮った後、1枚につなぎ合わせるといった実装が必要になります。

Puppeteerを利用した場合の実装は以下のように簡潔なものになります。 Node.js v8.11.1, Puppeteer 1.3.0で動作確認しています。

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({headless: true});
  const page = await browser.newPage();
  page.setViewport({width: 1200, height: 800})
  const url = 'http://swet.dena.com/entry/2018/02/16/104605'
  await page.goto(url);
  await page.waitForNavigation({waitUntil:'networkidle2', timeout:5000})
            .catch(e => console.log('timeout exceed. proceed to next operation'))
  await page.screenshot({path: 'testing-blog.png', fullPage:true})
  console.log("save screenshot: " + url)
  await browser.close()
})();

補足:Puppeteerの以前のバージョンではフルページスクリーンショットの高さに16384pxの制限がありましたが、1.2.0以降のバージョンではこちらの制限はなくなっているようです。

遅延読み込み対策

Puppeteerでは、前述のようにフルページスクリーンショットを簡単に利用することができ、Visual Regression Testなどに利用することが可能です。 しかし、画像の遅延読み込みに対応したウェブページでは、フルページスクリーンショットをうまく取得できないことがあります。

こちらの画像がそのような例です。 lazysizesという画像遅延読み込みライブラリのデモページで別に画像を用意して試しています。

遅延読み込みページのフルページスクリーンショット

使用画像: Test by Ray Bouknight is licensed under CC BY 2.0

ページ中にロードしきれていない画像が存在しており、正しくフルページスクリーンショット画像が撮れていません。

この問題はPuppeteerのissueにも報告されており、 不具合扱いではありませんが、Feature RequestとしてPuppeteer側での対応が提案されている状況です。 現時点では以下のように一度ページ下端までウィンドウをスクロールさせることで問題を回避できます。

const puppeteer = require('puppeteer');

async function scrollToBottom(page, viewportHeight) {
  const getScrollHeight = () => {
    return Promise.resolve(document.documentElement.scrollHeight) }

  let scrollHeight = await page.evaluate(getScrollHeight)
  let currentPosition = 0
  let scrollNumber = 0

  while (currentPosition < scrollHeight) {
    scrollNumber += 1
    const nextPosition = scrollNumber * viewportHeight
    await page.evaluate(function (scrollTo) {
      return Promise.resolve(window.scrollTo(0, scrollTo))
    }, nextPosition)
    await page.waitForNavigation({waitUntil: 'networkidle2', timeout: 5000})
              .catch(e => console.log('timeout exceed. proceed to next operation'));

    currentPosition = nextPosition;
    console.log(`scrollNumber: ${scrollNumber}`)
    console.log(`currentPosition: ${currentPosition}`)

    // 2
    scrollHeight = await page.evaluate(getScrollHeight)
    console.log(`ScrollHeight ${scrollHeight}`)
  }
}

(async () => {
  const viewportHeight = 1200
  const viewportWidth = 1600
  const browser = await puppeteer.launch({headless: true});
  const page = await browser.newPage();
  page.setViewport({width: viewportWidth, height: viewportHeight})
  const url = 'http://afarkas.github.io/lazysizes/#examples'
  await page.goto(url);

  // 1
  await page.waitForNavigation({waitUntil: 'networkidle2', timeout: 5000})
            .catch(e => console.log('timeout exceed. proceed to next operation'));

  await scrollToBottom(page, viewportHeight)
  await page.screenshot({path:'scroll-sc.png', fullPage: true})

  console.log("save screenshot: " + url)
  await browser.close()
})();

こちらのコードは、Vasilev氏のPuppeteer Screenshotsの実装を参考にしつつ、以下2点の改良を加えたものです。

  1. page.waitForNavigation()関数の条件として、networkidle2(ネットワーク接続が2本以下の状態が500ms以上続く状態)を 指定しています。 ただしウェブサイトによっては、 画像ロード以外のネットワーク接続の影響でこの条件が恒久的に満たされないため、timeoutオプション(デフォルトは30sec)を明示的に指定しています。
  2. また、scrollToBottom()関数の中ではwhileループの中でスクロールしながら毎回scrollHeightの値を更新しています。 これは、スクロール操作によってページのscrollHeightの値が動的に変わる場合があるためです。

ページを一度下端までスクロールしておくことで、さきほどのページのフルページスクリーンショットは以下のように改善されます。

遅延読み込みページのフルページスクリーンショット(遅延読み込み対応版)

画像が全てロードされ、きれいなフルページスクリーンショットが取得されています。

補足Tips

以前のバージョンにあった高さ制限の問題とは別に、Puppeteerでは非常に大きなフルページスクリーンショット画像を取得しようとすると、その下端がかけてしまうことがあります。 こちらの現象は遅延読み込みとは別の問題ですが、こちらのissueで説明されています。 こちらの問題はChromium側での対応が必要ということで、Chromiumの不具合としてあがっていますが、Puppeteer1.3.0にバンドルされたChromiumでは未対応です。

この現象が発生した場合には、スクロールしながらスクリーンショットを複数枚取得し最後につなぎ合わせる、といったSeleniumの場合と同様のワークアラウンドが必要になります。

DeNA TechCon 2018でSWETの取り組みについて発表してきた

初めまして、SWETの坂本です。先日行われたDeNA TechCon 2018のBlueStageにて、SWETの取り組み内容についての発表を行いました。発表資料は以下になります。

発表内容

今回の発表ではSWETの具体的な取り組みとして、"画像"が絡むようなテスティングに関する2つの取り組みについて、前後半に分けて紹介しました。

前半の発表では、SWETで開発を行っている、WebアプリのVisual Regression Testを支えるクローラーについてお話ししました。
クローリングの高速化のための並列化の方法、Visual Regressionに使うためのスクリーンショットの取り方のテクニックなどについて述べました。また、単純なクローラでは突破することができない登録フォームなどに対応するために、機械学習の活用を検討している状況についても発表しました。

後半の発表では、テンプレートマッチング(画像処理)を使った自動化のツラミを低減するためにSWETで開発しているサービス「ExMachina」についてお話ししました。
ExMachinaの基本的なアイデアは、「ページ情報」という形でテスト用のイメージ素材を管理することにより、WebやNativeアプリと同様にセマンティックな情報を利用してUIテストの自動化が行えることです。 発表ではその基本的なコンセプトを共有し、ExMachinaを使った自動化の処理の流れ、ExMachinaのクローラーへの応用などについて説明しました。

おわりに

SWETでは、まだベストな方法が確立されていないテスティングの領域に対してR&D的な取り組みを行っており、今後も拡充していきたいと思っています。
また、その取り組みの中で機械学習を活用したアプローチも検討しています。

SWET視点のDroidKaigi 2018参加レポート

はじめまして。SWETの外山(@sumio_tym)です。
2018年1月よりSWETで働いています! どうぞよろしくお願いします!

さて、2018年2月8日(木)から2日間にわたって開催されたDroidKaigi 2018の参加レポートをお届けします。
DroidKaigi 2018では、私達DeNA SWETグループからも、私を含めて3名が登壇しました!

f:id:swet-blog:20180215202534j:plain
(C) 2018 DroidKaigi実行委員会

このエントリでは、SWETらしく、テスティングに関係するセッションを以下の2つに分けてご紹介します。

  • DeNA SWETメンバーによる発表
  • DeNA以外の方による発表

DeNA SWETメンバーによる発表

Androidで利用できるデバイスファームのメリット・デメリットの紹介

duckさんによる発表です。

サーバーで集中的に管理されたAndroid端末を、遠隔操作・テストできる「デバイスファーム」について、 以下の観点で比較していました。

  • 端末を操作できるか?
  • 自動テストで何が動かせるか?
  • 利用者がテストを用意しなくても良い「モンキーテスト」ができるか?
  • adbで接続できる「ダイレクトアクセス」ができるか?
  • CI/CDと連携可能か?

また、最後に、以下の点を強調していたのが印象的でした。

「必ず、無料枠で、自分達の業務に適用できるか試してみること」

デバイスファーム選びの参考にしてみてください。

UIテストの実行時間を短縮させる方法

tarappoさんによる発表です。

前半では、UIの自動テストに関する以下の点について、具体例を挙げながら解説していました。

  • テスト実行時間が増加しやすい要因
  • テスト実行時間増加により引き起こされる問題

後半では、実行時間短縮のために必要な、以下のプラクティスを解説していました。

  • 無駄にUIの自動テストを増やさない
  • sleepの利用を減らす
  • 事前にテストアセットを用意する
  • テストを実行させる端末の種類を減らす
  • テストケースを分割して、テストの実行を並列化する

特に、単純な並列化だけではスケールしない場合に、 ボトルネックを特定しつつ更に並列度を上げていく過程はとても参考になると思います。

Espressoテストコードの同期処理を究める

外山の発表です。

AndroidのUIテストツールEspressoを使っていると、 テスト対象アプリのUI更新の完了を待てずに失敗することがあります。

その問題を解決するために必要なIdlingResourceについての知識や、 UI Automatorを併用してUI更新完了を待ち合わせる方法について説明しました。

独自の非同期処理機構を持つRxJavaなどを採用しているアプリでは、Espressoによるテストの失敗頻度が高くなります。 そのようなときに、この発表を参考にして、失敗しないEspressoテストに書き換えてみてください。

また、外山が過去のDroidKaigiで発表した以下の内容も役に立つと思います。あわせて参照してみてください。

DeNA以外の方による発表

はじめてのUnit Test

@fushiroyamaさんによるハンズオンです。 自分のEspressoの発表と時間が重なっていたため、参加は叶わなかったのですが、スライドを読むだけでも参考になります。

このスライドでは、AndroidのLocal Unit Testを書くのに必要な知識が、MockitoやRobolectricの使い方も含めて丁寧に解説されています。

ハンズオンに利用するソースコードも公開されていますので、 AndroidのLocal Unit Testに入門したい方はチャレンジしてみると良いと思います。

How to improve your MVP architecture and tests

kiriminさんによる発表です。

MVPアーキテクチャを採用したアプリにおいて、Presenter部分をテストする方法を解説する内容でした。

  • MVP採用時にありがちなアンチパターンの解説
  • 正しくViewとPresenterを分離し、Mockitoを使ってテストを書く方法

が丁寧に説明されており、具体的でとても分かりやすい内容でした。

MVPアーキテクチャを採用するときはもちろん、そうでないときでも、 Androidのユニットテストを書くときの参考にすると良いと感じました。

Moving Forward with JUnit 5

Marcel Schnelleさんによる発表です。

JUnit4が抱えている問題の説明から始まり、以下のような流れで解説していました。

このGradleプラグインはAndroid Test Night #1でも少し話題になっていました。

当時はLocal Unit Testしかサポートしていませんでしたが、 現在ではInstrumented Testもサポートしている(Experimental)とのことです。

AndroidでJUnit4が使えるようになるまでは長い時間が必要でしたが、JUnit5は案外すぐに使えるようになるかも知れません。 今後が楽しみですね!

おわりに

DroidKaigi 2018のセッションのうち、テスティングに関係するものをご紹介しました。

SWETグループでは、DroidKaigiでの登壇に限らず、積極的に対外的なアウトプットを行っています。 加えて、SWETグループ主催の勉強会である、Android Test NightiOS Test Nightも開催していますので、ご興味の有る方は是非ご参加ください。

また、SWETグループではAndroidに限らずテストの自動化やCI/CDに興味があり、私達と一緒に働いてくれる仲間を募集しています。ご応募お待ちしています!

Golang testingことはじめ(3)〜アプリケーションのテスト〜

こんにちは。
2回にわたってGolang標準の testing パッケージを使ったユニットテストについてお伝えしてきました。

今回はGolangで作成したアプリケーションをテストする際に利用できるライブラリなどについて紹介します。

この文章中に登場するサンプルは GitHub にありますので、実際に動作させることが可能です。

$ go get github.com/duck8823/sample-go-testing
$ cd $GOPATH/src/github.com/duck8823/sample-go-testing
$ git checkout refs/tags/blog
$ dep ensure # 依存パッケージのダウンロード

なお、文章中のコマンドは全てバージョン1.9.2での動作を確認しています。

アプリケーションのテスト

アプリケーションをテストする場合はいくらかのテクニックが必要になります。
ここでは、モックを使ったテストやウェブアプリケーションのrouting(エンドポイント)のテストについてGolangでの書き方について記述します。

モック

通常、ある程度の大きさ以上のアプリケーションを作成する場合、複数のパッケージに分けて分割します。 分割したアプリケーションのそれぞれのコードをテストする場合、モックを利用して外部(テスト対象以外)の依存を減らすことが望ましいです。
Golangでは gomock が提供されており、 testing フレームワークと組み合わせて利用することができます。
gomock では静的なモック用のソースコードを作成します。

インストール

モックを生成する mockgen はcliツールですが、go get でインストールできます。
Golangはツールの配布・利用も簡単です。

$ go get github.com/golang/mock/mockgen

モックの作成

モックはインタフェースに対して作成します。

foods/food.go には food インタフェースが含まれているので、これに対してモックを生成します。

foods/food.go

package foods

type Food interface {
    Name() string
}

type Apple struct {
    cultivar string
}

func NewApple(cultivar string) *Apple {
    return &Apple{cultivar}
}

func (apple *Apple) Name() string {
    return apple.cultivar
}

mockgenコマンドを実行します。-sourceオプションでインタフェースが含まれるソース、-destinationオプションで出力先を指定します。

$ mockgen -source=foods/food.go --destination foods/mock_foods/mock_foods.go

foods/mock_foods/mock_foods.go

// Code generated by MockGen. DO NOT EDIT.
// Source: foods/food.go

// Package mock_foods is a generated GoMock package.
package mock_foods

import (
    gomock "github.com/golang/mock/gomock"
    reflect "reflect"
)

// MockFood is a mock of Food interface
type MockFood struct {
    ctrl     *gomock.Controller
    recorder *MockFoodMockRecorder
}

// MockFoodMockRecorder is the mock recorder for MockFood
type MockFoodMockRecorder struct {
    mock *MockFood
}

// NewMockFood creates a new mock instance
func NewMockFood(ctrl *gomock.Controller) *MockFood {
    mock := &MockFood{ctrl: ctrl}
    mock.recorder = &MockFoodMockRecorder{mock}
    return mock
}

// EXPECT returns an object that allows the caller to indicate expected use
func (m *MockFood) EXPECT() *MockFoodMockRecorder {
    return m.recorder
}

// Name mocks base method
func (m *MockFood) Name() string {
    ret := m.ctrl.Call(m, "Name")
    ret0, _ := ret[0].(string)
    return ret0
}

// Name indicates an expected call of Name
func (mr *MockFoodMockRecorder) Name() *gomock.Call {
    return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "Name", reflect.TypeOf((*MockFood)(nil).Name))
}

デフォルトのパッケージ名はソースとなるパッケージに mock_ の接頭辞をつけたものになります。これは -package オプションで変更することができます。
その他のオプションは gomock -help で確認することができます。

モックを使ったテスト

インタフェース food を引数にした以下の関数に対してテストを記述します。

func (duck *Duck) Eat(food foods.Food) string {
    return fmt.Sprintf("%s ate %s", duck.Name, food.Name())
}

モックインスタンスは以下のように作成します。

ctrl := gomock.NewController(t)
food := mock_foods.NewMockFood(ctrl)

作成したモックから EXPECT() に続いて関数を指定し、Return の引数で戻り値を指定することができます。

food.EXPECT().Name().Return("kougyoku")

上記の場合、 Name() が呼ばれたら "kougyoku" を返します。

animals/animals_07_test.go

package animals_test

import (
    "github.com/duck8823/sample-go-testing/animals"
    "github.com/duck8823/sample-go-testing/foods/mock_foods"
    "github.com/golang/mock/gomock"
    "testing"
)

func TestDuck_Eat_02(t *testing.T) {
    ctrl := gomock.NewController(t)
    defer ctrl.Finish()

    food := mock_foods.NewMockFood(ctrl)
    food.EXPECT().Name().Return("kougyoku")

    duck := animals.NewDuck("tarou")
    actual := duck.Eat(food)
    expected := "tarou ate kougyoku"
    if actual != expected {
        t.Errorf("got: %s\nwont: %s", actual, expected)
    }
}

上記の例でduck.Eat(food)では、FoodのName()を呼び出します。
Foodはインタフェースなので本来であればその実装に依存しますが、 モックを作成して特定の文字列を返却するように指定しているのでテスト実行時の依存を減らすことができます。

$ go test -v animals/animals_07_test.go animals/animal.go 
=== RUN   TestDuck_Eat_02
--- PASS: TestDuck_Eat_02 (0.00s)
PASS
ok      command-line-arguments  0.007s

この例ではName() の例では引数は必要ありませんでした。
戻り値を設定したい関数に引数が必要な場合は、呼び出される際の引数を指定して限定できます。
値が何でもいい場合は gomock.Any() を指定できます。

ここでは

type Hoge interface {
    Foo(foo string) string
}

というインタフェースを想定します。
モックを利用する場合は以下のようになります。

hogeMock.EXPECT().Foo(gomock.Any()).Return("bar")

フラグのテスト

コマンドライン引数やオプションなど、クライアントツールやサーバーアプリを作成した場合にフラグを利用することはよくあると思います。
フラグによって動作を変更する場合のテストを想定します。 標準の flag を利用してオプションを実現していた場合、設定する値を変えて複数回 flag.Parse() しようとすると flag redefined: ... とエラーになってしまいます。
そこで、フラグを設定する場合flag.Parse()は利用せずflag.NewFlagSet()で生成されたインスタンスを利用することで、テスタブルなコードを記述することができます。

フラグをパースする関数は以下のようにしました。

app/flag.go

package app

import (
    "flag"
    "os"
)

func ParseFlag(args ...string) string {
    flg := flag.NewFlagSet(os.Args[0], flag.ExitOnError)
    optC := flg.String("c", "default value", "flag usage")
    flg.Parse(args)

    return *optC
}

上記の関数は以下のように利用することができます。

package main

import "github.com/duck8823/sample-go-testing/app"

func main() {
    optC := app.ParseFlag(os.Args[1:]...)
    fmt.Printf("option c: %s", optC)
}

関数ParseFlagをテストするコードは以下のようにしました。

app/flag_test.go

package app_test

import (
    "github.com/duck8823/sample-go-testing/app"
    "testing"
)

func TestParseFlag(t *testing.T) {
    t.Run("with argument, returns value", func(t *testing.T) {
        actual := app.ParseFlag("-c", "hello")
        expected := "hello"

        if actual != expected {
            t.Errorf("got: %s\nwont: %s", actual, expected)
        }
    })

    t.Run("with no argument, returns default value", func(t *testing.T) {
        actual := app.ParseFlag()
        expected := "default value"

        if actual != expected {
            t.Errorf("got: %s\nwont: %s", actual, expected)
        }
    })
}
$ go test -v app/flag_test.go
=== RUN   TestParseFlag
=== RUN   TestParseFlag/with_argument,_returns_value
=== RUN   TestParseFlag/with_no_argument,_returns_default_value
--- PASS: TestParseFlag (0.00s)
    --- PASS: TestParseFlag/with_argument,_returns_value (0.00s)
    --- PASS: TestParseFlag/with_no_argument,_returns_default_value (0.00s)
PASS
ok      command-line-arguments  0.013s

異なる値でフラグのパースを複数回行なっていますが、エラーにならず実行できています。

Webアプリケーションのroutingをテストする

ウェブアプリケーションを開発する場合は、実際にエンドポイントへアクセスして正しい結果が返ってくるかテストすることがあります。

アプリケーションを起動してテストする

利用するフレームワークがhttp.Handlerの実装となっている場合は後述のhttptestが利用できるので、そちらを利用した方がよいです。

ここでは、実際にアプリを起動してhttpクライアントからリクエストを投げ、ハンドラーの想定通りのメソッドが実行されているかどうかを確認します。
また、このサンプルではEchoフレームワークを利用しています。

ランダムで空いてるポートをListen

多くのウェブフレームワークではサーバー起動時にポートを指定しますが、指定したポートが利用されていた場合はテストが実行できません。
以下の関数はランダムで空いてるポートを取得します。

func randomAddress(t *testing.T) net.Addr {
    t.Helper()

    listener, err := net.Listen("tcp", ":0")
    listener.Close()

    if err != nil {
        t.Fatal(err)
    }
    return listener.Addr()
}

サーバーの起動

以下のソースコードについてのテストを想定します。
実際にサーバーを起動し、正しいレスポンスが返却されるかをチェックします。

app/server.go

package app

import (
    "fmt"
    "github.com/labstack/echo"
    "net/http"
)

func CreateServer() *echo.Echo {
    e := echo.New()
    e.GET("/hello", hello)
    return e
}

func hello(c echo.Context) error {
    message := fmt.Sprintf("Hello %s.", c.QueryParam("name"))
    return c.String(http.StatusOK, message)
}

利用するウェブフレームワークがフォアグラウンドでサーバーを起動する場合、テストケース内でサーバーを起動すると、そこでテストがストップしてしまいます。
別のターミナルセッションでサーバーを起動した後でテストを実行することもできますがテスト実行以外のプロセスに依存するのは避けた方がよいでしょう。

goルーチン内でサーバーを起動することで、テストケース内で完結するようにしてみます。

app/server_test.go

package app

import (
    "io/ioutil"
    "net"
    "net/http"
    "net/url"
    "testing"
)

func Test_RoutingWithStartServer(t *testing.T) {
    addr := randomAddress(t)

    s := CreateServer()
    go func() {
        s.Start(addr.String())
    }()

    reqUrl := &url.URL{
        Scheme:   "http",
        Host:     addr.String(),
        Path:     "hello",
        RawQuery: "name=duck",
    }
    resp, err := http.Get(reqUrl.String())
    if err != nil {
        t.Fatal(err)
    }

    body, err := ioutil.ReadAll(resp.Body)
    if err != nil {
        t.Fatal(err)
    }

    actual := string(body)
    expected := "Hello duck."
    if actual != expected {
        t.Errorf("got: %s\nwont: %s", actual, expected)
    }
}

func randomAddress(t *testing.T) net.Addr {
    t.Helper()

    listener, err := net.Listen("tcp", ":0")
    listener.Close()

    if err != nil {
        t.Fatal(err)
    }
    return listener.Addr()
}

これを実行すると、

go test -v app/server_test.go app/server.go
=== RUN   Test_RoutingWithStartServer

   ____    __
  / __/___/ /  ___
 / _// __/ _ \/ _ \
/___/\__/_//_/\___/ v3.2.6
High performance, minimalist Go web framework
https://echo.labstack.com
____________________________________O/_______
                                    O\
⇨ http server started on [::]:50985
--- PASS: Test_RoutingWithStartServer (0.00s)
PASS
ok      command-line-arguments  0.021s

ログからも実際にサーバーが起動しているのがわかります。

goルーチンを利用してサーバーを起動した場合の課題

上述の例では正しく動いているように見えました。
しかしサーバーの起動に時間がかかってしまう場合はどうでしょうか。

--- a/vendor/github.com/labstack/echo/echo.go
+++ b/vendor/github.com/labstack/echo/echo.go
@@ -587,6 +587,7 @@ func (e *Echo) ServeHTTP(w http.ResponseWriter, r *http.Request) {
 
 // Start starts an HTTP server.
 func (e *Echo) Start(address string) error {
+       time.Sleep(30 * time.Second)
        e.Server.Addr = address
        return e.StartServer(e.Server)
 }

ウェブフレームワークechoのコードに手を加え、サーバーが起動する際にSleep処理を追加しました。

$ go test -v app/server_test.go app/server.go
=== RUN   Test_RoutingWithStartServer
--- FAIL: Test_RoutingWithStartServer (0.00s)
        server_test.go:27: Get http://[::]:64158/hello?name=duck: dial tcp [::]:64158: getsockopt: connection refused
FAIL
exit status 1
FAIL    command-line-arguments  0.013s

サーバーが立ち上がっていないのでconnection refusedのエラーが出てしまいました。
この場合、サーバーが立ち上がるまで待つといった工夫をしなければなりません。

サーバーの起動待ちを実装するのは面倒ですが、簡単に実現できる方法が用意されています。
ここではgoルーチンを使わない方法でテストを書き直してみましょう。

httptestを利用してテストを実行する

Golangでは、Webサーバーのテストをサポートするnet/http/httptestも用意されています。
このパッケージを利用することで、routingのテストも容易になります。

app/server_01_test.go

package app

import (
    "io/ioutil"
    "net/http/httptest"
    "testing"
)

func Test_RoutingWitHttpTest(t *testing.T) {
    s := CreateServer()
    server := httptest.NewServer(s)
    defer server.Close()

    client := server.Client()

    resp, err := client.Get(server.URL + "/hello?name=duck")
    if err != nil {
        t.Fatal(err)
    }

    body, err := ioutil.ReadAll(resp.Body)
    if err != nil {
        t.Fatal(err)
    }

    actual := string(body)
    expected := "Hello duck."
    if string(actual) != expected {
        t.Errorf("got: %s\nwont: %s", actual, expected)
    }
}

空いているポートの検索・利用は httptest が行なってくれるので、 シンプルに記述することができます。

$ go test -v app/server_01_test.go app/server.go
=== RUN   Test_RoutingWitHttpTest
--- PASS: Test_RoutingWitHttpTest (0.00s)
PASS
ok      command-line-arguments  0.013s

httptest.NewServerすることでラップされたサーバーが立ち上がります。 ウェブフレームワークのStart()をコールしているわけではないので、Sleepされません。
また、ポートも自分で指定せずにランダムで空いているポートを利用してくれます。

リクエストをシミュレーションする

httptestではサーバーを起動するほか、リクエストをシミュレーションする方法を用意しています。

レスポンスはResponseRecorderを介して行われます。
Recorderを利用することでレスポンス内容の取得も楽になります。

package app

import (
    "net/http/httptest"
    "testing"
)

func Test_RoutingWitHttpTestSimulate(t *testing.T) {
    s := CreateServer()

    req := httptest.NewRequest("GET", "/hello?name=duck", nil)
    rec := httptest.NewRecorder()

    s.ServeHTTP(rec, req)

    actual := rec.Body.String()
    expected := "Hello duck."
    if actual != expected {
        t.Errorf("got: %s\nwont: %s", actual, expected)
    }
}

サーバーを立ち上げる方法ではレスポンスのBodyio.Reader型のため変換が必要でしたが、 レコーダーのBodyio.Readerにバッファ機能をつけたリッチなbytes.Budder型となっています。
そのためString()で変換することができ、テストもシンプルに記述できました。

$ go test -v app/server_02_test.go app/server.go
=== RUN   Test_RoutingWitHttpTestSimulate
--- PASS: Test_RoutingWitHttpTestSimulate (0.00s)
PASS
ok      command-line-arguments  0.011s

最後に

これまで3回に渡ってGolangが標準で提供しているテストの機能の一部を紹介しました。 言語としてテストを強くサポートしていることが感じられたのではないでしょうか。
まだまだ紹介しきれていない機能やオプションなどがたくさんあります。
今後も有益な機能について紹介できればと思っております。

Golangでtestingことはじめ(2)〜テストにおける共通処理〜

こんにちは。
前回からGolangのテストについて紹介をしています。
今回の記事はその2回目(テストにおける共通処理)に当たります。

この文章中に登場するサンプルは GitHub にありますので、実際に動作させることが可能です。

$ go get github.com/duck8823/sample-go-testing
$ cd $GOPATH/src/github.com/duck8823/sample-go-testing
$ git checkout refs/tags/blog
$ dep ensure # 依存パッケージのダウンロード

なお、文章中のコマンドは全てバージョン1.9.2での動作を確認しています。

テストの共通処理

いくつかのテストケースを書いていて、共通処理をまとめたいと思ったことはないでしょうか。
他言語のテスティングフレームワークには、必ずといっていいほどこの機能が提供されています。

BeforeAll / AfterAll

全てのテストケースの前と後に実行するBeforeAllAfterAllを実現したい場合、

func TestMain(m *testing.M)

を利用します。

animals/animals_03_test.go

package animals_test

import (
    "github.com/duck8823/sample-go-testing/animals"
    "github.com/duck8823/sample-go-testing/foods"
    "os"
    "testing"
)

func TestMain(m *testing.M) {
    println("before all...")

    code := m.Run()

    println("after all...")

    os.Exit(code)
}

func TestDuck_Say_03(t *testing.T) {
    duck := animals.NewDuck("tarou")
    actual := duck.Say()
    expected := "tarou says quack"
    if actual != expected {
        t.Errorf("got: %v\nwant: %v", actual, expected)
    }
}

func TestDuck_Eat(t *testing.T) {
    duck := animals.NewDuck("tarou")
    apple := foods.NewApple("sunfuji")

    actual := duck.Eat(apple)
    expected := "tarou ate sunfuji"
    if actual != expected {
        t.Errorf("got: %v\nwant: %v", actual, expected)
    }
}

テストファイル内に TestMain が存在している場合、 go test はTestMainのみ実行します。 testing.MRun を呼ぶことで各テストケースが実行され、失敗か成功かに応じてコードを返却します。 最終的に os.Exit0 が渡ればそのテストファイルは成功、それ以外の値の場合は失敗になります。

Run の前後に処理を挟むことでBeforeAllAfterAllが実現できます。

$ go test -v ./animals/animals_03_test.go 
before all...
=== RUN   TestDuck_Say_03
--- PASS: TestDuck_Say_03 (0.00s)
=== RUN   TestDuck_Eat
--- PASS: TestDuck_Eat (0.00s)
PASS
after all...
ok      command-line-arguments  0.007s

BeforeEach / AfterEach

続いてテストケースごとに前処理や後処理を実行する方法です。

ループによるBeforeEachの実現

この方法は可読性も低く、テストケースを指定した場合無駄に処理が行われてしまうので推奨しません。

下記のサンプルコードではループとサブテストを利用し、 BeforeEachを実現しています。

animals/animals_04_test.go

package animals_test

import (
    "github.com/duck8823/sample-go-testing/animals"
    "github.com/duck8823/sample-go-testing/foods"
    "testing"
)

func TestDuck_04(t *testing.T) {

    println("before all...")
    var duck *animals.Duck

    for _, testcase := range []struct {
        name string
        call func(t *testing.T)
    }{
        {
            "it says quack",
            func(t *testing.T) {
                actual := duck.Say()
                expected := "tarou says quack"
                if actual != expected {
                    t.Errorf("got: %v\nwant: %v", actual, expected)
                }
            },
        }, {
            "it ate apple",
            func(t *testing.T) {
                apple := foods.NewApple("sunfuji")

                actual := duck.Eat(apple)
                expected := "tarou ate sunfuji"
                if actual != expected {
                    t.Errorf("got: %v\nwant: %v", actual, expected)
                }
            },
        },
    } {
        println("before each...")
        duck = animals.NewDuck("tarou")

        // テストケースの実行
        t.Run(testcase.name, testcase.call)

        println("after each...")
    }
    println("after all...")
}

コードが長くなってしまいましたが、

duck = animals.NewDuck("tarou")

の行ではテストケース毎に変数 duck を初期化しようとしています。

コード全体を見るとケース名と関数をスライスにいれ、それをループしてサブテストとして実行させています。
これを実行してみると、

$ go test -v ./animals/animals_04_test.go 
=== RUN   TestDuck_04
before all...
before each...
=== RUN   TestDuck_04/it_says_quack
after each...
before each...
=== RUN   TestDuck_04/it_ate_apple
after each...
after all...
--- PASS: TestDuck_04 (0.00s)
    --- PASS: TestDuck_04/it_says_quack (0.00s)
    --- PASS: TestDuck_04/it_ate_apple (0.00s)
PASS
ok      command-line-arguments  0.007s

テストケースの前後に処理を挟むことができました。

また、--run オプションで特定のテストケースのみを実行することができます。
ある関数のリファクタリングをする場合など早いフィードバックが欲しい時は、テストケースを指定することで実行時間の短縮が期待できます。

$ go test -v ./animals/animals_04_test.go --run TestDuck_04/it_says_quack
=== RUN   TestDuck_04
before all...
before each...
=== RUN   TestDuck_04/it_says_quack
after each...
before each...
after each...
after all...
--- PASS: TestDuck_04 (0.00s)
    --- PASS: TestDuck_04/it_says_quack (0.00s)
PASS
ok      command-line-arguments  0.007s

この場合も正しく実行できていますが、before each...after each... が余分にプリントされてしまっています。 --run オプションでは上から順にテストを実行し、一致しないものをスキップするようです。
スキップしたテストケースについても前処理を実行してしまうため、前処理が重い場合は全体の実行時間が長くなってしまいます。

前処理に5秒のSleepを追加してみます。

animals/animals_04_test.go

--- a/animals/animals_04_test.go
+++ b/animals/animals_04_test.go
@@ -4,6 +4,7 @@ import (
        "github.com/duck8823/sample-go-testing/animals"
        "github.com/duck8823/sample-go-testing/foods"
        "testing"
+       "time"
 )
 
 func TestDuck_04(t *testing.T) {
@@ -41,6 +42,7 @@ func TestDuck_04(t *testing.T) {
                duck = animals.NewDuck("tarou")
 
                // テストケースの実行
+               time.Sleep(5 * time.Second)
                t.Run(testcase.name, testcase.call)
 
                println("after each...")
$ go test -v ./animals/animals_04_test.go --run TestDuck_04/it_says_quack
=== RUN   TestDuck_04
before all...
before each...
=== RUN   TestDuck_04/it_says_quack
after each...
before each...
after each...
after all...
--- PASS: TestDuck_04 (10.01s)
    --- PASS: TestDuck_04/it_says_quack (0.00s)
PASS
ok      command-line-arguments  10.014s

Sleepを追加した結果、全体の実行時間が10秒もかかってしまいました。 これでは、テストケースを指定しても実行時間の短縮になりません。
また、前後処理とテストケース内の処理が分離されてしまいコード全体の可読性も悪くなってしまっています。

関数による共通化

上述の例では、テストケースの外で共通処理を呼び出すとテストケースを指定した場合は無駄に共通処理が行われてしまいました。
各テストケース内で共通化した関数を明示的に呼び出すよう書き換えてみましょう。

animals/animals_05_test.go

package animals_test

import (
    "github.com/duck8823/sample-go-testing/animals"
    "github.com/duck8823/sample-go-testing/foods"
    "testing"
    "time"
)

func TestDuck_05(t *testing.T) {
    t.Run("it says quack", func(t *testing.T) {
        duck := createInstance()

        actual := duck.Say()
        expected := "tarou says quack"
        if actual != expected {
            t.Errorf("got: %v\nwant: %v", actual, expected)
        }
    })

    t.Run("it ate apple", func(t *testing.T) {
        duck := createInstance()

        apple := foods.NewApple("sunfuji")

        actual := duck.Eat(apple)
        expected := "tarou ate sunfuji"
        if actual != expected {
            t.Errorf("got: %v\nwant: %v", actual, expected)
        }
    })
}

func createInstance() *animals.Duck {
    duck := animals.NewDuck("tarou")
    time.Sleep(5 * time.Second)

    return duck
}

可読性は非常に高くなりました。
また、

$ go test -v ./animals/animals_05_test.go --run TestDuck_05/it_says_quack
=== RUN   TestDuck_05
=== RUN   TestDuck_05/it_says_quack
--- PASS: TestDuck_05 (5.00s)
    --- PASS: TestDuck_05/it_says_quack (5.00s)
PASS
ok      command-line-arguments  5.011s

実行時間も前処理1回分になりました。

共通メソッドのエラー処理

共通メソッド内でエラーが発生した場合、テストを失敗させる必要があります。 そこで、共通メソッドに testing.TB インタフェースを渡してやります。 Fatal をコールすることでテストを失敗にし、その場でそのテストケースを終了させてやることができます。 Error の場合はテストを失敗にしますが、テストケースは引き続き実行されます。

--- a/animals/animals_05_test.go
+++ b/animals/animals_05_test.go
@@ -9,7 +9,7 @@ import (
 
 func TestDuck_05(t *testing.T) {
        t.Run("it says quack", func(t *testing.T) {
-               duck := createInstance()
+               duck := createInstance(t)
 
                actual := duck.Say()
                expected := "tarou says quack"
@@ -19,7 +19,7 @@ func TestDuck_05(t *testing.T) {
        })
 
        t.Run("it ate apple", func(t *testing.T) {
-               duck := createInstance()
+               duck := createInstance(t)
 
                apple := foods.NewApple("sunfuji")
 
@@ -31,9 +31,10 @@ func TestDuck_05(t *testing.T) {
        })
 }
 
-func createInstance() *animals.Duck {
+func createInstance(tb testing.TB) *animals.Duck {
        duck := animals.NewDuck("tarou")
        time.Sleep(5 * time.Second)
+       tb.Error("前処理で失敗しました.")
 
        return duck
 }
$ go test -v ./animals/animals_05_test.go
=== RUN   TestDuck_05
=== RUN   TestDuck_05/it_says_quack
=== RUN   TestDuck_05/it_ate_apple
--- FAIL: TestDuck_05 (10.00s)
    --- FAIL: TestDuck_05/it_says_quack (5.00s)
        animals_05_test.go:37: 前処理で失敗しました.
    --- FAIL: TestDuck_05/it_ate_apple (5.00s)
        animals_05_test.go:37: 前処理で失敗しました.
FAIL
exit status 1
FAIL    command-line-arguments  10.012s

Errorを使っているので残りのテストケースはちゃんと実行されていることが確認できますが、 2つのサブテストにおいて同一箇所で失敗したと表示されてしまいました。
特に1つのケース内で複数回コールされる関数の場合、どこで失敗したか特定しにくくなってしまいます。 これを、ケース内のどこで失敗したかわかるようにしてみます。

共通処理内で testing.TB インタフェースの Helper をコールすることで、 呼び出し部分が表示されるようになります。

先ほど変更したソースコードに、さらに変更を加えます。

--- a/animals/animals_05_test.go
+++ b/animals/animals_05_test.go
@@ -32,6 +32,8 @@ func TestDuck_05(t *testing.T) {
 }

 func createInstance(tb testing.TB) *animals.Duck {
+       tb.Helper()
+
        duck := animals.NewDuck("tarou")
        time.Sleep(5 * time.Second)
        tb.Error("前処理で失敗しました")
$ go test -v ./animals/animals_05_test.go
=== RUN   TestDuck_05
=== RUN   TestDuck_05/it_says_quack
=== RUN   TestDuck_05/it_ate_apple
--- FAIL: TestDuck_05 (10.01s)
    --- FAIL: TestDuck_05/it_says_quack (5.01s)
        animals_05_test.go:12: 前処理で失敗しました.
    --- FAIL: TestDuck_05/it_ate_apple (5.00s)
        animals_05_test.go:22: 前処理で失敗しました.
FAIL
exit status 1
FAIL    command-line-arguments  10.013s

表示されるソースコードの行数が変わっていることがわかります。 こちらの方がテストケース内のどこで失敗したか原因を探りやすくなると思います。

最後に

テストケース毎に実行する前処理や後処理は、Golangでは少し工夫が必要でした。
しかし、シンプルに記述することができ処理の流れが分かりやすいようになっていると思います。

次回はアプリケーションやツールのテストで利用できる機能(gomockhttptest)について紹介します。

Golangでtestingことはじめ(1)〜testingパッケージを使ったユニットテスト〜

こんにちは。
Golangが一般的に使われるようになってきてもう久しいですね。
最近作られたSWET製のツールでも、Golangを採用したものがあります。
そこで、Golangの標準テストパッケージtestingやその他についてまとめたいと思います。

今回から3回にわたり、

を紹介します。

この記事を読んで一通りGolangでテストがかけるようになると嬉しいです。

この文章中に登場するサンプルは GitHub にありますので、実際に動作させることが可能です。

$ go get github.com/duck8823/sample-go-testing
$ cd $GOPATH/src/github.com/duck8823/sample-go-testing
$ git checkout refs/tags/blog
$ dep ensure # 依存パッケージのダウンロード

なお、文章中のコマンドは全てバージョン1.9.2での動作を確認しています。

testingパッケージ

testingパッケージはGolangが標準で提供している、テスト全般を支援するパッケージです。
ベンチマークやカバレッジ、標準出力のテストなどカバーしている範囲は広く、サードパーティ製のテストフレームワークに頼らずともテストが記述できます。 標準なのでGolangをインストールしたら使えます。パッケージマネージャなどで指定する必要はありません。
以下のtypeについてユニットテストを書いてみましょう。

animals/animal.go

package animals

import (
    "fmt"
    "github.com/duck8823/sample-go-testing/foods"
)

type Duck struct {
    name string
}

func NewDuck(name string) *Duck {
    return &Duck{name}
}

func (duck *Duck) Say() string {
    return fmt.Sprintf("%s says quack", duck.name)
}

func (duck *Duck) Eat(food foods.Food) string {
    return fmt.Sprintf("%s ate %s", duck.name, food.Name())
}

foods/food.go

package foods

type Food interface {
    Name() string
}

type Apple struct {
    cultivar string
}

func NewApple(cultivar string) *Apple {
    return &Apple{cultivar}
}

func (apple *Apple) Name() string {
    return apple.cultivar
}

testing では、 _test.go で終わる名前のファイルにテストコードを書きます。
また、TestXxxで始まる関数についてテストを実行します。

なお、テストコードは対応するソースコードと同一のパッケージにすることでpackage privateな変数や関数を呼び出すことができ、 APIを必要以上公開せずにテストを書くことができます。

animals/animals_test.go

package animals

import "testing"

func TestDuck_name(t *testing.T) {
    duck := &Duck{"tarou"}
    actual := duck.name
    expected := "tarou"
    if actual != expected {
        t.Errorf("got: %v\nwant: %v", actual, expected)
    }
}

パッケージ名_test をテストコードを記述するパッケージ名として利用することもできます。 パッケージ外に公開したAPIを通してのみテストしたい場合は、こちらを利用するとよさそうです。
この場合、テスト対象のパッケージもインポートする必要があります。

animals/animals_01_test.go

package animals_test

import "testing"
import "github.com/duck8823/sample-go-testing/animals"

func TestDuck_Say(t *testing.T) {
    duck := animals.NewDuck("tarou")
    actual := duck.Say()
    expected := "tarou says quack"
    if actual != expected {
        t.Errorf("got: %v\nwant: %v", actual, expected)
    }
}

テストを記述したら実行しましょう。 go testの引数にはテストが記述されたファイルを指定することができます。 テストがプロダクトコードと同一のパッケージの場合、引数にテスト対象のファイルを含める必要があります。

$ go test animals/animals_test.go animals/animal.go

プロダクトコードとテストコードのパッケージを分けてimportしている場合は、単一のファイルでも実行可能です。

$ go test animals/animals_01_test.go

他の言語ではビルドツールやテストランナーを介して実行するものが多い中、 goのサブコマンドとしてtestを実行できることからも、言語として積極的にサポートしているのがわかります。

go testの引数はファイルの他、github.com/duck8823/sample-go-testing/animalsのようにパッケージを指定することもできます。 上記の記述だと冗長的になってしまいますが、パッケージの指定はディレクトリからの相対パスとして記述することもできます。

$ go test ./animals

パッケージングされたアプリケーションを作成している場合は ./... を指定することで全ディレクトリのテストを再帰的に実行してくれます。

$ go test ./...

(1.9より以前のバージョンの場合は)

$ go test $(go list ./... | grep -v /vendor)

実行結果は以下のように表示されます。

ok      command-line-arguments  0.007s

詳細な結果を見たい場合は、-vオプションが有効です。

$ go test -v animals/animals_01_test.go
=== RUN   TestDuck_Say
--- PASS: TestDuck_Say (0.00s)
PASS
ok      command-line-arguments  0.007s

アサーション

標準のtestingパッケージでは、アサーション用の関数が用意されていません。
Errorf などの関数を利用し、自分でエラーメッセージを書く必要があります。

duck := animals.NewDuck("tarou")
actual := duck.Say()
expected := "tarou says quack"
if actual != expected {
    t.Errorf("got: %v\nwant: %v", actual, expected)
}

testify のようなサードパーティ製のアサーションライブラリも存在しています。
これらのライブラリを利用することで、記述が容易になります。

import "github.com/stretchr/testify/assert"
duck := animals.NewDuck("tarou")
actual := duck.Say()
expected := "tarou says quack"
assert.Equals(t, expected, actual)

サブテスト

テストを階層構造にすることができます。
サブテストはテストケース内で t.Run をコールすることで実現できます。
第一引数にはテストケース名、第二引数には無名関数を渡すことができます。

animals/animals_02_test.go

package animals_test

import (
    "github.com/duck8823/sample-go-testing/animals"
    "github.com/duck8823/sample-go-testing/foods"
    "testing"
)

func TestDuck(t *testing.T) {
    duck := animals.NewDuck("tarou")

    t.Run("it says quack", func(t *testing.T) {
        actual := duck.Say()
        expected := "tarou says quack"
        if actual != expected {
            t.Errorf("got: %v\nwant: %v", actual, expected)
        }
    })

    t.Run("it ate apple", func(t *testing.T) {
        apple := foods.NewApple("sunfuji")

        actual := duck.Eat(apple)
        expected := "tarou ate sunfuji"
        if actual != expected {
            t.Errorf("got: %v\nwant: %v", actual, expected)
        }
    })
}

テスト結果は以下のように表示されます。

$ go test -v ./animals/animals_02_test.go 
=== RUN   TestDuck
=== RUN   TestDuck/it_says_quack
=== RUN   TestDuck/it_ate_apple
--- PASS: TestDuck (0.00s)
    --- PASS: TestDuck/it_says_quack (0.00s)
    --- PASS: TestDuck/it_ate_apple (0.00s)
PASS
ok      command-line-arguments  0.006s

ベンチマーク

Golangのtestingパッケージでは、ベンチマークも標準でサポートしており、簡単に記述することができます。 ベンチマークは、関数を以下のように定義することで実現できます。

func BeanchmarkXxx(b *testing.B) {
    for i := 0; i < b.N; i++ {
        //  ここに処理を記述
    }
}

animals/animals_06_test.go

package animals_test

import (
    "github.com/duck8823/sample-go-testing/animals"
    "github.com/duck8823/sample-go-testing/foods"
    "testing"
)

func BenchmarkDuck_Say(b *testing.B) {
    duck := animals.NewDuck("tarou")

    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        duck.Say()
    }
    b.StopTimer()
}

func BenchmarkDuck_Eat(b *testing.B) {
    duck := animals.NewDuck("tarou")
    food := foods.NewApple("sunfuji")

    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        duck.Eat(food)
    }
    b.StopTimer()
}

ベンチマークの実行は -bench オプションをつけます。

$ go test -v -bench=. ./animals/animals_06_test.go
goos: darwin
goarch: amd64
BenchmarkDuck_Say-4     10000000               139 ns/op
BenchmarkDuck_Eat-4      5000000               407 ns/op
PASS
ok      command-line-arguments  3.965s

出力結果はループの回数とループ1回あたりの処理時間です。 -benchmem オプションをつけることで、メモリに関するベンチマークも取得することができます。

前処理や後処理がある場合は ResetTimerStopTimer 関数を呼び出して正しく測定できるようにしましょう。

func BeanchmarkXxx(b *testing.B) {
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        //  ここに処理を記述
    }
    b.StopTimer()
}

カバレッジ

カバレッジも標準でサポートされています。
-cover オプションをつけることで、テスト実行結果にカバレッジ情報が付加されます。

$ go test -cover ./animals
ok      github.com/duck8823/sample-go-testing/animals   10.014s coverage: 100.0% of statements

カバレッジレポートの出力

カバレッジレポートを出力するためにには -coverprofile オプションを利用しますが、 バージョン1.9(2018/01/08現在)では複数のパッケージにまたがって利用することができません。

$ go test -cover -coverprofile cover.out ./animals ./foods
cannot use test profile flag with multiple packages

1.10からはサポートされるようなので、試してみましょう。

beta版のインストールは以下の手順で行います。

go get golang.org/x/build/version/go1.10beta1
go1.10beta1 download

go コマンドをインストールした go1.10beta1 に置き換えて実行してみましょう。

$ go1.10beta1 test -cover -coverprofile cover.out ./animals ./foods
ok      github.com/duck8823/sample-go-testing/animals   10.009s coverage: 100.0% of statements
ok      github.com/duck8823/sample-go-testing/foods 0.006s  coverage: 100.0% of statements

cover.outの出力結果は以下のようになりました。

mode: set
github.com/duck8823/sample-go-testing/foods/food.go:11.39,13.2 1 1
github.com/duck8823/sample-go-testing/foods/food.go:15.35,17.2 1 1
github.com/duck8823/sample-go-testing/animals/animal.go:12.33,14.2 1 1
github.com/duck8823/sample-go-testing/animals/animal.go:16.32,18.2 1 1
github.com/duck8823/sample-go-testing/animals/animal.go:20.47,22.2 1 1

-coverprofile で出力されるカバレッジレポートは見にくいので、 htmlとして出力しましょう。
カバレッジレポートからhtmlを生成するのも標準機能です。

go tool cover -html=cover.out -o cover.html

f:id:swet-blog:20180115132650p:plain

最後に

今回は紹介しませんでしたが他にもテストのスキップや、標準出力のテストが容易になるExampleといった魅力的な機能があります。 Golangは 公式ドキュメント も充実しているので、是非ご覧ください。

次回はtestingパッケージを利用して共通処理(Before/After)を実現する方法について紹介します。