DeNA Testing Blog

Make Testing Fun, Smart, and Delighting End-Users

本日(11/5)販売開始:書籍「Androidテスト全書」のUIテスト部分を執筆しました

こんにちは。SWETの外山(@sumio_tym)です。 本日、書籍「Androidテスト全書」の一般販売が開始されました! 本書のUIテスト部分(第4〜6章)は、SWETの平田(@tarappo)と私が執筆しています。

f:id:swet-blog:20181029165224j:plain

本書の一般販売を記念して、本エントリーでは本書全体の概要と想定読者を紹介してから、 それぞれの担当著者がUIテスト各章の「見どころ」を解説します。

本書の概要

本書の目次は次のとおりです。

  • 第1章:テスト入門
  • 第2章:ユニットテスト実践入門
  • 第3章:ユニットテスト応用編
  • 第4章:UIテスト(概要編)
  • 第5章:UIテスト(Espresso編)
  • 第6章:UIテスト(Appium編)
  • 第7章:JUnit 5
  • 第8章:CI/CD

ユニットテストやUIテストはもちろん、 最新のテストフレームワークであるJUnit 5や、 テストの運用や開発プロセスの効率化に欠かせないCI/CDまでしっかり解説されています。

このようにAndroidのテスト(正確には自動テスト)すべてをカバーしている本書ですが、 公式サイトのチュートリアルのレベルにとどまることなく、実践的な内容まで踏み込んで解説しています。

また、ネット上に散らばっている古い情報や間違った情報に振り回されることなく、 最新の正しい情報を学べるというのも本書の大きな利点です。

本書の対象読者

このように本書の内容はとても充実していますが、 Androidのアプリ開発経験があれば自動テスト未経験でも読み進められるように意識して書かれています。

本書の「まえがき」には対象読者として次のように書かれています。 Androidの自動テストに関心のある方であれば、自動テスト経験にかかわらずおすすめの一冊になっています。

  • テストを書いた方がいいと思いつつ書けていない方
  • テストを書いているが、もっといい書き方があると思っている方
  • さらに発展的な内容を求める方
  • 安定したアプリを継続的にリリースしたいすべてのAndroidエンジニア

第4章「UIテスト(概要編)」の見どころ(執筆:外山)

4章ではUIテストにありがちな誤解を無くすべく、次の内容を盛り込みました。

  • UIテストを書きはじめる前に検討した方が良いこと
  • EspressoとAppiumの比較
  • テストツールの種類に依存しない、UIテストを長く運用し続けるためのポイント

実は、本書の当初の構想ではUIテストの解説はEspressoとAppiumのみの予定でした。 しかし、具体的な章立ての検討に入った時点で、当初の構想では次のような懸念を払拭し切れないことに気付きました。

  • いきなりUIテストツールの解説が始まると、読者が常にUIテストを書くべきだと誤解しないだろうか?
  • EspressoとAppiumの特徴がわからないと、読者がどちらを採用すれば良いか分からないのではないか?

それらに対する解決策として執筆したのがこの第4章です。

「UIテストを書き始めたけど辛くなってやめてしまった」という悲劇が少しでも減ることを願っています。

第5章「UIテスト(Espresso編)」の見どころ(執筆:外山)

5章は、Espressoの入門者が本書から学ぶことで、実用レベルのUIテストを書けるようになることを目指して執筆しました。

Espresso Test Recorderの使い方やEspresso APIの概要といった基本的な部分をきちんと押さえつつ、 実用レベルでは必ず必要となる次の点を丁寧に解説しています。

  • Page Objectデザインパターンを実践して長く使われ続けるテストにする方法
  • (難しいIdlingResourceだけに頼らない)画面更新の完了を待つためのテクニック

また、 テストを書いていてよく直面する「これってどうすればテスト書けるんだろう?」を解決すべく、 良くあるシーン別の解決方法も説明しています。

まさに、Androidアプリ開発を一通り学んだエンジニアがEspressoを自習できる内容に仕上がったと思っています。 本章をきっかけに、Espressoを実用レベルで使えるエンジニアが増えることを願っています。

第6章「UIテスト(Appium編)」の見どころ(執筆:平田)

この6章では他の章とは異なり、Android特有の話というわけではなく、AppiumというUIテストツールについて書いています。

本章では、このAppiumを使ってUIテストを実装する方法を書いています。 また、本書のために弊社のプロダクトに対して実際にUIテストを1から導入した話を載せています。

UIテストについての日本語の情報は少しずつ増えているように思いますが、まだまだ少ない状況だと思います。 特に実際にUIテストを導入した実績が書かれた話はあまり見たことがありません。

また、5章ではEspressoにふれています。 EspressoとAppiumの2つについて紹介し、それぞれのことを1冊の本で紹介するというのはなかなかないと思います。 これらの情報が、少しでも皆様の知見になればと思います。

終わりに

SWETメンバーが執筆に参加した「Androidテスト全書」について紹介しました。

Androidアプリ開発を一通り学んだエンジニアがテストについて学ぶ際に「次に読む一冊」として自信を持っておすすめできます! このエントリーを読んで少しでも興味を持たれた方は、 是非本書の公式サイトをチェックしてみてください!

また、11/30(金)には 「Android Test Night #5 - Androidテスト全書の回 -」 と題したイベントの開催を予定しています。 本書の筆者、編集者ともに登壇予定ですので合わせてご参加ください!

WebdriverIOでAppiumを使う勘所

こんにちは。SWETの外山(@sumio_tym)です。 SWETの一員になって約9か月、Appiumを使ってAndroidアプリのUIテスト自動化を行いつつ、 DroidKaigi 2018に登壇したり、 書籍「Androidテスト全書」を執筆したりしていました1

先日(2018年9月28日)に電子版が正式リリースされた「Androidテスト全書」の宣伝をしたいのもやまやまなのですが、 今回はAppiumを使ったAndroidのUIテスト自動化業務で得られたノウハウを紹介します。

Appiumを使ったUIテスト自動化経験があっても、使っているプログラミング言語は組織やプロジェクトによって様々だと思います。 本エントリーでは、Appiumの経験はあるもののJavaScriptでテストを書くのは初めての方に向けて、 クライアントライブラリにWebdriverIOを採用するときのノウハウを次の3点に分けて説明します。

  • セットアップするときのポイント
  • テストコードを書くときのポイント
  • テスト失敗時に解析しやすくする工夫

Appium経験者に向けたエントリーであるため、Appiumの詳しい解説はしていません。 Appiumについて詳しく知りたい方は公式ドキュメントを参照してください。

また、ノウハウの一部はAndroidでしか通用しないものもありますのでご注意ください。

WebdriverIOとは

Appium向けのクライアントライブラリのうち、JavaScriptに対応しているものは次の2つです。 どちらもJavaScript(Node.js)によるWebDriver実装です。

今回取り上げるWebdriverIOで特徴的なものは次の2点です。

  • 同梱されているCLIベースのテストランナーwdio
  • WebdriverIOサービスプラグインwdio-appium-service

wdioを使うと、async/awaitを使わずともテストコードを同期的に書くことができます。 JavaScriptに付きものの非同期処理から解放されてテストコードを書けるのは、思いの外便利です。

wdio-appium-serviceはWebdriverIOとAppiumを協調動作させるためのプラグインです。 このプラグインを使えばテスト実行・終了と合わせて、自動的にAppiumを起動・終了してくれます。

以降で説明するようにセットアップすれば、両者の機能をフル活用してテストを書き始めることができます。

なお、今回は次のバージョンで動作を確認しました。

  • Node.js: 10.9.0
  • WebdriverIO: 4.3.12
  • Appium: 1.9.0
  • wdio-appium-service: 0.2.3

セットアップするときのポイント

インストールと設定ファイルの雛形作成

Node.jsは既にインストールされているものとします。 テストコードを書くための空ディレクトリを作成し、 以下のようにwebdriverioパッケージをインストールします。

$ npm init
$ npm install --save-dev webdriverio

次に、以下のコマンドを実行します。 このコマンドは対話形式でWebdriverIOの設定ファイルを作成するものです。

$ npx wdio config

いくつか質問されますが、以下の質問以外は全てデフォルトのままEnterを押して先に進めてください。

  • Which reporter do you want to use?: テスト結果レポートをどのように表示するか選択します。
    こだわりがなければspecjunitを選択しておくのが無難です。
  • Do you want to add a service to your test setup?: appiumを選択します。 ここでappiumを選択すると、テスト実行の度にAppiumが自動的に起動するようになります。
  • Level of logging verbosity: 原因解析に有用ですのでverboseにするのがお勧めです。

全ての質問に回答するとWebdriverIOの設定ファイルwdio.conf.jsの雛形が生成されます。 あわせて、関連パッケージが自動的にインストールされます。

最後にAppium本体とアサーションライブラリ(ここではchai)をインストールします。

$ npm i --save-dev appium chai

wdio.conf.jsファイルの編集

生成された設定ファイルwdio.conf.jsは、そのままではAppiumを使ったテストを書くことができません。 少なくとも以下の修正が必要です。

同時起動数を1にする

WebdriverIOにはテストをできるだけ並行実行するという特徴がありますが、 そのときにAppiumも同じ待ち受けポートで複数個起動してしまい、うまく動作しません。

その事象を回避するため、maxInstances1にしてください。

exports.config = {
  ...
  maxInstances: 1,
  ...
}

Desired Capabilitiesを適切に設定する

設定ファイルの雛形にはFirefoxを利用するDesired Capabilitiesが設定されています。 この部分をAppiumで利用するDesired Capabilitiesに置き換えてください。 たとえば以下のようになります。

exports.config = {
  ...
  capabilities: [{
    platformName: 'Android',
    automationName: 'UiAutomator2',
    app: './app-release.apk',
    deviceName: 'Android Device',
    unicodeKeyboard: true
  }],
  ...
}

capabilitiesにはDesired Capabilitiesの配列を指定するようになっていますが、 配列の要素は1つだけにしてください。 複数の要素を持たせると、書いた要素の数だけAppiumが同時に起動してしまいます。

また、雛形にはcapabilitiesの中にもmaxInstancesが設定されていますが、 こちらも同じ理由で削除しなければなりません。

接続先情報を設定する

Appiumサーバの待ち受けポートのデフォルト値は4723ですが、 WebdriverIOの接続先ポート番号のデフォルト値は異なります。そのため、以下のとおり接続先を明示的に指定してください。

exports.config = {
  ...
  host: 'localhost',
  port: 4723,
  ...
}  

npm testでテストを実行できるようにする

最後に、package.jsonを以下のように変更します。

{
  ...
  "scripts": {
    "test": "wdio",
    ...
  },
  ...
}

これでnpm testコマンドを使ってテストを実行できるようになりました。

テストコードを書くときのポイント

次に、テストコードを書くときに、Appiumだからこそはまるポイントを説明します。 WebdriverIOの詳しい使い方は公式ドキュメントに譲りますが、 次の点を押さえておくと、これから説明する内容が理解しやすくなると思います。

  • テストコードからは、グローバル変数browserにアクセスできます
  • browserが提供するメソッドの一覧はWebdriverIO APIで確認できます
  • browserが提供するメソッドは非同期ですが、前述のwdioテストランナーから呼び出されるときはawaitなしでも同期呼び出しになります
  • UIコンポーネントの操作はbrowser.click(selectorText)のように行います

UIコンポーネントの特定

簡略化された書き方 でUIコンポーネントを探せるのがWebdriverIOの特徴のひとつになっています。 しかし、この書き方はブラウザを操作するときであれば威力を発揮するものの、モバイルアプリではそうはいきません。

特に「テキスト」の判定は、ブラウザを前提とした公式ドキュメントの説明に惑わされてはいけません。 ブラウザで「テキスト」と言うと、<span>この部分</span>を指しますが、 Androidでは<android.widget.Button text="この部分" />になるため、WebdriverIOの簡略記法は使えないのです。

たとえばAndroidの場合は、次のようなユーティリティメソッドを用意しておくと良いでしょう。

module.exports = {
  /** リソースIDを指定するセレクタ */
  resourceId(id) {
    return `//*[@resource-id="${id}"]`;
  },

  /** 表示テキストを指定するセレクタ */
  text(text) {
    return `//*[@text='${text}']`;
  },

  /** contentDescription属性を指定するセレクタ */
  accessibilityId(text) {
    return `~${text}`;
  },

  /** UIコンポーネントのクラス名(android.widget.Buttonなど)を指定するセレクタ */
  className(className) {
    return `android=new UiSelector().className("${className}")`;
  }
};  

このユーティリティメソッドを使えば、 「OKと表示されたUIコンポーネントをクリックする」という操作は次のように書けます。

const by = require(...);
browser.click(by.text('OK'));

スクロール

WebdriverIOには scroll(selectorText)メソッドが存在しており、 ドキュメントには、あるコンポーネントが画面内に入るまでスクロールできると書かれています。

しかし、このメソッドはAppiumでは動作しませんので、自身で実装が必要です。 たとえば、下方向にスクロールする実装は次のようになります。

  scrollDown(selectorText) {
    const screenSize = browser.windowHandleSize().value;
    const width = screenSize.width;
    const height = screenSize.height;
    const isOnScreen = () => browser.isExisting(selectorText) && browser.isVisible(selectorText);
    browser.waitUntil(() => {
      // 既に画面内に有る場合は、スクロールせずに脱出する
      if (isOnScreen()) {
        return true;
      }

      // 画面中央をタップし、少し200pxだけy方向に動かす。
      browser.touchAction([
        {
          action: 'press',
          x: width / 2,
          y: height / 2
        },
        // Appium1.8からはこのwaitが必要
        {
          action: 'wait',
          ms: 500
        },
        {
          action: 'moveTo',
          x: width / 2,
          y: height / 2 + 200
        },
        'release'
      ]);

      return isOnScreen();
    }, 180000);
  }

このサンプルコードでは、最初に端末の画面サイズを取得しています。 その後、目的のUIコンポーネントが画面内に見つかるかタイムアウト(ここでは180秒)するまで、以下の処理を繰り返しています。

  • pressで画面中央をタップします
  • waitで500msec待ちます。この処理はAppium 1.8より必要になりました
  • moveToで、画面中央から200pxだけ下方向に指を動かします
  • releaseで指をリリースします

テスト失敗時に解析しやすくする工夫

テストに失敗したときには、次の情報があると解析が捗ります。

  • Appiumのログ
  • テストに失敗したときのスクリーンショット
  • テストを実行した端末のログ

このうちAppiumのログは、ログレベルをverboseにしておけば標準出力に表示されます。 残りの2つについてAndroidの場合の設定を紹介します。

スクリーンショットを保存する

WebdriverIOはデフォルトで、コマンド(browserが提供している各メソッド)実行に失敗したタイミングでスクリーンショットを保存してくれます2。 ところが、画面に表示されている文字列が想定と異なる場合などではスクリーンショットが保存されません。 そのようなケースではassertには失敗しているものの、コマンドの実行は成功しているからです。

この問題を解決するため、テスト失敗時(assertに失敗したとき)にもスクリーンショットを保存するようにします。 テストが終了する度にwdio.conf.jsafterTest関数(デフォルトではコメントアウトされています)がコールバックされるため、その中にスクリーンショットを保存する処理を書いていきます。

exports.config = {
  ...
  /**
   * Function to be executed after a test (in Mocha/Jasmine) or a step (in Cucumber) ends.
   * @param {Object} test test details
   */
  afterTest: async function(test) {
    // エラーでないときは何もせずにreturnする
    if (!test.err) {
      return;
    }

    const fs = require('fs');
    const dateFormat = require('dateformat');
    // ファイル名を現在時刻(秒)で生成するため、重複しないように1秒スリープする
    await browser.pause(1000);
    const dateString = dateFormat(Date.now(), 'isoDateTime');

    // スクリーンショットの保存
    const screenshotFileName = `screenshot-${dateString}.png`;
    await browser.saveScreenshot(`./screenshots/${screenshotFileName}`);
  },
  ...
}  

このサンプルコードでは./screenshots/ディレクトリにscreenshot-2018-10-02T21:58:29+0900.pngのようなファイル名でスクリーンショットを保存しています。 ファイル名に現在時刻を含めるためにdateformatを利用していますので、 あらかじめnpm installコマンドでdateformatをインストールしておいてください。

スクリーンショットを取得しているのはbrowser.saveScreenshot()です。 afterTest関数の中ではbrowserが提供しているAPI呼び出しであっても非同期呼び出しになるため、 明示的にawaitキーワードを付けて処理の終了を待たなければならない点に注意してください。

logcatを保存する

WebdriverIOではbrowser.log()の引数に‘logcat’を指定することで、logcatを取得できます。 スクリーンショットを保存したときと同じく、wdio.conf.jsafterTest関数に処理を追加していきましょう。

前述のスクリーンショット保存コードに続けて、次のコードを追加してください。

    // logcatの保存
    const logcatFileName = `logcat-${dateString}.log`;
    const logcats = await browser.log('logcat');
    logcats.value.map(o => {
      const timestamp = dateFormat(new Date(o.timestamp), 'yyyy-mm-dd HH:MM:ss o');
      const message = o.message;
      return `${timestamp} - ${message}\n`;
    }).forEach(logline => {
      fs.appendFileSync(`./logs/${logcatFileName}`, logline);
    });

browser.logcat()はlogcatの各行(timestampmessageで構成)を要素とした配列を返します。 このサンプルコードでは、各行をyyyy-mm-dd HH:MM:ss +0900 - ログメッセージという形に加工して上で ./logsディレクトリにlogcat-2018-10-02T21:58:29+0900.logのようなファイル名で保存しています。

afterTest関数の全体像

前述の2つの処理を書いたafterTest関数の全体像は次の通りです。 コピーして試してみる場合は、./logsディレクトリと./screenshotsディレクトリを事前に作成しておいてください。

exports.config = {
  ...
  /**
   * Function to be executed after a test (in Mocha/Jasmine) or a step (in Cucumber) ends.
   * @param {Object} test test details
   */
    // エラーでないときは何もせずにreturnする
    if (!test.err) {
      return;
    }
    const fs = require('fs');
    const dateFormat = require('dateformat');
    // ファイル名を現在時刻(秒)で生成するため、重複しないように1秒スリープする
    await browser.pause(1000);
    const dateString = dateFormat(Date.now(), 'isoDateTime');

    // スクリーンショットの保存
    const screenshotFileName = `screenshot-${dateString}.png`;
    await browser.saveScreenshot(`./screenshots/${screenshotFileName}`);

    // logcatの保存
    const logcatFileName = `logcat-${dateString}.log`;
    const logcats = await browser.log('logcat');
    logcats.value.map(o => {
      const timestamp = dateFormat(new Date(o.timestamp), 'yyyy-mm-dd HH:MM:ss o');
      const message = o.message;
      return `${timestamp} - ${message}\n`;
    }).forEach(logline => {
      fs.appendFileSync(`./logs/${logcatFileName}`, logline);
    });
  },
  ...
}  

まとめ

WebdriverIOでAppiumを使ったテストを書くときのノウハウを紹介しました。 WebdriverIOの公式ドキュメントにはAppiumの場合の説明が少ないのですが、 本エントリで紹介した内容を押さえておけば、基本的なテストは書き始められると思います。 参考にしてみてください。


  1. 大変ありがたいことに、業務時間の一部を執筆活動に充てることをリーダーの@okitanさんに快諾していただきました。このような柔軟性がSWETグループの魅力のひとつです!

  2. 保存先はwdio.conf.jsscreenshotPathで指定したディレクトリ(デフォルト値は'./errorShots/')です。

reviewdogによるGoのコードレビュー

こんにちは。ゲーム・エンターテインメント事業本部の鈴木です。
AndAppの開発をしています。

今回は私たちのチームで使っているreviewdogについて、CIの設定やlinterの組み合わせなど、どのようにしてコードレビューに活用しているか紹介します。

reviewdogとは

一言でいうとコードレビューを補助してくれるコマンドラインツールです。
各種linterの実行結果を渡してあげると、Pull Requestなどの差分に関して警告された行を教えてくれます。

私たちのチームではほとんどがGo言語による開発なため、golintなどの結果を表示するために使っています。
開発はGitHub Enterprise上で行なっており、CircleCI Enterpriseからreviewdogを実行すると以下のような警告がPull Requestのレビューコメントとして付きます。

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

似たようなツールであるDangerはPull Request全体に関わるチェックを得意としており、

  • Pull RequestのTitleおよびDescription
  • Pull Requestのファイル数や行数
  • Pull Requestに含まれるファイル名

などを元にする時にはとても便利ですが、linterとの連携という点ではreviewdogの方が簡単に使えます。

なぜreviewdogを導入したのか

以下の3点からreviewdogの導入を決めました。

1. lintの結果をPull Requestのレビューコメントに表示できる

それまでは人が細かい部分までレビューをしていたため、そこに気を取られ過ぎてなかなか本質的なレビューに進めないということがありました。
そうなると双方が、細かい修正やその確認で消耗してしまい、レビュー自体が後回しになりがちという悪循環に陥っていました。
特にレビュアーへの時間や精神的な負担が大きく、その一部でも代行してくれるような仕組みが求められていました。

単純にlintの結果を表示するだけならDangerでも可能ですが、通常のコメントとして表示してしまうと何が警告されたのかわかりにくくなってしまいます。
かといって該当行に警告を表示しようとすると、様々なlinterの出力ごとに該当行を特定したり、APIを呼び出したりといった作り込みをしなければなりません。
reviewdogはそのあたりを吸収してくれるので人の代わりにレビューを行なってくれるツールとしてぴったりでした。

2. 改修のあった部分のみを警告できる

また、対象となるコードは既にサービスとしてリリースされていましたが、それまで一度もlinterをかけたことが無かったので大量の警告がある状態でした。
しかも開発は日々続いており、全てを直してからlinterを導入するのも現実的ではなく、改修のタイミングで段階的に対応していく必要がありました。
当然reviewdogはそのようなユースケースも想定されているのでPull Requestの差分に含まれない行の警告をフィルタリングしてくれます。

3. 任意のlinterを使用できる

最後は任意のlinterをかけたいという要求です。
AndAppではインフラにGoogle Cloud Platformを採用していますが、そのAPIの使い方を誤ってしまうことがありました。
こちらについては人によるチェックだと見逃されてしまうことがあるため、ツールを活用したいということをDeNA TechCon 2018でお話ししました。

しかし、既存のlinterでは私たちがチェックしたい内容を満たすものが無かったため、独自のlinterを作成してチェックするようにしました。
こういったケースでもreviewdogはlinterの出力をどのように扱うのかを簡単かつ柔軟に指定できるため、何の問題もなく独自のlinterを使うことができました。

reviewdogの使い方

Go製のツールなので、

go get -u github.com/haya14busa/reviewdog/cmd/reviewdog

もしくはGitHubのRleasesページからダウンロードしたバイナリをPATHの通った場所に配置することでインストールできます。
(CIで利用する場合、バージョンを固定できるこちらが推奨)

インストール後はREADME.mdやコマンドのhelpに書いてある通り、

$ <linter> | reviewdog [<flags>] (-reporter=github-pr-review | -diff=<diff command>)

の形式で実行できます。

例えばCircleCI上でgolintを実行する場合は以下のようになります。

export GITHUB_API=<GitHub EnterpriseのAPIエンドポイント>
export REVIEWDOG_GITHUB_API_TOKEN=<APIアクセストークン>
golint $(go list ./...) | reviewdog -f=golint -reporter='github-pr-review'

また、Pull Requestをpushする前などにローカルでgolintを実行する場合は以下のようになります。

golint $(go list ./...) | reviewdog -f=golint -diff='git diff master'

ただ、現在は以下にある複数のツールを使用しており、

それぞれに対して実行時にオプションを指定していたりと、個別に実行するのが面倒なのでまとめて実行するスクリプトを用意しています。

  • go-reviewdog.sh
#!/bin/sh

PKGROOT=$1
if [ "$1" = "" ]; then
    PKGROOT="."
fi

REVIEWDOG_ARG="-reporter='github-pr-review'"
if [ "$CI_PULL_REQUEST" = "" ]; then
    REVIEWDOG_ARG="-diff='git diff master'"
fi

golint $(go list $PKGROOT/...) | eval reviewdog -f=golint $REVIEWDOG_ARG

gsc -tests=false \
    -exit-non-zero=false \
    $(go list $PKGROOT/...) \
    | eval reviewdog -f=golint -name="gsc" $REVIEWDOG_ARG

megacheck -tests=false \
    -staticcheck.exit-non-zero=false \
    -simple.exit-non-zero=false \
    -unused.exit-non-zero=false \
    -unused.fields=false \
    $(go list $PKGROOT/...) \
    | eval reviewdog -f=golint -name="megacheck" $REVIEWDOG_ARG

golangci-lint run \
    --issues-exit-code 0 \
    --out-format checkstyle \
    --disable-all \
    -E errcheck \
    -E ineffassign \
    -E interfacer \
    -E unconvert \
    -E misspell \
    -E unparam \
    -E nakedret \
    -E prealloc \
    $GOPATH/src/$PKGROOT/... \
    | eval reviewdog -name=golangci-lint -f=checkstyle $REVIEWDOG_ARG

golangci-lint run --tests=false \
    --issues-exit-code 0 \
    --out-format checkstyle \
    --disable-all \
    -E dupl \
    -E goconst \
    -E gocyclo --gocyclo.min-complexity 15 \
    $GOPATH/src/$PKGROOT/... \
    | eval reviewdog -name=golangci-lint -f=checkstyle $REVIEWDOG_ARG

こちらのスクリプトはローカルで実行する際はmasterとの差分をstdoutに出力します。
他にもBranchのpushなど、Pull Request以外の場合はそのような動作するようになっており、CircleCIでは次のように設定して使っています。

  • .circleci/config.yml
version: 2
jobs:
  build:
    docker:
      - image: <reviewdogや関連ツール・スクリプトがインストール済みのイメージを指定>

    environment:
      GITHUB_API: <GitHub EnterpriseのAPIエンドポイント>
      # REVIEWDOG_GITHUB_API_TOKEN: CircleCI上のEnvironment Variablesに設定

    steps:
      - checkout

      # 省略

      - run:
          name: Execute reviewdog
          command: go-reviewdog.sh <対象のパッケージ名>

      # 省略

CIで利用するイメージは共通化されており、どのリポジトリでも同じlinterが同じルールで実行されます。
そのため、イメージの方でlinterやルールを変更することで、各リポジトリでは特に何もせずに新しい設定が適用されるようになっています。

linterについて

reviewdogを導入してから半年ほど経ちましたが、実はまだlinterやそのルールがしっかりと固まっていません。
基本的には、

  • Goの標準的なスタイルに合わせる
    • golint
  • シンプルで安定したコードを書く
    • megacheck
  • よくある問題を防ぐ
    • gsc

としていますが、golangci-lintに関しては試行錯誤しながら使っています。
また、一部のlinterは実行時間の短縮や誤検出を減らすためにオプションを変えたりテストを除外しています。
定番のgo vetを入れていませんが、それは修正を必須としているのでreviewdogを通さずに実行しているためです。

試行錯誤した結果、現時点では下表のlinter設定にしています。

Linter Include tests Description
golint - 公式のlinter
gsc ⬜️ スコープ外のContextを使用していないか、などのチェックをする
megacheck staticcheck ⬜️ 誤った動作をするコードがないかチェックする
gosimple ⬜️ より簡潔に書けるコードがないかチェックする
unused ⬜️ 未使用の変数、型、フィールドがないかチェックする
※フィールドのチェックはgoon_kindが引っかかるので無効にしている
golangci-lint errcheck 未チェックのエラーがないかチェックする
ineffassign 値が未使用なまま上書きされている変数がないかチェックする
interfacer より小さいinterfaceに置き換えられる引数がないかチェックする
unconvert 不必要なキャストがないかチェックする
misspell 英単語のスペルに誤りがないかチェックする
unparam 未使用の引数がないかチェックする
nakedret Named Result Parametersによるreturnをしていないかチェックする
prealloc 事前に容量を確保できるスライスがないかチェックする
dupl ⬜️ 重複しているコードがないかチェックする
goconst ⬜️ 定数に置き換えられるコードがないかチェックする
gocyclo ⬜️ コードの循環的複雑度をチェックする
min-complexityを15に設定(デフォルトは30)

この中でよく警告されるのはコメントが無いコードに対してgolintが出力する

exported XXX should have comment or be unexported

ですが、コメントの英語縛りはしていないため、警告されたら日本語でコメントを足せばいいのであまり困っていません。
それにコメントを書くタイミングで書きづらいことに気づいた場合、処理を詰め込みすぎている可能性があるので実装を考え直すきっかけにもなっています。

まとめ

reviewdog導入の成果として「コードの品質を改善しよう」という意識がチーム内で高まりました。

おかげで最低限のチェックが済んだ状態でレビューを始めることができるようになりました。
ただし、一部のlinterは厳しめのチェックをすることもあるため、実装者にとってはやや負担が増えてしまっているようにも感じます。
それでも後々になって致命的な問題が見つかるよりはよっぽど良いと思っています。

また、reviewdogの特徴として改修のあった部分のみが警告されるため、自分の触ったコードやその周辺を綺麗にしようという「ボーイスカウト・ルール」が働きやすくなっています。
これが1度に全ての警告が出てきてしまうと気軽に直すのが難しく、つい後回しにされがちなので狙い通りの効果だと言えます。

今の段階ではまだ誤検出をしてしまったり、警告の意味がわからず戸惑ってしまうようなことがあるような状況です。
しかし、今後もlinterやルールは継続的に見直していくつもりですし、慣れてくると意識しないでも警告されないコードが書けるようになるはずです。
このような積み重ねをしてくことでレビューの効率化、ひいては全体的なGo力の底上げに繋げていきたい考えています。

Google Cloud Buildとは一体何者なのか

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

こんにちは。SWETの加瀬(@Kesin11)です。
Google Cloud Next ’18でGoogleのCI/CDサービスとしてGoogle Cloud Build(以後GCBと略します)というものが発表されました。
https://cloud.google.com/cloud-build/
https://www.youtube.com/watch?v=iyGHW4UQ_Ts

CI/CDサービスを追っているものとして、これは要チェック!
ということで、GCBを軽く使ってみて分かった特徴をCircleCIと比較してまとめてみました。

最初にまとめを書いてしまうと、GCBはCI/CDとして見るとCircleCIと比べてまだまだ扱いづらいところがあります。一方で、従量課金制のフルマネージドなビルドサービスというCircleCIとは違った使い方もできるところが特徴と言えます。

GCBの特徴

1ステップ1コンテナ

一般的なCI/CDサービスでは、以下のようなステップをGUIや専用のファイルに自分で記述していきます。

  • git checkout
  • 依存ライブラリのインストール
  • ビルド
  • テスト実行
  • デプロイ

CircleCIを例にすると、それぞれのステップは1つの仮想マシン、あるいは最近では1つのdockerコンテナ上で実行されるのが一般的です。

.circleci/config.yml

version: 2
jobs:
  build:
    docker:
      - image: circleci/node:9
    working_directory: ~/repo

    steps:
      - checkout
      - restore_cache:
          keys:
          - v1-dependencies-{{ checksum "package.json" }}
          - v1-dependencies-
      - run: npm install
      - save_cache:
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package.json" }}
      - run:
          name: lint
          command: npm run lint
      - run:
          name: test
          command: npm run test

上の.circleci/config.ymlの場合、circleci/node:9のコンテナ上で全てのステップが実行されることになります。Workflowsを活用した場合には複数のコンテナを使用してビルドフローを構築することも可能ですが、基本的には1コンテナ上で複数のステップを実行するという考え方です。

GCBではここから根本的に異なっており、1ステップ1コンテナで実行されます。

cloudbuild.yaml

steps:
# build node script
- name: 'gcr.io/cloud-builders/npm'
  args: ['install']
- name: 'gcr.io/cloud-builders/npm'
  args: ['run', 'lint']
- name: 'gcr.io/cloud-builders/npm'
  args: ['run', 'test']
- name: 'gcr.io/cloud-builders/docker'
- args: ['build', '-t', 'gcr.io/$PROJECT_ID/sampleproject:latest', '.']

各ステップに必ずdockerイメージ名が記載されており、実際にこのコンテナ上で各ステップが実行されます。 そのため、例えばnpmを使いたいときはnpmが使えるコンテナ、docker buildしたいときはdockerが使えるコンテナを指定します。

Cloud Buildではよく使われるコマンドを実行できるdoockerイメージをGitHub上で公式コミュニティがメンテしています。 例えばgcloudkubectlfirebaseなどが使えるイメージが存在します。

もちろん、Cloud Buildによってメンテされているdockerイメージ以外も使用可能です。例えば先ほどのcloud-buildersのnpmのディレクトリにあるREADMEを見ると、以下のようにentrypointを指定することで公式のnodeイメージを使用することも可能であると書かれています。

steps:
- name: node:10.8.0
  entrypoint: npm
  args: ['install']

より詳しく知りたい場合、GCBのCreating Custom Build Stepsのドキュメントを参照するとよいでしょう。
https://cloud.google.com/cloud-build/docs/create-custom-build-steps?hl=en

GitHubのChecks APIが使える

2018/05にGitHubからChecks APIというものが公開されました。 これはPull Requestの画面からCI結果の詳細が見られるようになるという新機能なのですが、まだ対応されているサービスは多くありません。 この記事が公開された2018/08の時点で対応しているサービスはTravis CI、Visual Studio App Center、そしてGCBの3つしかないようです。 https://developer.github.com/v3/checks/

CircleCIは5月の発表時点では名を連ねていましたが、まだ使えるようになっていません。

docker imageのpushが簡単

GCBの特筆すべき特徴の1つとして、Google Cloud Platform(GCP)に含まれるGoogle Container Registry(GCR)との連携が挙げられます。 GCRはプライベートなコンテナレジストリを提供してくれるサービスで、特にGCPのコンテナを扱うサービス(GKEなど)を利用する上ではとても便利です。

GCBでは以下のようにdocker buildしたイメージをimagesで指定するだけで、自動的にGCRにpushしてくれます。 認証のための鍵などを考える必要はなく、非常にお手軽です。

cloudbuild.yaml

steps:
# docker build
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/$PROJECT_ID/sampleproject:latest', '.']

# push built images to Container Registry
images: ['gcr.io/$PROJECT_ID/sampleproject:latest']

ローカルからコマンド実行するだけで手軽にビルドできる

CircleCIなどのCIサービスは基本的にGitHubにpushされたトリガーによってジョブが走るため、最初にビルドフローをトライ&エラーで構築するときに設定ファイルを少し変えてはgit pushをひたすら繰り返すことになります。

GCBの場合はgcloud builds submit --config=cloudbuild.yaml .このコマンド一発だけでローカルのソースコードを全てtarで固めて、cloudbuild.yamlに従ってクラウド上ジョブが実行されるので非常に簡単です。
https://cloud.google.com/cloud-build/docs/running-builds/start-build-manually?hl=en

設定ファイルを修正するたびにgit pushして動作確認するのもそれほど手間ではありませんが、トライ&エラーの時期にはコマンド一発で動作確認ができるのは意外と便利です。また、CI/CDという文脈を外せばリモートでdocker buildなどを実行できる便利なサービスとして使うこともできるでしょう。

ちなみにGCBでも手動で実行するだけではなく主要なCIサービスと同様に、GitHubにpushしたタイミングで自動的にジョブが動くように設定することは可能です。
https://cloud.google.com/cloud-build/docs/run-builds-on-github?hl=en

8コア、32コアマシン

GCBではビルドを実行するマシンのスペックを簡単に選択できます。どれだけ簡単かというと、先程のコマンドに--machine-typeオプションを追加するだけです。

gcloud builds submit --config=cloudbuild.yaml --machine-type=n1-highcpu-8 .

これだけでビルドを実行するマシンは8コアのスペックになります。オプション1つでマシンスペックを上げることが可能なので、非常に時間がかかるビルドフローを実行する場合だけハイスペックマシンにするという使い方が可能です。
もちろんcloudbuild.yamlに直接マシンスペックを記載することで、常に8コアマシンを使用してビルドするように設定することも可能です。
https://cloud.google.com/cloud-build/docs/api/reference/rest/v1/projects.builds#machinetype

従量課金制

CircleCIは月額課金制で、並列数やコンテナ数に応じて料金が変動する料金体系になっています。
https://circleci.com/pricing/

GCBでは料金体系が一般的なCIサービスとは異なっており、月額課金ではなくて従量課金制です。1コアマシンなら毎日120分は無料で、それを超えた先は分単位で課金されます。
ちなみに無料枠は1コアマシンだけのようで、先程紹介した8コア、32コアマシンの場合は無料枠がありませんので注意してください。
https://cloud.google.com/cloud-build/pricing?hl=en

CircleCIとは料金体系が異なるのでどちらが良いとは一概に言えませんが、少なくともGCBの場合はハイスペックマシンが必要な瞬間や、ビルドフローによってマシンスペックを変更することが可能という柔軟性があります。

GCBのイマイチな点

ここまでGCBの特徴として基本的に良い点を取り上げてきましたが、使ってみてイマイチだと感じた点もあるのでこちらについても触れておきます。

Slack連携がない。Cloud Functionでやるしかない

これが痛すぎるマイナスポイント。なんとビルドの成功/失敗を通知するという基本的な機能ですらデフォルトでSlackやメールに対応していません。

ビルドの結果はGoogle Cloud Pub/Subに流されるので、それをトリガーにしたCloud Functionを自前で用意してSlackなりMailgunのようなメール送信サービスのAPIを叩けということのようです。

https://cloud.google.com/cloud-build/docs/send-build-notifications https://cloud.google.com/cloud-build/docs/configure-third-party-notifications

CircleCIのような主要なCI/CDサービスではSlackなどに簡単に接続できるので、この点はだいぶ方針が異なると思いました。

キャッシュの記法が無い

CircleCIでは、ビルド時間を短くするために有効な方法として依存ライブラリのキャッシュがあります。CircleCIではキャッシュの読み取り/保存のためにrestore_cachesave_cacheという特別なステップが用意されています。

GCBの場合には、そのようなキャッシュのためのステップは用意されていないようです。自分がドキュメントを探した限りでは代替手段の解説も見当たりませんでした。
どうしてもキャッシュを使用したい場合は、Google Cloud Storage(GCS)をキャッシュの代わりに使用することで実現できるかも…?

並列ビルドフローの書き方が分かりにくい、フローのGUIが無い

CircleCIでは2.0からWorkflowを使うことで比較的簡単に並列のビルドフローを組み立てることができ、さらにビルドフローの図をGUIで表示してくれます。
https://circleci.com/docs/2.0/workflows/

GCBでも並列のビルドフローを組み立てることは可能ですが、設定ファイルの記述方法がCircleCIと比較してとても把握しやすいとは言えません。

例として、1つのリポジトリの中にツール用のTypeScriptと、Firebase Hostingにデプロイする用のディレクトリが存在する場合に並列で処理させる場合の書き方を比較します。

ディレクトリの構成はこのような感じです。

.
├── firebase.json
├── node_modules
├── package-lock.json
├── package.json
├── ts # ツール用のTypeScript
├── js # build後に生成されるjs
├── tsconfig.json
├── tslint.json
└── web # Firebase HostingにデプロイするNuxt.jsによるウェブサイト
    ├── assets
    ├── components
    ├── dist
    ├── layouts
    ├── middleware
    ├── node_modules
    ├── nuxt.config.js
    ├── package-lock.json
    ├── package.json
    ├── pages
    ├── plugins
    ├── static
    └── store

まずはCircleCI。一連のステップをbuild, build-web, deployのジョブに分割し、最後のworkflowsで順序や依存関係を記述するスタイルです。

以下の設定ではこのような流れになります(キャッシュ周りなど、今回の説明に不要な一部のステップは省略しています)。

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

.circleci/config.yml

version: 2
jobs:
  build:
    docker:
      - image: circleci/node:9
    working_directory: ~/repo

    steps:
      - checkout
      - run: npm install
      - run: npm run lint
      - run: npm run build

  build-web:
    docker:
      - image: circleci/node:9
    working_directory: ~/web

    steps:
      - checkout
      - run:
          name: npm install
          command: npm install
          working_directory: web
      - run:
          name: lint
          command: npm run lint
          working_directory: web

  deploy:
    docker:
      - image: circleci/node:9
    working_directory: ~/repo

    steps:
      - checkout
      - run:
          name: firebase deploy
          command: npm run deploy -- --token "$FIREBASE_TOKEN"

workflows:
  version: 2
  build_and_deploy:
    jobs:
      - build
      - build-web
      - deploy:
          requires:
            - build
            - build-web

次がGCBです。ステップごとにidを設定しておき、waitForで依存するステップを記述するスタイルです。
waitForが無いステップでは、自動的に1つの上のステップに依存するという挙動になります。 ただしwaitForで'-'を指定した場合は特別で、どのステップにも依存しないという意味になるので並列化する部分の起点になります。

以下の設定ではbuild webの最初のステップでwaitFor: ['-']を指定することで、build TypeScriptbuild webの一連のステップが並列化され、両方が完了してからfirebase deployが実行されます。

cloudbuild.yaml

secrets:
- kmsKeyName: ****
  secretEnv:
    FIREBASE_TOKEN: ****

steps:
# build TypeScript
- name: 'gcr.io/cloud-builders/npm'
  args: ['install']
- name: 'gcr.io/cloud-builders/npm'
  args: ['run', 'lint']
- name: 'gcr.io/cloud-builders/npm'
  args: ['run', 'build']
  id: 'script:build'

# build web
- name: 'gcr.io/cloud-builders/npm'
  args: ['install']
  dir: 'web'
  waitFor: ['-']
- name: 'gcr.io/cloud-builders/npm'
  args: ['run', 'lint']
  id: 'web:lint'

# firebase deploy
- name: 'gcr.io/cloud-builders/npm'
  args: ['run', 'deploy']
  id: 'firebase:deploy'
  waitFor: ['script:build', 'web:lint']
  secretEnv: ['FIREBASE_TOKEN']

個人的には、どの部分が並列に実行されるかがwaitForの挙動を把握していたとしても分かりづらいと感じました。さらに、CircleCIのworkflowと比べてyaml上で全体的なフローが把握しにくいだけではなく、GUIでフロー図を出してくれる機能もないのがマイナスポイントです。

とてもお手軽にマシンスペックを変更可能な点がGCBの長所なのですが、この並列ビルドフローの書きにくさがその長所を活かしにくくしてしまっています。

https://cloud.google.com/cloud-build/docs/configuring-builds/configure-build-step-order?hl=en

設定ファイル中に分岐処理を記述できない

CircleCIのconfig.ymlにはif-elseや、ブランチの指定などによって例えばmasterブランチの場合にだけデプロイのステップを実行する、といった制御を行うことができます。
先ほどのconfig.ymlも最後のworkflowsの部分にfiltersを追加することで、最後のdeployのジョブはmasterブランチの場合のみ実行されるといった制御が可能です。

workflows:
  version: 2
  build_and_deploy:
    jobs:
      - build
      - build-web
      - deploy:
          requires:
            - build
            - build-web
          filters:
            branches:
              only:
                - master

一方で、GCBには1つの設定ファイルの中で条件分岐を行うための記法が存在しません。分岐させたい処理だけシェルスクリプトに記述して実行させるという方法でおそらく実現は可能だと思いますが、全体の見通しは悪くなってしまうでしょう。

代わりにGCBはビルドトリガーを設定する際に、ブランチ名を正規表現で指定してビルドに使用する設定ファイルをcloudbuild.yaml以外にも指定できます。例えば以下のようにブランチ毎に使用する設定ファイルを分けることでブランチ毎のフロー制御が可能です。

  • developブランチ
    • cloudbuild.yaml(lintやテストを行う)
  • masterブランチ
    • cloudbuild_deploy.yaml(デプロイを行う)

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

ただし、CircleCIと異なり設定ファイルを分割する必要があるので、保守性の観点から個人的にはCircleCIの方法の方が好みです。

シークレットキーの扱いが面倒

デプロイを実行するフローを構築する場合に、秘密にしておく必要があるトークンをどうやってCIサービス中に読み取るかという問題があります。トークンが記されたファイルをリポジトリに含めてしまうのが最も簡単ですが、セキュリティ的な観点からは望ましくありません。
CircleCIではconfig.yamlとは別にCircleCIのGUIから環境変数の登録が可能なため、秘密にしておきたいトークンなどは環境変数にセットしてしまうのが一般的な方法です。

GCBの場合でも環境変数を使うというアプローチは可能なのですが、GCB単体にはその機能は存在せず、Cloud Key Management Service(Cloud KMS)というまた別のサービスと連携させる必要があります。
先程のcloudbuild.yamlでは、secrets:の箇所で暗号化されたトークンを環境変数としてセットしています。
https://cloud.google.com/cloud-build/docs/securing-builds/use-encrypted-secrets-credentials?hl=en#encrypting_an_environment_variable_using_the_cryptokey

詳しい使い方は上記のドキュメントを参照してください。正直、環境変数を登録したいだけなのにCircleCIと比較すると手順が多いという印象です。

まとめ

他のCI/CDサービス(今回は代表としてCircleCI)と比較したときのGoogle Cloud Buildの良い点、イマイチな点を紹介しました。最後にまとめとして、自分の主観ですがざっくりとした比較表を用意してみました。

CircleCI Google Cloud Build
ビルドフローの書きやすさ
GitHub連携
dockerコンテナのデプロイ(GCPとの連携)
チャットツール連携
マシンパワー
料金 月額課金 従量課金

GCBをCircleCIと比較してみて、個人的にはCI/CDとしてはまだ発展途上かなという印象でした。GCPとの連携は強みですが、ビルドフローが書きにくかったり、Slack通知がデフォルトでは無いあたりが現時点では少々扱いづらい点です。

一方で、コマンド一発でソースコードをアップロードしてクラウドでビルドができたり、マシンスペックを簡単に変更できるところが特徴的で、Cloud Buildというその名の通りフルマネージドな従量課金ビルドサービスとして非常に便利だと思います。

ブランチ戦略によってビルドやテスト、デプロイを複雑に制御するCI/CD用途よりもdocker buildを並列に行ってコンテナレジストリに登録したり、ソースコードのコンパイルといった、シンプルにコア数の多いハイスペックマシンを用意できると時間が短縮できるタスクを行う方が向いているという印象です。

近い将来、もはやビルド用のハイスペックマシン実機を手元に置いておく必要はなくなるかもしれません。
コーディング環境はコード補完が不自由ない程度のスペックのPCを使い、ビルドしたいときだけGCBにソースコードを送りつけてビルドしてもらう。そんな未来が来るかもしれないですね。

iOSデバイスの情報をアプリ内から取得する

こんにちは。SWETの加瀬(@Kesin11)です。
今回は、iOSデバイスの色々な情報をSwiftから取得するのに便利なLuminousというライブラリを紹介します。

デバイス情報の必要性

SWETではテスト自動化以外にもQAチームによるマニュアルテスト作業の効率化に取り組んでおり、その中でもバグチケットに記載されるデバイスの情報に着目しました。 開発者としては、バグが発生したときの検証デバイスのモデル名や、OSのバージョンといった情報は再現確認やデバッグのために貴重な情報です。

一方、QAチームは検証に使用したデバイスの情報を人力で記入しているという現状があるため、表記が微妙に統一されていなかったり、記載された情報が足りないというケースがありました。そのような場合には、開発者がQAチームに詳細を問い合わせるといったコミュニケーションコストが発生していました。

開発チームとQAチームにヒアリングをしたところ、以下の項目についてバグチケットに記載されていると助かるという回答が得られたため、これらの情報をアプリ内から取得する方法について調査してみました。

  • モデル名(iPhone 8、iPhone Xなどの名前)
  • OSバージョン
  • 画面解像度
  • メモリ
  • ストレージ空き容量

それぞれの項目についてSwiftから情報を取得することは可能なのですが、各情報を取得するためのクラスが別々だったりして少し面倒です。 今回、その面倒を解消してくれるLuminousという各種デバイス情報を取得するのに便利なライブラリを利用してみたのでその紹介をしたいと思います。

Luminous

Luminousはデバイスに関する各種情報を簡単に取得できるAPIを提供してくれるライブラリです。

以下は、前述の5項目についてLuminousを使って情報を取得してみた例です。

print("モデル名: \(Luminous.System.Hardware.Device.current.model)")
print("iOSバージョン: \(Luminous.System.Hardware.systemVersion)")

let nativeScreenBounds = Luminous.System.Hardware.Screen.nativeBounds
print("画面解像度: \(Int(nativeScreenBounds.width)) x \(Int(nativeScreenBounds.height))")

let totalMemoryMb = Int(Luminous.System.Hardware.physicalMemory(withSizeScale: .bytes) / 1024 / 1024)
print("メモリ: \(totalMemoryMb) MB")

let totalMemoryMbRounded = totalMemoryMb + 256 - (totalMemoryMb % 256)
print("メモリ(丸め): \(Int(totalMemoryMbRounded)) MB")

print("ストレージ空き容量: \(Luminous.System.Disk.freeSpace)")

// 実行結果
//
// モデル名: iPhone 6
// iOSバージョン: 10.1
// 画面解像度: 750 x 1334
// メモリ: 989 MB
// メモリ(丸め): 1024 MB
// ストレージ空き容量: 7.03 GB

メモリのところだけ補足をすると、実際に取得できる値はLuminous.System.Hardware.physicalMemoryによる989MBとなっており、残念ながら何らかの理由によってカタログスペックよりも低い値となってしまっています(iPhone 6のカタログスペックは1GB)。
そのため、256刻みで一番近いところに丸めた値も用意してみました。用途によると思いますが、カタログスペックと一致した値を表示させたい場合には上記のコードのように値を丸めてもいいかもしれません。

サンプルプロジェクト

Luminousでは他にも様々な情報を取得できます。他にどういった情報を取得できるのかはREADMEに記載されていますが、リポジトリにサンプルプロジェクトも同梱されているので、これをビルドして実際に確認することもできます。

サンプルプロジェクトをビルドして実機で動かすと以下のようにコンソールに表示されます(一部の情報については伏せています)。

以下の環境で実行した結果となります。

  • Xcode 9.3.1
  • Swift 3.3(現時点で古いですが、サンプルプロジェクトのBuild Settingsで設定されているため)
  • Luminous 1.0.2
  • iPhone 6(実機)
------------
Network
------------
isConnectedViaCellular: false
isConnectedViaWiFi: true
SSID: ****
------------
Locale
------------
currentCountry: en_JP
currentCurrency: JPY
currentCurrencySymbol: JP¥
currentLanguage: en-JP
currentTimeZone: Asia/Tokyo (current)
currentTimeZoneName: Asia/Tokyo
decimalSeparator: .
usesMetricSystem: true
------------
Carrier
------------
allowsVOIP: true
ISOCountryCode: jp
mobileCountryCode: 440
name: ****
networkCountryCode: 20
------------
Hardware
------------
bootTime: 47519.0146807917
physicalMemory: 1.08742e+15
processorsNumber: 2
systemName: iOS
systemVersion: 10.1
isLowPowerModeEnabled: false
------------
Screen
------------
bounds: (0.0, 0.0, 375.0, 667.0)
brightness: 0.255796
isScreenMirrored: false
nativeBounds: (0.0, 0.0, 750.0, 1334.0)
nativeScale: 2.0
bounds: 2.0
------------
Device
------------
current: Deviice
Identifier: iPhone7,2
Type: iPhone6
Model name: iPhone 6
Connectivity: wiFi4G
Screen size: screen4Dot7Inches
identifierForVendor: 1E75D506-AF8D-4743-A0DE-23574EBF75F8
orientation: UIDeviceOrientation
------------
Accessory
------------
2018-05-22 19:10:47.888318 Luminous_Example[630:247318] Couldn't find the "com.apple.private.externalaccessory.showallaccessories" entitlement
connectedAccessories: []
connectedAccessoriesNames: []
count: 0
isHeadsetPluggedIn: false
------------
Sensors
------------
isAccelerometerAvailable : true
isGyroAvailable : true
isMagnetometerAvailable : true
isDeviceMotionAvailable : true
------------
Disk
------------
freeSpace: 7.03 GB
freeSpaceInBytes: 7548157952
totalSpace: 11.21 GB
totalSpaceInBytes: 12039397376
usedSpace: 4.18 GB
usedSpaceInBytes: 4491239424
freeSpaceInPercentage: 62.6955%
usedSpaceInPercentage: 37.3045%
------------
Battery
------------
level: 99.0
state: charging
------------
Application
------------
clipboardString: test
version: 1.0

Luminousを使うときには、このサンプルプロジェクトの表示を見ながら必要なコードを見つけるのが早いでしょう。

サンプルプロジェクトの注意点

残念ながら、バージョン1.0.2現在ではサンプルプロジェクトをビルドするとエラーになってしまいます。

対処法として、Build Phases > Link Binary With Librariesの設定にExternalAccessory.frameworkを追加するか、このフレームワークが必要な該当コードをコメントアウトすることで正常にビルドできるようになります。
この記事を書いている途中にpull requestを送っておいたので、もしかしたら記事が公開される頃には修正されているかもしれません。

その他の注意点としては、プロジェクトの署名に作者のプロビジョニングプロファイルが設定されているので、自分の実デバイスで実行したい場合には実機デバッグができるように署名の設定を変える必要があります。

まとめ

Luminousというライブラリを使ってデバイス情報を取得する方法の紹介をしました。

今回はiOSデバイスについて紹介しましたが、Androidでも同様にモデル名やOSバージョンに限らず、様々な情報が取得可能です。
そちらについても近いうちにまたご紹介していきたいと思いますのでお楽しみに!

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の場合と同様のワークアラウンドが必要になります。