End-Users2018-05-30iOSデバイスの情報をアプリ内から取得するiOSこんにちは。SWETの加瀬(@Kesin11)です。今回は、iOSデバイスの色々な情報をSwiftから取得するのに便利なLuminousというライブラリを紹介します。デバイス情報の必要性SWETではテスト自動化以外にもQAチームによるマニュアルテスト作業の効率化に取り組んでおり、その中でもバグチケットに記載されるデバイスの情報に着目しました。開発者としては、バグが発生したときの検証デバイスのモデル名や、OSのバージョンといった情報は再現確認やデバッグのために貴重な情報です。QAチームは検証に使用したデバイスの情報を人力で記入しているという現状があるため、表記が微妙に統一されていなかったり、記載された情報が足りないというケースがありました。そのような場合には、開発者がQAチームに詳細を問い合わせるといったコミュニケーションコストが発生していました。開発チームとQAチームにヒアリングをしたところ、以下の項目についてバグチケットに記載されていると助かるという回答が得られたため、これらの情報をアプリ内から取得する方法について調査してみました。Xなどの名前)OSバージョン画面解像度メモリストレージ空き容量それぞれの項目についてSwiftから情報を取得することは可能なのですが、各情報を取得するためのクラスが別々だったりして少し面倒です。今回、その面倒を解消してくれるLuminousという各種デバイス情報を取得するのに便利なライブラリを利用してみたのでその紹介をしたいと思います。LuminousLuminousはデバイスに関する各種情報を簡単に取得できるAPIを提供してくれるライブラリです。以下は、前述の5項目についてLuminousを使って情報を取得してみた例です。6のカタログスペックは1GB)。そのため、256刻みで一番近いところに丸めた値も用意してみました。用途によると思いますが、カタログスペックと一致した値を表示させたい場合には上記のコードのように値を丸めてもいいかもしれません。サンプルプロジェクトLuminousでは他にも様々な情報を取得できます。他にどういった情報を取得できるのかはREADMEに記載されていますが、リポジトリにサンプルプロジェクトも同梱されているので、これをビルドして実際に確認することもできます。サンプルプロジェクトをビルドして実機で動かすと以下のようにコンソールに表示されます(一部の情報については伏せています)。以下の環境で実行した結果となります。1.0Luminousを使うときには、このサンプルプロジェクトの表示を見ながら必要なコードを見つけるのが早いでしょう。残念ながら、バージョン1.0.2現在ではサンプルプロジェクトをビルドするとエラーになってしまいます。Librariesの設定にExternalAccessory.frameworkを追加するか、このフレームワークが必要な該当コードをコメントアウトすることで正常にビルドできるようになります。requestを送っておいたので、もしかしたら記事が公開される頃には修正されているかもしれません。その他の注意点としては、プロジェクトの署名に作者のプロビジョニングプロファイルが設定されているので、自分の実デバイスで実行したい場合には実機デバッグができるように署名の設定を変える必要があります。まとめLuminousというライブラリを使ってデバイス情報を取得する方法の紹介をしました。今回はiOSデバイスについて紹介しましたが、Androidでも同様にモデル名やOSバージョンに限らず、様々な情報が取得可能です。Articleはじめまして!4/1よりSWETに加わった@Kuniwakです。今回は、私がSWETに入って驚いたことと、そしてSWETだからこそ生まれたものについてお話しします。Kuniwakはどんな人?開発を高速化させるテストや静的検査を生業としています。以下のような記事やスライドを書いています。script静的解析の光と闇では、こんな私がSWETという自動テストのエキスパートのチームで働くことになって驚いたことを紹介します。SWETに入って驚いたことSWETに入って驚いたのは、テストに関連するトピックについてどなたも一家言をもっていたことです。以下のようなやりとりが実際にありました。Kuniwak:Mockライブラリ1やDIライブラリ2は必要だと思いますか?いずれもライブラリに頼らずにシンプルに書ける気がします。皆さんはどういうご意見をお持ちでしょうか。さん:Mockはライブラリに頼りたいですね。自前でMockのコード書くとMock自体のテストとかが必要になって面倒なことになると思います。さん:複数のプログラミング言語にまたがるような組織では、それぞれの言語に対するメンバーの習熟度にもばらつきがありますから、既存の文献やコード資産を参考にできるデファクトなライブラリを使った方がいいという視点もありますね。さん:Mockライブラリに限らず、他のライブラリと同じようにメンバーの学習コストやメンテナンスの継続性、利用者数などから考慮するといいのではないでしょうか。さん:この記事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さんの意見からうかがえる事実です。このやりとりをするまで、文献の少なさを気にしたことがありませんでした。このやりとりのあと、私はすぐにここで得た知識を活かす機会を思いつきました。私が声をあげることで、本来ライブラリを使わなくてもよい状況でライブラリを無理に使ってしまう問題を減らせると思ったのです。Manifesto)」と「バニラMock宣言」を書くことにしました。メンバーとの議論から生まれた「バニラDI宣言」と「バニラMock宣言」バニラDI/Mock宣言とは、状況に応じてライブラリを使わないことを選ぼう、ということを表明した宣言です。このバニラという表現は、何も手が加えられていないという意味でよく使われるものです。ライブラリを使わずに言語本来の自然な書き方で実現していくという方針にぴったりだと思い、この名前をつけました。以降では既に公開済みのバニラDI宣言の方を中心に解説していきます(バニラMock宣言は鋭意準備中です)。そもそもライブラリを使わないでDIを実現できるのでしょうか?この疑問にお答えするために、バニラDI宣言には各言語のコードサンプルを付属させました。これらは依存先コンポーネントです。後述のコンポーネント内で使われます。これは依存元コンポーネントです。