「iOS Test Night #9 - 2周年 -」での登壇資料になります。 イベントのページ: https://testnight.connpass.com/event/102778/ 当初のテストコードを書く意識が希薄だったX年前の自分から、現在の実務の中でUnitTestに触れていく中で、「まずはできるところから始める」をコンセプトに実務や自分のライブラリを題材としたテストコードの事例に関しての発表になります。またほんの少しではありますが、テストがしやすい形にするための実装のヒントについても触れています。 （参考） 個人開発及び実務でユニットテストに助けられたと個人的に感じた例の紹介 https://qiita.com/fumiyasac@github/items/19c525116f1b585bb43f

1. まずはできるところから始める
UnitTestとテストができる実装について
Fumiya Sakai (Just1factory)
2018/12/09 iOS Test Night #9 @ DeNA

2. 自己紹介
・酒井文也
・iOSアプリエンジニア
アカウント:
・Twitter: https://twitter.com/fumiyasac
・Facebook: https://www.facebook.com/fumiya.sakai.37
・Github: https://github.com/fumiyasac
・Qiita: https://qiita.com/fumiyasac@github
発表者:
・Eversense, inc.
これまでの歩み:
Web Designer
2008 ~ 2010
Web Engineer
2012 ~ 2016
App Engineer
2017 ~ Present

3. ほんの少しだけ告知と宣伝
「少しの工夫とアイデアでできる表現集」として、これまでサンプル開発や実務の
中で培ったノウハウ等から、UI実装いくつかのまとまったサンプル実装を例にUI構
築をする上で重要な実装ポイントやアイデアを紹介していく形式にしてみました。
収録サンプル:
https://github.com/fumiyasac/ios_ui_recipe_showcase
現在Boothにて販売中です（近日アップデート予定） ¥1,000
同人誌「iOSアプリ開発 UI実装であると嬉しいレシピブック」を書きました。
https://booth.pm/ja/items/1021745
概要:

4. 今回お話する内容に関する補足資料
1年前に書いたQiitaの中にも簡単な事例をまとめています。
https://qiita.com/fumiyasac@github/items/19c525116f1b585bb43f

5. UnitTestを書き始める前に感じていたこと
最初は恥ずかしながらそれほど関心が高いわけではなかった。
iOSアプリ開発初期:
1. ViewControllerにまるっと処理が書かれている状態
2. 画面と表示データとの不整合に悩まされる状態
3. そもそもアーキテクチャや読みやすさの考慮が甘い状態
手計算している祝祭日のライブラリをせっかく作るのだから、ここにはテストコードを入れよう！
転機となった出来事:
このままではよくない！何か簡単なものでも良いのでテストコードを書く経験をしなくては！

6. ライブラリ:CalculateCalendarLogic
2016年〜今日まで初心を忘れないように運用しています。
https://github.com/fumiyasac/handMadeCalendarAdvance
つぶやき:
来年・再来年が
まじで怖い…

7. CalculateCalendarLogicでUnitTestを追加した理由
計算による祝祭日の判定ロジックなので目視でのチェックはやってられない。
基本の方針としては、ある程度の祝祭日がパターン化ができそう
な2000年以降の日付に対しては動作の保証をするようにしている
（内閣府の発表を元にロジックを追加している）。
このライブラリでの動作保証について:

8. 中ではこんな感じのUnitTestが記載されています
シルバーウィークの判定における紛らわしい年の場合に関するテスト例。
テストの目的:
9月の第2週の土曜日〜第3週の木曜日までで紛らわしい年のケース検出と検証
(年, 月, 日, ライブラリのメソッドでの判定結果)のタプル

9. 実際の開発したアプリに関する一例
Eversenseで開発しているアプリ「手作り離乳食」での事例です。
1. データは内部のRealmで保持している
API通信をして情報を取得する形式ではなく、検索用
のデータ一覧を内部のRealmで保持する形式。
2. 絞り込み検索に相当する機能
ユーザーが選択したキーワードや含めないものを考
慮した選択条件等を元に該当のデータを取得するた
めのロジックを実装。
既存仕様の理解も含めてUnitTestを新機能実装時に追加する

10. 図解で説明するテストする箇所の要点
食材リスト画面における仕様の概略とテストが必要な部分まとめる。

11. 図解で説明するテストする箇所の要点
検索画面における仕様の概略とテストが必要な部分まとめる。
見つけた仕様1. 完全一致するレシピがある考慮
完全一致するようなデータある場合には、検索結果
にそのデータが先頭に来る。
見つけた仕様2. 優先的に検索に含めない考慮
除外する食材のチェックボックスを有効にした食材
を使用している検索ワードで検索する場合、そのデー
タは1件もヒットしないこと。
紛らわしい検索条件の組み合わせをテストコードで理解

12. 検索画面におけるテストコードの例
検索ワードや選択項目を紛らわしい形にしてUnitTestを実行する
テストコードを作るためのポイント:
該当のビジネスロジックを実行するためのメソッドをテストできる形式にしておく点が肝心（すでにされていた）。

13. 現在開発中のアプリでの取り組み
Eversenseで今年リリースしたアプリ「michiru」での取り組みです。
1. 生理データに関するロジックが複雑
ユーザーのデータを元にした計算ロジックが多岐に
渡り複雑なので予めそのような部分にはテストコー
ドを含めるようにして担保する。
2. 新機能追加や修正時にテストを含める心がけ
特にModel層やService層相当の部分を開発・修正す
る場合にはテストコードを追加するようにする。
メンバーのお陰で自分もテストを書く意欲や意識が高まった！

14. チームやプロジェクト内で少しずつテストを書いてみて
自分も含めて「二の足を踏んでいた状態」からの脱出
些細なテストコードが実装や理解の助けとなる
・Swiftバージョンアップ時の実装担保
最初はほんの些細なものであっても、チームで少しずつ追加していけば大きな財産になる（と思います）
はじめからうまくいかない、だからできるところから試そう
今後の機能追加や今現在の仕様理解のための大切なバロメーターとなる部分
・内部で保持しているデータが本当に正しいものであるか
・実装されているビジネスロジックが妥当なものであるか

15. 今回のまとめ
できるところから、そして書けるところから少しずつ追加してみる
まずは自分の作った祝祭日判定ライブラリに書いてみる :
Utility系の簡単なライブラリやクラスに対してテストコードを追加する
ステップから初めると比較的テストが書きやすい
内部に予めデータを登録する形式のコードやサンプルで試す :
jsonやcsvデータから表示用のデータを作成して内部に保持するような形
であればModel層の検索や取得処理に関するテストを追記する
利用しているアーキテクチャやロジックに沿ったテストを書く :
実務のコードにおいてこの部分を担保しないといけない部分をまずは優
先してテストを書きそこから継続してテストしやすい形にする繰り返し
1st Step
2nd Step
3nd Step

16. エバーセンスよりメッセージ
ninaruシリーズ・michiru等のサービスは絶賛開発・運用中！
https://eversense.co.jp/
やっていき！