2020/10/2 変更

参考記事・図書の記載に一部誤りがあったことをご指摘いただき、修正いたしました。
ご指摘いただきました y-okudera様、ありがとうございます!
ならびに、関係者の方々にはお詫び申し上げます。

はじめに

こんにちは、iOSエンジニアの dayossi です。

家族が幸せになれるサービスを提供したいと思って、
HaloHaloという家族日記アプリをリリースしています。

今回は、ユニットテストの結果を
どう解釈したらいいのか悩んだので整理しました。

テストの目的は、
記述した処理が、きちんと意図したとおりに動けているのか検証することです。

テスト結果の評価には、コードカバレッジが活用できます。
XCTestではコードカバレッジのうち、ラインカバレッジの結果が簡単に可視化でき
行単位でどの処理が活用されている/いないのかが抽出できるようになります。

Xcodeのラインカバレッジでは、コメント文を含め
その行を通り抜けたかどうかをチェックします。

また、ビルドする対象を管理するスキームを変更すると
テスト環境下でのカバレッジ計測の結果を % で見ることができます。
（個人的に、ここの設定が抜けていてカバレッジ計測どうやるんだ!?っとハマってました...）

今回は、HTTP通信に関する簡単なテストを組みました。
testAPI()からcallAPI()を呼び、結果をコールバックで受けるまでの流れを検証しました。

テストの結果、testAPI()自体は呼ばれ、callAPI()も実行されていますが
callAPI()のクロージャが呼ばれていない結果が得られました。

callAPI()の中で、きちんとcompletionが呼ばれていないことが原因でした。
（あり得ないエラーですが...）

callAPI()内でcompletionを呼んであげたら、無事に通過しました。

上記の様に、1文にメソッドの呼び出しとコールバック後の処理の2つが書かれていても
それぞれの処理について、通過したかどうかを検証することができます。

以下のように、カバレッジの結果を確認できます。

HTTP通信のリクエスト・レスポンスに関しては、テストの結果から
コード内部の記述について改善が見られたと考えられます。

ですが、実装しているクラスと比較するとカバレッジに大きな差があります。

実装クラスの中身を見てみると、エラー文の中を通過しており
guard文でのアンラップに失敗しています。

つまり、なんらかの理由でURLSessionが失敗したため
テストの結果と差異が生まれたことがまず考えられそうです。
（実際、ネットワーク通信を切断した状況下で行っていたので整合性がありました。）

この解釈から、処理内部のコード記述ミスなのか
外部要因によるエラーなのか
問題点を少しずつ切り分けて考えることもできるんだな〜と実感できました。

XCTestで把握できるのは「コード内部の処理通過状況」であり、
コンポーネントごとの処理動向を把握することができるんだなと実感しました。

ただし、基本的にネットワーク通信の環境から切り離されているので
ネットワーク通信を伴うコンポーネントのテストを行いたいときは、
HTTPスタブライブラリを活用するほうが便利だなと思いました。

副産物として、「テストを書きにくいな〜」と思ったコンポーネントには
複数の責務が混じっていて、簡素化できる余地を発見できる点も
テストを書くメリットだなと思いました。

テストありきで設計をすすめる考えも学んでみたいと思います！
（温かいツッコミを、お待ちしております）