コード日進月歩

プログラミングの技術的なメモなど

『Android Test Night #1』に行ってきたよメモ

Androidのテストとかちゃんと取り組んだことないので知見を得るために行ってきました。 (もしかしたらあとで追記するかも)

コードレビューをより良くする Danger x Android

感想

  • Webhookは結構やってるけどここらへんの取り組みはまだしていないのでやってみたくなる
  • reviewのコメントでチェックがかかる機構は緊急時にすっ飛ばすとかもできるので便利そう

Androidのテストを効率的にするために考えたこと

(スライドなさそう)

テストの効率化にあたり、どう自動化をしたか、何を優先的にやっていったかという話でした。

感想

  • 古くなったテストコードを捨ててイチから作り直すという決断。
  • 書くことのできるコードがから書いていく、取捨選択の大事さを感じる。

Android e2e testing at mercari

www.slideshare.net

感想

  • 今回の発表の中で一番インパクトがあった話、メルカリすごい。
  • E2EテストをSelenium + capybara + rspec っていうRubyと同じ座組でSeleniumをAppiumに置き換えるというパワー、そういやAppiumって「Selenium for Application」が由来だもんね…
  • Androidはデバイスファーム作って運用するのが普通なんだなという感じ
  • サーバレスE2Eテストの仕組みをここまで構築できちゃうのがすごいというか、専属チームならではという感じでした。

AndroidSDK with Docker

speakerdeck.com

感想

  • Dockerでやると使いまわせていいよねという知見
  • AndroidSDKもエミュレータも権利問題めんどくさいので共有しづらいね…

JUnit5とAndroidのテスト

www.slideshare.net

感想

  • JUnitが新しくなろうともAndroidJavaのサポートバージョンが上がらない限りは苦しめられる
  • これ似たような話を何処かで見たような…あ、Uni(ry

Kotlinで書かれたAndroidアプリをBazelでビルドする

speakerdeck.com

感想

  • Bazel、そういうのもあるのか!
  • Kotlin導入予定だが、ダブルで新しいものをやるのでもっと知見が広まったら使ってみたい感

Android CIをBitriseに移行して開発者・QAが幸せになったこと

speakerdeck.com

感想

  • CircleCIでいいじゃんとか思ってたけど、ネイティブアプリ向けに用意されているので予想よりも手厚そうだし、使いやすそう
  • Playのバイナリアップミスって普通にやりがちなのでそのリスクが避けられるのは結構でかい(過去に経験して冷や汗かいた)

Clean Architecture & TDD

speakerdeck.com

感想

  • TDDの方、一回は行ってみたいTDD BootCamp。
  • テストのやりやすさは粒度だと思うので、アーキテクチャでそこらへんの共通認識をカバーできるのはでかいなと思う。
  • やってはみたいが理解が得にくいTDD…

全体的な感想

  • テストのチーム体制が整っているところは自動テストの楽園を作れてて、テスト書く余裕が少しある程度のところはそこまで整っていないみたいに二分されてしまっている印象
  • うまくピックアップして専属チームはいないけど外部サービス連携しまくってうまく回しているぞ!みたいな事例になりたいし、体現しているところは話を聞きたい
  • 過去にiOS Test Nightにおじゃました際にも思いましたが、いまやユニットテスト単体テスト)は当たり前で、以下にE2EテストやUIの検証を効率化&自動化できるかがテストにおいては焦点になってきそうだなという感じ。そうするとSeleniumとAppiumやってないとつらくなりそう。

関連リンク

今回のお話で気になった公式サイトとか

使い方とか知見

他の方のレポート

qiita.com