Code and Passion Take Me Anywhere

iOS Test Night #5でこれから新規でテストを導入する際に役立つ考え方を聞いてきた

time 2017/07/27

iOS Test Night #5でこれから新規でテストを導入する際に役立つ考え方を聞いてきた

iOS Test Night #5に参加した

久々のエントリになるが、来たる2017年7月26日にDeNAで行われたiOS Test Night #5に参加した。

今年の5月からiOSの開発をしており、日頃からSwiftの話はしているものの、ことテストとなると自分はほぼ0ベースの初心者である。
今のチームでテストは導入していないものの、近い将来にやるべきタスクとして最近優先度が高まっている。

その意味で、どんなやり方やフレームワークがトレンドなのか、また使い所や課題は何かといったことを知るきっかけにしたくて行ったのだが、結果としてそれらに関する知見を得ることができ大変有意義な勉強会となった。

例えば、当日の発表で何度か “Property-based test” なるテスト手法の話が出ていた。
自分はこの単語自体を知らなかったので最近のトレンドなのかなと気になった次第(実際単語でググってみたらここ1年以内のエントリが検索上位に来ていた)。
また、E2Eテストによる自動リグレッションテストの話も、チームのQAで活かせそうな話だったので大変おもしろかった。
発表スライドは既にシェアされているので、Connpass等から参照していただくこととしよう。

さて、このエントリでは懇親会で話をさせていただいた参加者の方から得られた、テスト導入でつまづかないようにするための知見を自分用にメモしておきたい。

1. 単体テストを過去の実装には入れない=これからの実装に対して段階的に入れていく

これは既に短期間でテストを文化として定着させることに成功したという、とあるチームから聞いた話。
自分も勘違いしていたことだが、初心者は「既存の実装に対してテストを書かないといけない」と考えがち。
逆に「新しい実装は仕様が固まっていないのでテストは難しい」と思いがち。

しかし既存のコードは、逆に言うとある程度動作が安定しているためテストの導入効果が目に見えにくい。
さらにコードベースも大きいため、結局書いている途中でテストを書く意味を見失い疲弊してしまうそう。

それよりも、新しく作る機能に対して、厳密なTDDのやり方に則りテストを仕様として書いていく方が、効果の実感があり続けやすいらしい。
もちろんよほど試験的な検証段階なら話は別かもしれないが、少なからずテスト導入の効果を実感することと文化として定着させることに対しての効果はありそうだなと思った。

2. テスト導入時は既に知見のあるチームに手伝ってもらおう

これも上記と同様、テスト初心者はどのモジュールからテストを書けばよいのかの見当がつかない。
例えば自分のチームのコードは ViewController, Model, Presenter, Service などのレイヤーにモジュールが分かれていて、どこからテストを書いていくべきかについては、自分もまだ良くわかっていない。

そこで単体 VS 結合といった手法の問題、フレームワークやCI選定といったツールの問題は、本やネットを読むよりも成功したチームから教えてもらった方が圧倒的に良いとのこと。
これも純粋に大きな納得感。
ダイエットも禁煙もテスト導入も、パートナーと一緒に続けると成功しやすいんですね。

幸いなことに、自分の会社の隣のチームが、この勉強会で登壇しているくらい知見をもっていらっしゃるので、この点は心配なさそう。
ただそうでない場合は、こうした勉強会に出てきて知見を得るほかないといった感じだろうか。

ペアプロをするとコードレビューが要らなくなる

ちなみに上記の知見を下さった方のチームでは、テストと同時にペアプロを導入したらしい。
その結果残業時間がほぼなくなるくらい、開発効率が上がったという。
理由の一つがコードレビューが不要になるためらしく、なぜなら隣でナビゲーターがコーディングを見て質問する行為そのものがコードレビューとなっているからということである。
またテキスト経由で使用を把握する必要はなく、言語化しにくい情報も伝わりやすくなり、かつリアルタイム共有されるので自分の手元で再ビルドなども不要になる。

テストコードが増える分だけ、コードレビューすべき部分も増えることは必然であるが、それをペアプロにより効率化しようということである。
自分のチームにはまだペアプロの文化もなく上記のような問題があるので、もし可能ならテスト導入と併せて取り入れたい (しかし今はチームメンバーが少なく時間調整は難航するかも)

単体テストとUIテストは導入すべき箇所がまるっきり正反対

これは別の方から聞いた話。
先程も述べたように、単体テストはTDDとセットで導入して新規の実装で取り入れるべきもの。

ではUIテスト(E2Eテスト)はというと、こちらは変更が起きにくいような既存の実装において導入すべきものらしい。
ビジネスロジック周りや変更の少ないビューなどは、大きな変更が起こりにくい。
レイアウトのテストでも、新規に作る画面はUIやアクションの変更が起こりやすい一方、チュートリアルだとか商品一覧などのページは

ここについてはアプリのグロース状況やそもそもの性質も絡んでくるので、一概にそうとは言い切れないが全体論としては納得感があると思う。
過去の自分も、Railsで作ったアプリでとりあえずRspecと併せてCapybaraを導入してみたものの、頻繁にViewの仕様が変わる度「こんなテストする意味あるのか??」などと思っていた記憶がある。
それは実際には使い所を間違えていたというだけのことだ。

導入したけど辞める、あるいは辞めたけど再開する決断をしやすくする

これが一番大事かもしれない。
「何のためのテストなのか」を考えた時、必ずそこには「コストに見合うだけのパフォーマンス」が求められる
となれば、大規模リニューアルだとかで短期間でリリースしなければいけない状況にもかかわらず、手順どおりにTDDをやるのはコストに見合わないこともあるので、一時的には辞めるべきときもあるかもしれない。

しかし「それでテスト文化を終わりにしない」という努力もまた必要だという話はもっともだと思った。
テストは気軽に始めて、気軽に辞められて、そして気軽に再開できるものでなければいけない。

終わりに

余談だが、今回が社会人になってからの初めて参加した勉強会・カンファレンスだった。
そこで気づいたのは、学生時代と違ってカンファレンスに出て得られる知見の質が違うということ。

目的意識がある勉強会は本当に有意義である。
今日の話は今の仕事に直結する話であったのはもちろん、今の自分のチームにとってテストは「やらなくても良いこと」ではない。
近い将来「やらなければいけないこと」である。
そういうわけで、発表以外に他のチームに聞きたいこともある程度思いついていたので、積極的に話に行けたと思うし、自分の開発に活かそうという姿勢で臨めたかなという所感である。

8月にはBuildersconにも出るので、興味がある部屋を中心に業務や個人プロジェクトに活かせる知見を得て期待と思っている。

ちなみに最近先輩に薦められて読んでいる、テストの入門書がなかなかよさげ。
理論と実践のバランスが良く、細かい実装までは載っていないものの考え方を身につけるのにうまく情報がまとまっている。
境界値分析とか、コードカバレッジとか、ホワイトボックステストとか、一つでも知らない単語があればぜひ買って勉強しましょう。

知識ゼロから学ぶソフトウェアテスト 【改訂版】
高橋 寿一
翔泳社
売り上げランキング: 22,955

このブログを書いている人

imaizume

imaizume

RubyとRでやっていく [詳細]


UA-44092231-5
Bitnami