「ソフトウェアテスト入門」という話をした

先週、PFIセミナー（社内セミナー）で「ソフトウェアテスト入門」という話をした。 入門というタイトルだけど実はテストそのものではなく、2014年のソフトウェアテストでブームになりそうなことを紹介するつもりだったが、尺が足らなかったのでその詳細をここで紹介したい。

全然関係ないが、桜も散ってGWに近づく今日、最近わたしはFPS(First Person Shooting)のBattlefield 4をPCで遊ぶのにハマっている。 ハンドガン・ナイフオンリーのサーバで練習し、ついにハンドガンのアンロックを完了させたところである。 面識のある方がいたら是非一緒にプレイしたい（OriginのIDはsuma90hである）。

まずはImmutable Infrastructureといった単語やDocker(LXC)といった基盤技術とソフトウェアテストの関連について記す。 そして、RRRSpecのような取り組みと分散テストの相性とその問題点。 最後に、分散システムにおけるテストについて軽く扱う。 アカデミックな内容・Microsoftのテストに対する取り組みも踏み込んで紹介してみたかったが、今回は調査不足のためこのブログでは書かないことにする。いずれ紹介してみたい。

発表はustreamの録画もある。

Immutable InfrastructureとDocker

Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（前編） － Publickey

まず抑えておきたいがのImmutable Infrastructureという概念である。 関数型のプログラミング言語を使う・使わないプログラマーも変数（オブジェクト・インスタンス）がMutable/Immutableであるかは基礎的な知識だろう。 Immutable「不変」という単語をサーバといったインフラへにまで適用することは、エンジニアのソフトウェアテスト環境にとってこれほど嬉しいことはない（そうでもない？）。

数年前からTravis CIという継続的インテグレーションを可能にするサービスが存在する。 Travis CIではgithubにホストしているリポジトリを、Travis CIが提供する独立した仮想マシン上でビルドやテストを実行することができた。

昨年から有名になってきているツールとしてDockerがある。 LinuxのコンテナであるLXCも存在する。 LXCも悪くはないが、これは人間が管理するにはかなり低レイヤだ。 ちなみにUbuntu 14.04もリリースされたし、LXC 1.0もリリースされてLXC単体での利用も何かと期待できる。 話を戻して、Dockerはただのコンテナより層が厚く、同一ホストOS間のような環境では一定のバイナリ互換・移植性を提供してくれる。

ここ最近出現したOSSのCI環境として Drone がある。 触ったことはなため、詳細は知らないので言及はこの程度でとどめておく。 Immutable Infrastructure、DockerそしてDroneなど、ソフトウェアテスト環境がもの凄い勢いで進化しているのを感じている。

RRRSpec

RRRSpecについては、分散実行できるテストランナーという点に興味が惹かれた。 分散して実行できる利点は、ブログに書かれているようにテスト時間の短縮にある。 これは開発サイクルを早めるのに効果的だ。 アジャイルテストの4象限でいえば、開発チームを助ける2象限目に相当する。

RRRSpecはブログで解説されている、Amazon EC2のスポットインスタンス上でテストを実行するというアプローチは、AWS/クラウドコンピューティングがテストを実行する環境として有用なツールとなることを示している。 もちろん、エントリ内で言及されているようにアカデミックな側面もあるし、スポットインスタンスを使うための秘伝のノウハウもあると想像できる。 それでも、ここまで詳細にアイディアを説明してくれたら真似をするのも難しくないことだと思えてしまう。

RRRSpecは名前からもRSpecを実行するランナーであるが、一般的に分散してテストを実行するためにはソースコード以外にもテストに必要な環境（DBMS、関連するサーバーなど）を整えておく必要がある。 純粋にRubyソースコードだけで完結するコードであれば大がかりな準備は必要ない。 Amazon EC2を使うような場合では、あらかじめ必要なライブラリをインストールしたAMI(Amazon Machine Image)を作成したり、いわゆるプロビジョニングツールを使ってテスト環境のデプロイ自動化を利用することが考えられる。 RubyやLLによるソフトウェアの場合は、環境さえ構築済みならおそらくスクリプトのコピーだけテストの準備が完了してしまうと予想できる。 私が参加するプロジェクトでは特にC++での開発が多いため、C++やJavaのようにビルドが必要なソフトウェアでこのように分散テスト実行の環境が構築できたら素敵である。 Dockerなどの要素技術は既に整いつつあるので、小規模なプロジェクト/チームにおいても分散テストを実行する気運が高まっていると感じる。

分散システムのテスト

セミナーで紹介したかったけどしきれなかった内容として、分散システムのテストがある。 内容としては過去に自分がブログに書いたPFIインターンへ行ってきた（前編）～結合テストの自動化環境を整えてきた～ , (スライド)が詳しいため、こちらへの参照にとどめておいた。

問題はいかに早くプロジェクトのビルドを完了させるか、いかに早くデプロイを完了させるかに尽きるというこの2点だと思っている。 もちろん、誰の目線でテストするかも重要な要素になるはずで、分散システムのテーマについてここで説明するには下準備が足りていない。 kuenishiさんのブログへリンクを貼っておこう。

それっぽい分散テストツールっぽいものをいくつか - kuenishi’s blog

最後に

Go言語のテストスタイルが個人的には勉強になった（Go の Test に対する考え方 - Qiita ）とか、Googleがいうテストの大きさとかそういう話もした。 詳しくはスライドとかustreamの方を参照してもらいたい。

Docker/Droneといったソフトウェアがピックアップされたり、Immutable Infrastructureという単語が出てきた時から私はこれは流行る・流行に乗っかって楽しいエンジニアライフを過ごしたい人がたくさん出るのだろうと思っていた。 ソフトウェアテストや継続的インテグレーションの形も変わりつつある時代を実感できる今日この頃である。

そういえば今年の夏も私の所属している会社ではインターンシップをする予定である。応募資格のある方、興味のある方は是非応募してもらいたい。

https://preferred.jp/news/2763/