ブラックボックスなコードに対して少しずつテストを書いていくためのテクニック @k_katsumi #orecon_ios
https://fortee.jp/iosdc-japan-2018/proposal/51b4f787-3341-462e-8b50-c875915613d9
継続的に開発していく上で、テストは非常に重要です。意図しない影響を防ぎ、毎回のレビューの負荷を大きく下げます。一方で、テストがない複雑なコードはすぐにブラックボックス化し、変更もレビューも大変になります。しかし最初からテストを書くことは難しいことも多く、テスタブルなコードでないこともあります。そのような場合でも、大幅な書き換えをすることなく、最小限の負荷でテストを書いていくさまざまなテクニックを、私の経験から実例を用いて解説します。
-
- いいね！0
にわタコ
@niwatako
得られたもの - 起こりうる状態の可視化 - 意図しない影響が分かる - OSのアップデートなどを含む 諦めたもの - 不安定なテスト - 時間のかかるテスト - UIの操作によって動的におこる状態の検証 #orecon_ios
2018-09-12 21:14:01
shiz(しず)@翻訳本発売中
@stzn3
諦めたものもある(ただしまだ過渡期) 不安定なテスト 時間のかかるテスト UI操作で動的に起こる状態のテスト #orecon_ios
2018-09-12 21:14:41
にわタコ
@niwatako
先程のテストをおかしいところまで徹底しているのがこのOSSなので参考にしてください github.com/kishikawakatsu… #orecon_ios
2018-09-12 21:14:45
にわタコ
@niwatako
ある程度出来た段階でカバレッジとかを取ると、書いてないところがあるから書いてやろうみたいな気持ちになるのでうまく使うといい #orecon_ios
2018-09-12 21:15:07
Kenta.Kase
@Kesin11
web界隈だと画像のスナップショットの比較とか、DOM構造を比較することで低コストにデグレを検知するということが行われているっぽいので、アプリ開発もそういう流れになっていきそう #orecon_ios
2018-09-12 21:15:17
にわタコ
@niwatako
- どんなテストでもいいので１つでもテストが毎回実行されるようにする - プロダクトコードを気にせず活用できるものは何でも使う - プロダクトコードではないので、メンテ止まると分かってるライブラリでも書きやすければ使えばいいぐらいの勢い - できるところから少しずつ #orecon_ios
2018-09-12 21:16:43