TDDチュートリアル

Apr. 10th 2019
Android Tests Hands-on
TDDチュートリアル
@hoddy3190

View Slide

鈴木穂高（Hodaka Suzuki）
Twitter @hoddy3190
● 2014年DeNA新卒入社
● アプリゲーム開発・運用（2014/08 〜 2018/10）
○ サーバー、クライアント、マスター管理ツール、インフラ整備、
マネジメントなど
● テスト技術チーム - SWET（2018/10 〜）
○ 仕様品質を向上させるための技術的なアプローチ研究
■ https://speakerdeck.com/hoddy3190/xing-shi-shou-fa-nituitediao-betemita
○ Androidのテスト教育のための活動

View Slide

目次
● TODOリストに起こそう
● テストを書こう
● 演習
● テストを書こう（つづき）
● 構造化
● まとめ
● 演習

View Slide

本資料で使うツール、言語、ライブラリ
● Android Studio 3.3.2
● kotlin 1.3.21
● JUnit5 1.4.0
○ https://junit.org/junit5/docs/current/user-guide/

View Slide

TODOリストに起こそう

View Slide

お題
● 1から100の数が入力されたら、その数の文字列を出力する
プログラムを書け。
● ただし3の倍数のときは数の代わりに「Fizz」、
5の倍数のときは「Buzz」を出力しなければならない。
● 3と5両方の倍数の場合には「FizzBuzz」と
出力しなければならない。

View Slide

文脈
● フォームに数字を入力し、ボタンを押すと、
FizzBuzzの結果を表示するプログラムを書いている
● ボタンを押すと、フォームに入力したテキストを
そのまま結果欄に表示させるところまではできた
● これからFizzBuzz変換ロジックを書こうとしている
結果欄
ボタン
フォーム

View Slide

class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
fizzbuzz_button.setOnClickListener {
setResultText(convert(fizzbuzz_form.text.toString()))
}
}
private fun convert(input: String): String {
// fizzbuzz変換
return input // 仮
}
private fun setResultText(str: String) {
result_text.text = str
}
}
文脈（MainActivityの現在の中身）

View Slide

まずは細かなタスクに分解
コツ: 先に機能（仕様）の概要を定義し、そこに枝葉をつけていく
ドリルダウンの思考
コツ

View Slide

● [ ] 数を文字列にして返す
● [ ] 3の倍数のときは数のかわりにFizzと返す
● [ ] 5の倍数のときはBuzzと返す
● [ ] 3と5両方の倍数の場合にはFizzBuzzと返す

View Slide

概要

View Slide

枝葉

View Slide

この順番で実装

View Slide

この順番で実装
正常系
準正常系
準正常系
準正常系

View Slide

テストを書こう

View Slide

対象

View Slide

テストファイルを作る
クラスに対応するテストファイルを作ってくれる
まだMainActivity.ktしか存在しないので、MainActivity上でたたく
Cmd + Shift + T

View Slide

FizzBuzzTestにする
チェックをつける

View Slide

テストができる
internal class FizzBuzzTest {
@Test
fun onCreate() {
}
}

View Slide

落ちるテストを書く
@Test
fun onCreate() {
assertEquals(1, 2)
}
}
落ちるテストを記述

View Slide

@Test
fun onCreate() {
assertEquals(1, 2)
}
}
assertEqualsと入力すると候補がたくさん出るが
一番上のものを選んでくれればOK（なんでも良い）

View Slide

@Test
fun onCreate() {
assertEquals(1, 2)
}
}
usage: assertEquals(expected, actual)
expectedが先に来ることに注意

View Slide

テスト個別実行
あるテストを個別に実行したい場合、
カーソルをそのテスト内に移動させ、上のコマンドをたたく
@Test
fun onCreate() {
assertEquals(1, 2)
}
}
Ctrl + Shift + R
このあたりにカーソルを持ってきて
コマンドをたたく

View Slide

もしが効かない場合
Keymapがコンフリクトしている可能性。
[ Preferences ] -> [ Keymap ] でKeymapを変更しよう。
例えば、Ctrl + Shift + Z がよい。
Ctrl + Shift + R
検索ワード

View Slide

しっかり落ちることを確認
意図通りに落ちるということは、
問題なくテストが動いていることを意味する
org.openTestj.AssertionFailedError:
Expected :1
Actual :2

View Slide

テストを書いていこう
@Test
fun onCreate() {
assertEquals(1, 2)
}
}
アサーションを削除

View Slide

テストは動く仕様書
@Test
fun 数を文字列にして返す () {
}
}
日本語で書くのもあり
※ただし、instrumented testでは使えない

View Slide

@Test
@DisplayName("数を文字列にして返す ")
fun intToStringTest() {
}
}
DisplayNameでもOK

View Slide

テストコードをどう書けばよいのかわからない
=> タスクに具体性が足りていない

View Slide

○ 1を渡したら文字列"1"を返す
NEW

View Slide

テストケース修正
@Test
fun _1を渡したら文字列1を返す() {
}
}

View Slide

@Test
}
}
関数名の最初の文字に数字を使えない

View Slide

@Test
fun `1を渡したら文字列1を返す`() {
}
}
バッククオートで囲むのもよい
※ただ、クラス名で適用したときにテスト結果の表示が変になった

View Slide

ここからどう書いていくか
@Test
}
}

View Slide

3A
@Test
// Arrange 前準備
// Act 実行
// Assert 検証
}
}
前準備、実行、検証

View Slide

アサートファースト
● 一番具体的な例からどういう実装をしなければならないかを逆算して考える
● 使う人目線でどんなオブジェクトにどんな関数が生えているとよいのかを考える
@Test
// Act 実行
// Assert 検証
}
}
検証から書こう

View Slide

@Test
// Act 実行
// Assert 検証
assertEquals(“1”, )
}
}
返り値として文字列を返そう

View Slide

@Test
// Act 実行
// Assert 検証
assertEquals(“1”, fizzbuzz)
}
}
ﬁzzbuzzというオブジェクトを用意して

View Slide

@Test
// Act 実行
// Assert 検証
assertEquals(“1”, fizzbuzz.convert)
}
}
数字を文字列に変換する関数が
生えていると使いやすそうだ

View Slide

@Test
// Act 実行
// Assert 検証
assertEquals(“1”, fizzbuzz.convert(1))
}
}
引数として数字を渡すのはどうだろう

View Slide

@Test
// Act 実行
// Assert 検証
assertEquals("1", fizzbuzz.convert(1))
}
}

View Slide

@Test
// Act 実行
// Assert 検証
}
}
コンパイルエラー

View Slide

ローカル変数作成
エラーが出ている文字の上でたたくと、修正案を
表示してくれる。今回はローカル変数を作る。
@Test
// Act 実行
// Assert 検証
}
}
Opt + Enter

View Slide

@Test
// Act 実行
// Assert 検証
val fizzbuzz
}
}
Opt + Enter
追加される

View Slide

@Test
val fizzbuzz
// Act 実行
// Assert 検証
}
}
Opt + Enter
移動

View Slide

コンパイルエラー直し
@Test
val fizzbuzz = FizzBuzz()
// Act 実行
// Assert 検証
}
}
初期化処理追加

View Slide

コンパイルエラー直し
@Test
// Act 実行
// Assert 検証
}
}
まだエラー

View Slide

クラス作成
表示してくれる。今回はクラスを作る。
Ctrl + Shift + R
@Test
// Act 実行
// Assert 検証
}
}
Opt + Enter

View Slide

クラス作成
表示してくれる。今回はクラスを作る。
Ctrl + Shift + R
@Test
// Act 実行
// Assert 検証
}
}
Opt + Enter
そのままOK

View Slide

プロダクトコードに空のクラスができる
class FizzBuzz {
}

View Slide

前回見ていた場所に戻る
@Test
// Act 実行
// Assert 検証
}
}
Cmd + [

View Slide

行き来が面倒であればsplit windowを使おう

View Slide

新たなコンパイルエラー
@Test
// Act 実行
// Assert 検証
}
}
新たなコンパイルエラー

View Slide

また
@Test
// Act 実行
// Assert 検証
}
}
Opt + Enter

View Slide

メンバ関数ができる
class FizzBuzz {
fun convert(i: Int): Any? {
}
}

View Slide

class FizzBuzz {
fun convert(i: Int): String {
return ""
}
}

View Slide

class FizzBuzz {
return ""
}
}
仮引数はIntにして、返り値はStringにする
とりあえず空文字を返しておく

View Slide

ようやくコンパイルエラーがなくなる
@Test
// Act 実行
// Assert 検証
}
}

View Slide

考えたこと
● メソッド名
● クラス名
● 引数
● 返り値
一番最初サイクルで書く時は結構考えること多い
なるべく小さめの機能を選ぶのがコツ

View Slide

テスト実行
@Test
// Act 実行
// Assert 検証
}
}
Ctrl + Shift + R

View Slide

落ちる
Expected :1
Actual :
RED

View Slide

落ちる
Expected :1
Actual :
RED
でもちゃんとテストがコンパイルされた

View Slide

テストが通るように修正
class FizzBuzz {
return "1"
}
}
GREEN

View Slide

class FizzBuzz {
return "1"
}
}
テストを通すための最小限の修正
GREEN

View Slide

仮実装
いきなり本格的なコードから書き始めると、
テストが失敗したときに、原因がテストコードにあるのか
プロダクトコードにあるのかがわかりづらくなるので、
まず簡易的な実装をしてテストを通過させる

View Slide

テスト駆動開発において
テストコードにバグがないことを
どうやって保証するか

View Slide

テストコードのテストコードを書く？

View Slide

きりがない
テストコードのテストコードを書き、
テストコードのテストコードのテストコードを書き、
テストコードのテストコードのテストコードのテストコードを書き...

View Slide

テストコードのテストは実装側で行う

View Slide

テスト実行
@Test
// Act 実行
// Assert 検証
}
}
Ctrl + Shift + R

View Slide

通った GREEN

View Slide

○ [ ] 1を渡したら文字列"1"を返す

View Slide

三角測量
テストが偶然パスしただけなのではという不安を払拭するために、
2つ以上の入力を使用してテストを書き、
そのテストが予想通りに落ちるかを確かめる

View Slide

別の入力を使いながら、既存のテストのパスは保ちつつ、
プロダクトコードをリファクタしていく
入出力は明らかなのに内部ロジックが容易にイメージできない実装をする
場合にも有用なテクニック

View Slide

NEW

View Slide

入力が2のときのテストを書こう
@Test
// Act 実行
// Assert 検証
}
}

View Slide

アサーションルーレットアンチパターン
1つのテストに複数のアサーション
@Test
// Act 実行
// Assert 検証
}
}
JUnitの場合、あるアサーションでエラーが出て
しまうと、以降のアサーションが実行されず、
TDDサイクルを正常に回すことができなくなる

View Slide

原則
1 assertion per 1 test

View Slide

@Test
// Act 実行
// Assert 検証
}
@Test
// Act 実行
// Assert 検証
}
}

View Slide

@Test
// Act 実行
// Assert 検証
}
@Test
// Act 実行
// Assert 検証
}
}
テストを分割して書く

View Slide

テストを回すと落ちる
Expected :2
Actual :1
RED

View Slide

class FizzBuzz {
return i.toString()
}
}
GREEN

View Slide

テストは個別実行ではなく全体実行
プロダクトコードの書き換えにより、
既存のテストの結果が変わることもあるため
クリック

View Slide

通った GREEN

View Slide

テストコード
@Test
}
@Test
}
}
Refactoring

View Slide

@Test
}
@Test
}
}
3Aコメントの削除
テストコード Refactoring
3Aコメントの削除

View Slide

前回と同じテストを実行 Ctrl + R
前回実行したテスト

View Slide

通った Refactoring

View Slide

@Test
}
@Test
}

View Slide

@Test
}
@Test
}
共通化できるところを
共通化する

View Slide

テスト用関数（setUp関数）作成
テストで使うコードのテンプレートから関数を作れる。
カーソルをそのテスト内に移動させ、上のコマンドをたたく。
@Test
...
}
Cmd + N
このあたりにカーソルを持ってきて
コマンドをたたく

View Slide

テスト用関数（setUp関数）作成
テストで使うコードのテンプレートから関数を作れる
カーソルをそのテスト内に移動させ、上のコマンドをたたく
@Test
...
}
Cmd + N

View Slide

@BeforeEach
internal fun setUp() {
TODO("not implemented") // To change body of created
functions use File | Settings | File Templates.
}
@Test
}
...
setUp関数作成 Refactoring

View Slide

private lateinit var fizzbuzz: FizzBuzz
@BeforeEach
fizzbuzz = FizzBuzz()
}
@Test
}
...
共通処理をsetUp関数に集約 Refactoring
追加
追加

View Slide

@Test
}
@Test
}
少しずつ直してテスト実行 Refactoring
まずはここだけ削除

View Slide


View Slide

@Test
}
@Test
}
少しずつ直してテスト実行 Refactoring
次はここを削除

View Slide


View Slide

補足
共通化は、同じ処理が2箇所に現れたら行う派と、
同じ処理が3箇所に現れたら行う派がいる。
今回は、FizzBuzzの簡易性や説明の流れの都合を加味して
このタイミングで共通化を行った。

View Slide


View Slide

演習

View Slide

対象
仮実装・三角測量を使いながらやってみよう

View Slide

class FizzBuzz {
return i.toString()
}
}
private lateinit var fizzbuzz: FizzBuzz
@BeforeEach
fizzbuzz = FizzBuzz()
}
@Test
fun _1を渡したら文字列 1を返す() {
}
@Test
fun _2を渡したら文字列 2を返す() {
}
}
今段階のテストコード
今段階のプロダクトコード

View Slide

便利なショートカット一覧（keymap種別: Mac OS X 10.5+）
Ctrl + Shift + R
Cmd + N
Opt + Enter
Cmd + Shift + T
Ctrl + R
コードを生成（テスト関数などを作れる）
テストファイルを作る
テストファイルとプロダクトファイルの行き来をする
クイック修正
テストの個別実行
最後に実行したテストの再実行
前見ていた場所に戻る
Generate...
Test
Run ‘hogeTest‘
Run ‘hogeTest‘
コマンドアクション名説明
Show Intention
Actions
Back
Cmd + [

View Slide

解答例

View Slide

○ [ ] 3を渡したら文字列"Fizz"を返す
NEW

View Slide

@Test
// 省略
}
@Test
// 省略
}
@Test
fun _3を渡したら文字列Fizzを返す() {
assertEquals("Fizz", fizzbuzz.convert(3))
}
}
追加

View Slide

落ちる（個別実行） RED

View Slide

テストを通すための最低限の修正（仮実装）
class FizzBuzz {
if (i == 3) return "Fizz"
return i.toString()
}
}

View Slide

通った GREEN

View Slide

NEW

View Slide

三角測量
// 省略
@Test
}
@Test
}
// 省略
追加

View Slide

落ちる RED

View Slide

class FizzBuzz {
if (i % 3 == 0) return "Fizz"
return i.toString()
}
}
GREEN

View Slide

通った GREEN

View Slide


View Slide

つづき

View Slide

対象

View Slide

...
@Test
}
@Test
fun _5を渡したら文字列Buzzを返す() {
assertEquals("Buzz", fizzbuzz.convert(5))
}
...
テストケース追加
追加

View Slide

落ちる RED

View Slide

class FizzBuzz {
if (i % 5 == 0) return "Buzz"
return i.toString()
}
}

View Slide

class FizzBuzz {
if (i % 5 == 0) return "Buzz"
return i.toString()
}
}
あえてif (i == 5) とは
書かなかった

View Slide

明白な実装
テストの書き方や実装の仕方に不安がないときは
テストを書いて、見えている実装をそのまま書く

View Slide

通った GREEN

View Slide

構造化

View Slide

FizzBuzzを一切知らない人がこのテストコードを見たら、
FizzBuzzの挙動がわかるようになっているか
@Test
}
@Test
}
@Test
}
@Test
}
@Test
}

View Slide

日本語で仕様書を書くときに、
箇条書きといった見せ方の工夫をするように
テストでも同じことをやる

View Slide

テストを構造化
@Nested
inner class _3の倍数の場合 {
}
@Nested
}
@Nested
inner class その他の場合 {
}

View Slide

@Nested
@Test
}
@Test
}
}
@Nested
@Test
}
}
@Nested
@Test
}
@Test
}
}

View Slide

すっきり

View Slide

テストケースの整理
対称性の乱れは整理のきっかけ。
※対称性がとれていないからといってそれが悪いわけではない。
ただテストコードを読む際に気にする人もいたりする。
もうひとつ
2つ
1つ
2つ

View Slide

テストケース数
● 1つに統一するか
● 2つに統一するか
2つ
1つ
2つ

View Slide

どちらがよいのか正解はないし、
統一しないといけないわけでもない

View Slide

不安をトレースしたテストケースになっているか
「不安かどうか」というといささか抽象的に感じられるかもしれませんが、
TDDではそういった感情をとても大切にしています。

View Slide

不安がない場合
不安が残らないように入力を1つに統一する。
プロダクトコードと同じく、後でテストコードを減らすのは
ものすごい大変なので、ここで消しておくメリットもある。

View Slide

View Slide

不安がある場合
別のテストケースを加える。
入力を2つに統一するようにテストケース数を調整してもよいし、
対称性にこだわらず、さらにテストケースを追加しても良い。
不安が残らないようにするのが大事。

View Slide

View Slide

○ [ ] 5を渡したら文字列"Buzz"を返す

View Slide

まとめ

View Slide

まとめ
● 問題を小さく分割する
○ TODOリスト形式など
● 歩幅を適切に選ぶ
○ 不安だったらテスト -> 仮実装 -> 三角測量 -> 実装
○ やや不安だったらテスト -> 仮実装 -> 実装
○ 不安がなければテスト -> 明白な実装
● テストコードの読み手のことも考えて
テストの構造化とリファクタリングも忘れずに

View Slide

リファレンス
● 50分でわかるテスト駆動開発
○ https://channel9.msdn.com/Events/de-code/2017/DO03?ocid=player
○ 本資料は上の和田卓人（t_wada）さんの動画を参考にしています
○ 動画内でt_wadaさんがFizzBuzzの実装のTDDライブコーディングを
行っていますので、もしご興味あれば是非見てみてください
○ CC BY 4.0に基づいて使用しています
● テスト駆動開発
○ Kent Beck 著 / 和田卓人訳
○ オーム社

View Slide

演習

View Slide

対象

View Slide

解答例

View Slide

○ [ ] 15を渡したら文字列"FizzBuzz"を返す
○ [ ] 30を渡したら文字列"FizzBuzz"を返す

View Slide

@BeforeEach
fun setup() {
fizzbuzz = FizzBuzzComp()
}
@Nested
inner class _3の倍数かつ5の倍数の場合 {
@Test
fun _15を渡したら文字列FizzBuzzを返す() {
assertEquals("FizzBuzz", fizzbuzz.convert(15))
}
}
@Nested
// 省略
}

View Slide

落ちる RED

View Slide

class FizzBuzz {
if (num % 15 == 0) return "FizzBuzz"
if (num % 3 == 0) return "Fizz"
if (num % 5 == 0) return "Buzz"
return i.toString()
}
}

View Slide

通った GREEN

View Slide

@Nested
inner class _3の倍数かつ5の倍数の場合 {
@Test
}
@Test
}
}
@Nested
// 省略
}
不安だったので追加

View Slide

通った GREEN

View Slide

@Nested
inner class _3の倍数または5の倍数の場合 {
@Nested
@Test
fun _15を渡したら文字列 FizzBuzzを返す() {
}
@Test
}
}
@Nested
//　省略
}
@Nested
//　省略
}
}
@Nested
//　省略
}
Refactoring

View Slide

@Nested
@Nested
@Test
}
@Test
}
}
@Nested
//　省略
}
@Nested
//　省略
}
}
@Nested
//　省略
}
Refactoring
構造化

View Slide


View Slide

演習

View Slide

TDDBC(TDD Boot Camp)
http://devtesting.jp/tddbc/
TDDについて、実習形式で手を動かして体得することを
目的とするイベント。定期的に開催されている。
イベントで使った「お題」についても公開されているので
興味があればどうぞ！

View Slide

TDDチュートリアル

TDDチュートリアル

Hodaka Suzuki

More Decks by Hodaka Suzuki

Other Decks in Programming

Featured

Transcript