2022-04-20

Kotlinファーストなテストフレームワークについて

Kotlinにおけるテストフレームワークについて断片的な知識しかなく今まで雰囲気で技術選定していたので、主要なものを軽く調べてみた結果を備忘録として簡単にまとめてみます

調査対象

テストフレームワーク
- https://github.com/kotest/kotest
- https://github.com/spekframework/spek
アサーションライブラリ
モックライブラリ（列挙のみ）
- https://github.com/mockk/mockk
- https://github.com/mockito/mockito-kotlin

Kotest

Kotlin Multiplatformにも対応した包括的なテストフレームワーク
Kotlin JVMの場合はテストフレームワークにJunitを利用してアサーションライブラリだけを利用することも可能
フレームワークとしては複数のスタイルが定義されており様々な書き方に対応している ~~混乱を招かないかこれ~~
アサーションとしては拡張関数や中置関数を利用した記述が特徴で流れるように書ける

class StringSpecTest : StringSpec() {
    private val calc = Calc() 
    init {
        "10 割る 5 は 2 になる" {
            calc.divide(10, 5) shouldBe 2
        }
        "10 割る 0 は例外(ArithmeticException)が起きる" {
            shouldThrow<ArithmeticException> { calc.divide(10, 0) }
        }
    }
}

Spek

https://www.spekframework.org/

こちらはテストフレームワーク、2.0からMultiplatform対応がされたようだがいかんせんドキュメントが少ない
フレームワークとしてはカッコでネストしていく記法で一部Hookっぽい部分もありちょっと癖を感じる
アサーション機構はなくHamcrestやkotlin.test など別のアサーションライブラリと組み合わせて使っていくっぽい

class SimpleTest : Spek({
    describe("a calculator") {
        val calculator = SampleCalculator()
 
        it("should return the result of adding the first number to the second number") {
            val sum = calculator.sum(2, 4)
            assertEquals(6, sum)
        }

        it("should return the result of subtracting the second number from the first number") {
            val subtract = calculator.subtract(4, 2)
            assertEquals(2, subtract)
        }
    }
})

Kluent

https://markusamshove.github.io/Kluent/

アサーションのみを担うライブラリ、一部Multiplatformにも対応しているが中途半端
書き味はKotestに非常に近くて個人的には好み、ただだいぶ放置気味でメンテ不安なのでKotestのほうが個人的にはおすすめ

class SampleTest {
    @Test
    fun test {
        val value = 10
        value shouldBeInstanceOf Int::class
    }
}

atrium

https://docs.atriumlib.org/

こちらもMultiplatform対応のアサーションライブラリ、公式サイトが無駄に渋い
expect()を軸としたメソッドチェーンを多用してアサーションを組み立てていくのが特徴

 class SampleTest {
     @Test
     fun test {
         expect(4 + 6) {
             toBeLessThan(5)
             toBeGreaterThan(10)
         }
     }
 }

所感

いくつか調べてみた感じ、私のようなJunit+Hamcrestに慣れきった人が今から新規採用するなら下記の技術群がいいのではないかと感じました

テストフレームワーク: Junit (or Kotest)
アサーションライブラリ: Kotest
モックライブラリ: Mockk

2019-02-06

DroidKaigi 2019で発表する「中規模以上のアプリ開発におけるCIレシピとリリースフロー戦略」について

DroidKaigi 2019にて
「中規模以上のアプリ開発におけるCIレシピとリリースフロー戦略」
というタイトルで登壇します
会場にお越しになる方はご興味ありましたら見に来て下さい！

時間 : 2019/02/08 (Day 2) 10:30-11:00
場所 : Room2

droidkaigi.jp

概要

BitriseやCircleCI, TravisCIなどに代表されるCIツール（継続的インテグレーション）の導入方法を解説した記事は多くありますが、実際に運用フローに組み込むところまで言及されていることは少ないと思います。
複数人のエンジニアが絡む中規模以上の開発においては、開発フローに一定のルールを設け、ブランチ運用とCIをうまく連携させて自動化しヒューマンエラーを減らすことが大事です。

3〜4人での開発体制の中規模アプリを2週に1度のペースでリリースを年単位で続けた自身の経験を元に、実運用に耐えうるブランチ運用とCIレシピから事故の少ないリリースフローまでをGitFlowとBitriseをベースに解説します。
また、Google Play Developer Publishing APIを活用して安定的なリリースを行うための手法や各プロダクトに合わせたカスタマイズ方法についても、実際の業務での運用を元に解説します。

スライド

https://speakerdeck.com/kazakago/zhong-gui-mo-yi-shang-falseahurikai-fa-niokeruciresihitoririsuhurozhan-lue

スライド内で紹介したリンク

git-flow cheatsheet

Git-Flowの解説をしている代表的なサイト

git-flow cheatsheet

bitrise.yml

スライド内で紹介したBitrise用の汎用yamlファイル

bitrise.yml example · GitHub

StepReleaseDispatcher

スライド内で紹介したPlayストアにおける自動的な「段階的な公開」を行うためのKtor製サーバープログラム

github.com

2018-07-08

AniStackというアニメ視聴管理アプリを作った話

友人と2人でAniStackというアニメ視聴管理アプリを作ったので忘れないうちにやったことを書き留めておこうかと思います。
よければダウンロードしてね！

作ったもの

iOS版

AniStack

Kensuke Tamura
エンターテインメント
無料

Android版

play.google.com

きっかけ

エンジニアの友人である @alumys となんかアプリ作りたいよねって話をしていて、お互いアニメ好きだったので視聴管理できるアプリ作ろうという話から生まれました。

Annict

Annictというアニメ視聴管理サービスがあるのですが、そちらではAPIを公開されており、なおかつオフィシャルのクライアントアプリもなかったのでちょうどよさそうという話になりました。
（有志でクライアントアプリを作っている先人の方は何名かおりましたが）

なんとこのサイト、@shimbacoさんという方が個人で運営しているとのこと。このクオリティは素晴らしいの一言に尽きます。
私もユーザーで楽しく使わせて頂いているのでこの場で感謝申し上げます。

技術的なこと

担当割り振り

お互いAndroid/iOSどちらも書けるのですが相談の上、自分がiOS担当、@alumysがAndroid担当で実装しました。
またアイコンやロゴについてはデザイナーの方にも協力頂いています。

iOSはリリースを維持するのに毎年お布施が必要なので、新規アカウントを作らず元々持っていた自分名義のアカウントですべてリリースしています。

ツール

お互い別の会社に勤めているため、効率的に作業を進める必要がありいくつかのツールに頼りました。
オープンソースではないためクローズドに扱えるツールを中心に使いました。

ソース管理：Bitbucket
CI：Bitrise
デプロイ：Deploygate
コミュニケーション：Slack

ちなみに個人プロダクトであってもCIで自動的にDeploygateデプロイ+Slack通知を組むとめちゃんこ便利です。

言語

どちらもネイティブで書いており、iOSはフルSwift・AndroidはフルKotlinで書いています。
あとはアーキテクチャやクラス設計、画面仕様だけ合わせてそれぞれで実装しています。

アーキテクチャ

アーキテクチャはお互い業務でも使っているCleanArchitecture + MVPで実装しています。 RxとDIツールを組み合わせて使っています

ぶっちゃけ個人規模であればMVCで雑に作るのが最速かつ問題もそこまで起きないと思いますが、仕事だとやるのが難しいガチガチの設計で組みたいよねという話になりました。

画面設計

各OSで用意されているプレーンなコンポーネントを中心にシンプルな画面設計にしています。

最初JustInMindを使ってプロトタイプを組もうと思ったのですが、高機能すぎてワイヤーだけサクッと作るというのが逆に難しく、結局紙に書いてそれを直接実装しました。

この辺はAndroid・iOS両コンポーネントを把握しているエンジニア同士だからこそ、雑な画面設計から実装のイメージが付く部分なのかなとも思ったりします。

ただ、両OSの基本デザインを崩さないようには注意しました。（iOS風Androidアプリにしないとか）

アイコン・ロゴ

f:id:kazakago:20180707195635p:plain

アイコンやストアロゴなどのは流石に自前で用意できなかったので、会社のデザイナーさんに依頼して作ってもらいました。（もちろん有料でｗ）

ちなみにAndroidのアイコンはAdaptive-Iconに対応しています。
個人アプリでAdaptive-Iconに対応してるアプリは少ないのではないでしょうか。
細かいところに気を使ってくれるデザイナーさんには頭が上がりません。

こういうとき繋がりがあると非常に助かりますね。

UI/UX実装

UXを組むときに特に注意したのは、ユーザーの操作をなるだけ妨害せずに通信中かどうかを示す部分です。

ログイン中などはProgressHUDを表示して操作できないようにしていますが、その他非同期で取得できるものは画面上に通信中の表示を出しつつ、ユーザーの操作を邪魔しないような配慮をしています。
たとえば以下の作品詳細画面は、画面下部の視聴ステータスを非同期で取得しています。
変更時も非同期で情報の送信を行い読み込み中のストレスを最大限抑えています。

f:id:kazakago:20180707233307g:plain

また作品一覧画面では下まで読み込んだときにページング処理を行っていますが、読み込みに失敗した際は最後のセルにエラーの表示を出しています。
さらに再試行ボタンを押した場合にはその部分から再試行を行い、ロード済みの情報を失わずにシームレスに復帰できるよう実装をしました。

f:id:kazakago:20180707233436g:plain

リリースしてみて

自分自身すでにOSを変えながら何度かソフトやアプリをリリースしていますが、やはりいちばん大変なのが8割方作った後の作業だったりします。

なにかを出したことがある方ならよくおわかりだと思いますが、最後の詰めが一番めんどくさく手間がかかります。
アプリの場合はUIの細かい微調整や使い勝手の向上、ストア情報の準備や利用規約の用意、このあたりをいかに手を止めずに進められるかが個人でプロダクトをリリースするための肝になるかなぁと感じています。