iOS Test Night #7 参加レポート
iOS Test Nightにブログ枠として参加しました!
内容の詳細はスライドを読むのが一番なので書きません!感想メインで書いていきます。
SwiftにおけるMockライブラリの活用
トビ@デベロッパーのおしごと! (@tobi462) | Twitter
MockitoインスパイアなMockライブラリが2つ紹介されてました、CuckooとMockitです。ぼくはFlutterでもmockitoを使ってるので、学習コストの面でもそのどちらかを使おうかなーという感じです。
個人的に手動でMockを作ることにあまり抵抗はないですし、業務でも手動でやってますが、試しに導入できそうだったらしたいなと思います。
Visual Studio App Centerで始めるCI/CD
www.slideshare.net
テスト結果が視覚的に見やすくていいなと思いました。それからUDIDを追加したときに再署名されたプロファイルを含めて自動で配信してくれる(?)らしく、どちゃくそ便利。
つい最近、業務でちょうどMSのHockeyAppを使っているのですが、今回の発表を聞いて意外とMS頑張っているなーと驚きました!選択肢のひとつに加えたい。
DI with Reader Monad
Toshiki Takezawa👻 (@to4iki) | Twitter
関数に引数で渡すProtocolによってDI(≒Mock化)できるのはかなり面白いと思いました。ただ....多分....使わないだろうなー...。
ライブラリが公開されています。
モナドはいまだにちゃんと説明できないのでなんかいい記事ないかなーと探してたらこんな記事に出会いました。モナド、ポケモン、モナド、ポケモン。
はじめて書いたテスト
ryokosuge (@ryo_kosuge) | Twitter
こういう話好きです。チームメンバーに迷惑がかかるのを避けたいからテストを書き始めたというのが素晴らしいなーと思って聞いてました。たしかに人って他人に迷惑がかかるならなんか頑張っちゃう気がします。
逆にいうと、チームにテスト書く習慣を付けたいけどどうしたらいいかわからない!という人は、迷惑がかかっている雰囲気を出す、もしくはそういった仕組みをこっそり導入すればいいかもしれませんね。
また↓で登場するTDDを導入してみるのもいいかもしれません。
Swiftで書いておぼえるTDD
タイポー田中@技術書典4く-07 (@ktanaka117) | Twitter
これはまだスライドがあがっていませんが、人を殺せる厚みのTDD本を8000円で買いましたというお話でした。というのは嘘で、実際業務でテストに関する取り組みを積極的にしているご自身の経験から、TDDを導入して得られるメリットなどをお話してくださいました。(TDD本買ったのは本当)
そのなかでも、常にプロダクトコードに関して改善意識が持てる、というのは大きいメリットだなーと思います。しかもチーム全体で。
なかなか案件のお尻が決まってスケジュールがキツキツだったりして、思うようにリファクタや改善が進まないこともあると思います。というかあります。TDDを導入すると、"テストを書く"ということが"機能を実装する"ことの一部になるので、自然にテストを書く文化が根付くのかなーと思います。
// TODO: リファクタ
// TODO: テスト書く
って書かれたコードがプロダクトコードに眠っている人は、思い切ってTDDを導入すると案外そのTODOが実現されたりするかもしれないですね。
おわりに
まずスタッフの方々、楽しいイベントでしたありがとうございました!参加者も多かったですし、みなさんテストに関心があるのだなーと関心しました。
ぼく自身はというと、今ぼくが業務で触っている3つのアプリ(と自社作ライブラリ)すべてでテストが書けているわけではないので、テスト(TDD)導入の体験談が聞けたのはすごくよかったです。
あとテストを書く人は偉い。そう思いました。テストを書いたらみんなで褒めていきましょう。そして書いた人は自慢していきましょう。そのスパイラルが、じつはテストを書く組織/人になるために一番重要なのかもしれません。
テスト書いたら全力で自慢していきましょ #ios_test_night
— あぼぼ (@suxisuxido) 2018年3月26日