CI/継続的デリバリにおけるソースコード管理は分散型バージョン管理システムである「Git」が主流になっています。分散型バージョン管理システムとは、リポジトリをリモートとローカルで持つ構成のバージョン管理システムです。
分散型バージョン管理システムは、ローカルでマージしてからリモートにプッシュする仕組みになっています。そのため、リモートリポジトリは基本的にマージ済みのソースコードがPushされるため、競合が発生しづらくなっています。
CI/継続的デリバリでは、キリの良いタイミングで統合されたソースコードをビルドすることが望ましいので、分散型バージョン管理システムと非常に相性が良いです。そのため、近年ではGitをはじめとした分散型バージョン管理システムが採用されるケースがかなり増えてきています。
Gitならびに分散型バージョン管理システムについての概要は次の記事で解説されています。
プロジェクトでGitを使うには、Gitサーバーが必要です。「GitHub」「BitBucket」などのホスティングサービスを使ったり、「Stash」「GitLab」などのツール・サービスで自分で構築したりして、使うことになります。
また近年では、Git用の拡張ツールである「git-flow」を併用するケースが増えてきています。git-flowはGitのブランチを「develop」や「release」などのような開発フローをベースにした単位で構成するためのツールです。
git-flowを併用することにより、開発フローやソースコードの履歴、リリースの管理などといったデリバリの手順を標準化できます。git-flowの基礎知識・導入方法・使い方は次の連載記事で解説されています。
iOSアプリのテストにおいて、機能の「振る舞い」のテストが近年注目を集めています。
iOSアプリは開発期間が短い場合が多いため、テストフェーズが実装フェーズに圧迫されてしまい、品質の維持が困難になるケースがよくあります。機能の振る舞いをベースにテストを記述することで、成果物が要求仕様通りに実装できているか確認すると同時に、機能の実装の進捗(しんちょく)も容易に確認できようになるため、短い期間の中で効率的に品質を管理できます。
機能の振る舞いのテストを目的としたテスティングフレームワークは幾つかありますが、その中でも「Kiwi」は特に注目を集めています。Kiwiは読みやすいテストコードが記述できるという特長があり、Rubyの「RSpec」に近い形式で記述できます。
Kiwiで書くテストコードは次のような感じです。
describe(@"チームが", ^{ context(@"新しく作成されたとき", ^{ it(@"名前を持っている必要がある", ^{ id team = [Team team]; [[team.name should] equal:@"楽天イーグルス"]; }); it(@"11人の選手が必要である", ^{ id team = [Team team]; [[[team should] have:11] players]; }); }); });
GitHubなどで公開されているオープンソースのライブラリでは、Kiwiを使ってテストを実施しているプロジェクトがここ最近で非常に増えてきています。近年最も注目されているテスティングフレームワークといえるでしょう。
Kiwi以外にも、iOSアプリ開発で使えるテスティングフレームワークは数多くあります。Kiwiと同様に機能の振る舞いをテストすることを目的としたフレームワークもあれば、単体テストを目的としたフレームワークなど、目的とするテストの形式もさまざまなので、プロジェクトに必要なテストに合わせてフレームワークを選ぶ(または組み合わせる)必要があります。
そこで、iOSアプリ開発でよく使われるテスティングフレームワーク5つを以下にまとめました。ぜひチェックしておきましょう。
機能の振る舞いのテストを目的としたテスティングフレームワークです。Kiwiはモックやマッチャーなどが全てそろったフルセットのフレームワークなのに対し、Spectaはモックやマッチャーなどは提供していないので、「Expecta」「OCMock」など他のフレームワークを併用する必要があります。モックやマッチャーの組み合わせを自由に選べる点が特長です。
機能の振る舞いのテストを目的としたテスティングフレームワークです。テストコードを「Cucumber」形式で記述するため、自然言語に近くて読みやすいという特長があります。シミュレーターと実機の両方をサポートしているので、さまざまな環境でテストを実施できます。
またAndroid用のCalabash-Androidもあるので、UIや機能が同じであればテストケースをAndroidとiOSで併用することもできます。
Square社が提供している、結合テストを目的としたテスティングフレームワークです。主にUIを対象としたテストを実施したいときに使います。テストコードを「Step」(UIの1つの動作)と「Senario」(Stepの組み合わせ)で記述していくのが特徴です。
Xcodeとの親和性が高く、2.0.0からXcodeに統合されたテストとして実行できるようになりました([Command]+[u]キーで実行可能)。
単体テストを目的とした多機能なテスティングフレームワークです。iOSアプリとしてインストールし、テストを実行するという形式を採ります。通信処理などのような非同期のテストが容易にできるという特長があります。
また、シミュレータと実機の両方をサポートしているので、実機でしか発生しないバグを検出できます。
Xcode 5で新しく追加された、単体テストを目的としたテスティングフレームワークです。「SenTestingKit.framework」の後継で、SenTestingKit.frameworkとほぼ同様のAPIが提供されています。
また、Xcode 5からXCTest.frameworkのテストケースを実行するための「Test Navigator」機能が追加されました。Xcode 4まではテスト結果の出力がコンソールのみだったため、成功したか失敗したか確認するのが非常に困難でした。
Xcode 5からはTest Navigatorで、どのテストが成功したか失敗したか表示されるため、かなり分かりやすいものとなりました。
iOSアプリ開発で継続的デリバリーを実現するためには、開発メンバーやプロジェクトリーダー、顧客などにiOSアプリを継続的に配布しなければいけません。しかし、Xcodeからアプリを.ipaファイルを作成してメールで届けたり、開発環境をインストールしてもらってソースコードからビルドしてもらったりするのは、とても非効率で無駄の多い作業です。
そこで登場するのが、アプリの配布をサポートするサービス「TestFlight」です。先日、アップルが買収を発表して話題になりましたね。このサービスを使うと、リリース前のアプリをテスターのみに配布できます。
TestFlightでは、.ipaファイルをアップロードするだけで、チームに登録しているテスターに一斉に通知されます。通知を受けたテスターは、TestFlightにアクセスするだけでアプリをインストールできるようになります。またTestFlight SDKをアプリに組み込むことによって、セッションやクラッシュレポート、ログの収集などが行えるようになります。
またJenkinsと連係させることも可能で、プラグインを使うことで「テストが通ったらアプリを配布する」といったようなフローを自動化できます。
初回はCI/継続的デリバリ環境に必要不可欠なイマドキのツール・サービスを紹介しましたが、いかがでしたでしょうか。
環境構築は作業量が多そうで、なかなか手が付けられないと思っている方も多いかと思います。しかし、一度構築してしまえば他のプロジェクトでも使い回すことができますし、何より導入しないことによるコストや作業量の方が結果的に多くなってしまうことは明白です。
本連載では、各種ツールやサービスの導入方法と使い方を、学習コストが少なく済むよう分かりやすく解説することを重視して進めていく予定です。本連載が読者の方々が携わるプロジェクトにCI/継続的デリバリを導入するきっかけ作りになれば幸いです。
次回以降は各種ツール・サービスの導入方法と使い方、そして連係方法について解説していきたいと思います。
Copyright © ITmedia, Inc. All Rights Reserved.