(1) Android 網羅的単体テスト編-> https://qiita.com/hal319/items/a8b1d52ac0cfb36f4cee
(2) 網羅率測定-> 現在ココ
(3) github・CircleCI統合（作成中）
(4) AppiumでUI部分実装（作成中）

code coverageはちとメンドウなようだ

Code Coverage Tool準備

まず下記のどちらを選ぶかだ。2020年7月時点では

• Jacoco
• IntelliJ Code Coverage

どうもKotlinの場合はJacocoがハンドルできないという。とりあえず自動テストに特化したところの確認なので、一番簡単そうなJava　& Jacocoで進めてみる。build.gradleに以下のdebugセクションを加えてみる。

debug{
            testCoverageEnabled true
        }

一番簡単な網羅（命令網羅）

テストするソースは「Android 網羅的単体テスト編」と同様で。

package com.example.empty;
public class calc {
    public int plus(int a, int b) {
        int c = a + b;
        return c;
    }
    public int div(int a, int b){
        int c = a/b;
        return c;
    }
}

単体テストは

public class calcTest {
    private calc mcalc;

    @Test
    public void plus() {
        mcalc  = new calc();
        assertEquals(0, mcalc.plus(0,0),0 );  //Added test code

    }
}

単体テストを実行すると、なんとなくplus(int a, int b)だけテストされるのは想定できる。

$ ./gradlew createDebugCoverageReport

を実行すると。
ちょっと深いフォルダーの先に、網羅率のリポートが作成される。

plus(int, int)の部分は100%網羅されている。それでは分岐網羅がちゃんと動いているかみてみましょう。

分岐網羅

数年前までは分岐網羅はJacocoはサポートしてなかったような気がするので、分岐網羅が動いているか見てみる。開発者の方は命令網羅と分岐網羅の差はただたんに１０％程度網羅率が違うという評価を下す場合があるが（一般的なソフトウェアの場合分岐のほうが10%程度低くなる）、テスト屋さんにとっては命令網羅というのは品質保証上なんにも役ににたたない。なぜなら一番重要なテスト手法である、境界値テストがちゃんとされているか否かの判断基準は命令網羅ではもてないためである。

すこし乱暴だが、以下のようにテストされる関数を変更してみる。分母にゼロが来た場合にはそのままreturn 0で抜けてしまう。

public class calc {
    public int plus(int a, int b) {
        int c = a + b;
        return c;
    }
    public int div(int a, int b){
        if (b == 0){
            return 0;
        }
        else {
            int c = a / b;
            return c;
        }
    }
}

テストコードとしては、以下のようなものを追加してみる。2/1 =2 という正常処理ケース。

public class calcTest {
    private calc mcalc;

    @Test
    public void plus() {
        mcalc  = new calc();
        assertEquals(3, mcalc.plus(2,1),0 );  //Added plus test code
        assertEquals(2, mcalc.div(2,1),0 );  //Added div test code

    }
}

結果としては、以下のようになる。

div関数の分岐が50%網羅されていることになる。ここでCxtyという数値がある、Cyclomatic Complexity(またはMcCabe数とも言う)。関数の複雑をだしてくれるのはすごいステキ。分岐網羅すべきテストケース数とCxtyというのは同じである。Cxtyが高ければ単体テストを作るコストの比例的にあがる。

参考にしたweb

https://thom.hateblo.jp/entry/2016/02/28/182648
http://replication.hatenablog.com/entry/2016/05/26/071409
https://wadada420.hatenablog.com/entry/2019/01/27/223100
https://qiita.com/keidroid/items/adc4f065b84d8a2cd17a