{Why,How} should we do testing ?

Slide 1

Slide 1 text

{Why ,How } should we do testing ? by @izumin 5210 2016/12/10

Slide 2

Slide 2 text

Masayuki Izumi (@izumin 5210) Rekimoto Lab . @ The Univ . of Tokyo Ruby , JavaScript , CSS and Android application Engineer

Slide 3

Slide 3 text

Today 's Goal なぜテストを書くかを知るどうやってテストを書くかを知る（簡単に！）テストへの抵抗をなくす 2016/12/10 3

Slide 4

Slide 4 text

What is "Testing " ? 2016/12/10 4

Slide 5

Slide 5 text

DEMO はじめてのテスト！一緒に書いてみよう！ $ g i t c l o n e https :/ /github .com /M e n t o r s S c h o o l / t e s t i n g s - for - b e g i n n e r s $ c d t e s t i n g s - for - b e g i n n e r s $ b u n d l e i n s t a l l 2016/12/10 5

Slide 6

Slide 6 text

ここで扱う「テスト」とは Developer Test Customer Test QA Test 2016/12/10 6

Slide 7

Slide 7 text

Developer Testing (1/2) Developer Testing は，開発者が開発者のために，自分自身のために，もしくはチームメンバーのために行うテストです。 via 第3 回 ... 和田卓人の “ テスト駆動開発 ” 講座（強調引用者） 2016/12/10 7

Slide 8

Slide 8 text

Developer Testing (2/2) たとえば，自分が書いたコードは自分でテストします。そして，テストを書くことで，フィードバックを得ることができます。「次はこうしなきゃいけないはずだ」「こういうコードのほうがいいんじゃないか」―― テストがもたらしてくれる情報をもとにコードをより良くしていこうというのが，テスト駆動開発におけるテスト，つまり Developer Testing の役割です。 via 第3 回 ... 和田卓人の “ テスト駆動開発 ” 講座（強調引用者） 2016/12/10 8

Slide 9

Slide 9 text

Why should we do testing ? 2016/12/10 9

Slide 10

Slide 10 text

2016/12/10 10

Slide 11

Slide 11 text

テストを書くメリットテストが揃っていれば、機能停止に陥るような回帰バグ (Regression Bug : 以前のバグが再発したり機能の追加/ 変更に副作用が生じたりすること) を防止できる。テストが揃っていれば、コードを安全にリファクタリング ( 機能を変更せずにコードを改善すること) できる。テストコードは、アプリケーションコードから見ればクライアントとして動作するので、アプリケーションの設計やシステムの他の部分とのインターフェイスを決めるときにも役に立つ。 via 結局テストはいつ行えばよいのか - Ruby on Rails T utorial （強調筆者） 2016/12/10 11

Slide 12

Slide 12 text

How should we do testing ? 2016/12/10 12

Slide 13

Slide 13 text

TDD : Test -Driven Development TDD とはテストファーストによる追加・変更と、リファクタリングによる設計改善の2 つの活動を超短期で繰り返して開発を進めていく手法です。 via いまさら聞けない TDD/BDD 超入門（1）：テスト駆動開発／振る舞い駆動開発を始めるための基礎知識 ( 1/ 3) - ＠IT 2016/12/10 13

Slide 14

Slide 14 text

TDD のサイクル 1. 次の目標を考える 2. その目標を示すテストを書く 3. そのテストを実行して失敗させる（Red [Fail ]） 4. 目的のコードを書く 5. 2 で書いたテストを成功させる（Green [Pass ]） 6. テストが通るままでリファクタリングを行う（Refactor ） 7. 1∼6 を繰り返す via TDD のこころ @ OSH 2014（ [ ] 内引用者） 2016/12/10 14

Slide 15

Slide 15 text

Demo 2016/12/10 15

Slide 16

Slide 16 text

via TDD のこころ @ OSH 2014 2016/12/10 16

Slide 17

Slide 17 text

TDD Cycle http ://www .planetgeek .ch/wp-content/uploads/ 2012/ 06/A TDD-cycle .png 2016/12/10 17

Slide 18

Slide 18 text

TDD や Developer Testing にソフトウェア工学的なメリットはいろいろあるけれど、最大の理由は工学的なものではない。最大の理由は心理的なもの即座にフィードバックを得るため書いたコードに自信を持つためこれから書くコードに自信を持つため via TDD のこころ @ OSH 2014 2016/12/10 18

Slide 19

Slide 19 text

TDD を体験してみよう！ 2016/12/10 19

Slide 20

Slide 20 text

ex . 1: 閏年？数値を1 つ引数に取る l e a p _ y e a r ? 関数引数の年（西暦）が閏年なら t r u e ，それ以外だと f a l s e を返す 2016/12/10 20

Slide 21

Slide 21 text

テストを書く上で意識すること 2016/12/10 21

Slide 22

Slide 22 text

漏れのないテスト？ White -box testing Black -box testing 2016/12/10 22

Slide 23

Slide 23 text

White -box testing テスト対象の構造に着目してテストケースを作るカバレッジ（網羅率）: どれだけの処理経路を網羅したか命令網羅: 命令を網羅したか分岐網羅: 分岐条件の判定結果を網羅したか条件網羅: 分岐ルートを網羅したか TDD 的？ 2016/12/10 23

Slide 24

Slide 24 text

Black -box testing テスト対象の仕様に着目してテストケースを作るどんな入力/ 出力があるかどんなデータが保存されるかどんな計算を行うか etc . 仕様の分析同値分割境界値分析デシジョンテーブル（説明は割愛） etc . 2016/12/10 24

Slide 25

Slide 25 text

同値分割入力値をグループに分けて，その代表値でテストケースを作る e .g . 月と日を引数にとる関数月のグループ: 1 未満，1 以上12 以下，12 超日のグループ: 1 未満，1 以上31 以下，31 超 2016/12/10 25

Slide 26

Slide 26 text

境界値分析同値クラスの境界はエラーが起きやすいので，そこをテストする e .g . お酒飲めますか？ 19 歳: 飲めない, 20 歳: 飲める r e t u r n a g e > 2 0 って書いちゃってて20 歳なのに飲めないパターンを防ぐ 2016/12/10 26

Slide 27

Slide 27 text

実際にテストを書いてみよう！ 2016/12/10 27

Slide 28

Slide 28 text

ex . 2: FizzBuzz 数値を1 つ引数に取る f i z z b u z z 関数引数が3 の倍数なら f i z z ，5 の倍数なら b u z z ，3 と5 の公倍数なら f i z z b u z z という文字列を返す上記のいずれにも該当しない場合は数値をそのまま返却する 2016/12/10 28

Slide 29

Slide 29 text

ex . 3: そのクレジットカード番号，あってる？カード番号（文字列）を受け取り，正しいかどうかを返す v a l i d _ c a r d ? 関数を実装する Luhn アルゴリズム 1. 一の位から数えて奇数番目の場合はそのまま、偶数番目の場合は数を2 倍する 2. 2 倍にした偶数番目の数が10 以上の場合は、その各桁を足して1 桁にする例) 18 の場合は 1 + 8 = 9 とする 3. 得られた桁の数を全部足す 4. 10 で割り切れれば正当な番号 via クレジットカード番号の入力誤り確認について - mo-fu note 2016/12/10 29

Slide 30

Slide 30 text

ex . 4: 定番カウントアプリ C o u n t e r クラスを作る初期値は 0 # i n c r e m e n t でカウントアップ # c l e a r で0 に初期化 # c o u n t で現在の値を取得 2016/12/10 30

Slide 31

Slide 31 text

実プロダクトにおけるテスト 2016/12/10 31

Slide 32

Slide 32 text

Testing levels Unit testing 関数・メソッドなど小さい単位でのテスト Integration testing 複数のモジュールが関係するテスト System testing システムを通してのテスト 2016/12/10 32

Slide 33

Slide 33 text

Testing Pyramid via Google T esting Blog : Just Say No to More End-to-End T ests 2016/12/10 33

Slide 34

Slide 34 text

e .g . TodoMVC シンプルな Todo 管理アプリどんなテストを書いていく？ 2016/12/10 34

Slide 35

Slide 35 text

Small testings 単機能/ モジュールが責任範囲よくある機能に対する不具合、エラーケースに対するテストなどがここ mock や stub を使い、早く回すことを重視する開発の中に組み込んでいく via 続・テストの種類に関して振り返ってみた、Google の S/M/L もね – 徒然なるままに 2016/12/10 35

Slide 36

Slide 36 text

e .g . Small testings for TodoMVC 「タスクを作成する」関数新規タスクを DB に保存外部 API に新タスクを通知 etc . Use mocks for external dependencies like DB , Web API call , etc . Test targets include "bussiness logic ", etc . Unit testings はだいたい Small testings 2016/12/10 36

Slide 37

Slide 37 text

Medium testings 2 個以上の相互に影響のある機能をテストする時の区分それぞれの機能のつながりに対してテストすることに焦点を当てる開発の中に組み込んでいく via 続・テストの種類に関して振り返ってみた、Google の S/M/L もね – 徒然なるままに Integration testings はだいたい Medium testings 2016/12/10 37

Slide 38

Slide 38 text

e .g . Medium testings for TodoMVC チェックボックスが押されたらタスクを完了状態にする関数が呼ばれる編集ボタンが押されたらタスク名変更フォームが開く etc . Use mocks for dependencies 「タスクを完了状態にする関数」が mock だと楽 Test targets include "ui logic ", "view state ", etc . 2016/12/10 38

Slide 39

Slide 39 text

Large testings E 2E とよく呼ばれるように、システム全体で目的を達成するかなどを確認するための区分すべてが自動化できるわけではなく、xxx 性試験のような、アジャイル4 象限では第2, 3, 4 に区分されるような領域の試験が主テスト対象の規模も大きくなり、テストの実施に関しても時間がかかるようになる。 via 続・テストの種類に関して振り返ってみた、Google の S/M/L もね – 徒然なるままに ※ E 2E （End -to -end ）: 雑に言うと「最初から終わりまで」 System testings , E 2E testings , Feature testings と呼ばれるものは Large testings と言えるかも 2016/12/10 39

Slide 40

Slide 40 text

e .g . Large testings for TodoMVC チェックボックスが押されたらタスクを完了状態にする関数が呼ばれタスクが完了済みのリストに移動し DB に変更が保存されている実際のユーザの操作の流れ（シナリオ）をなぞるイメージコンポーネントも mock じゃなく本物を利用（ほんとに外部とのやり取りは別） 2016/12/10 40

Slide 41

Slide 41 text

A set of data -driven naming conventions for tests via Google T esting Blog : T est Sizes 2016/12/10 41

Slide 42

Slide 42 text

Test double 「本物のふりをするニセモノのプログラム」 via 使える RSpec 入門・その3「ゼロからわかるモック（mock ）を使ったテストの書き方」 - Qiita Stub 関数の返り値を予め設定しておき，振る舞いを変更する Mock 関数の実行回数・引数の期待値を設定しておく Spy 関数の呼び出され方を記録する 2016/12/10 42

Slide 43

Slide 43 text

xUnit 形式と Spec 形式 2016/12/10 43

Slide 44

Slide 44 text

xUnit class CalculatorTest < Minitest ::Test def setup @ c a l c u l a t o r = C a l c u l a t o r . n e w end def test _ 足し算ができる a s s e r t _ e q u a l ( @ c a l c u l a t o r . a d d ( 1, 3) , 4) end # snip . end JUnit (Java ), XCTest (XCode ), minitest (Ruby ), etc . 2016/12/10 44

Slide 45

Slide 45 text

Spec d e s c r i b e C a l c u l a t o r do d e s c r i b e "#add " do i t " 足し算ができる" do e x p e c t ( a d d ( 1, 3) ) . t o e q 4 end end # snip . end Spock (Groovy ), Quick (Swi ), RSpec (Ruby ), etc . ※ minitest は xUnit ・Spec いずれでも書ける 2016/12/10 45

Slide 46

Slide 46 text

余談 2016/12/10 46

Slide 47

Slide 47 text

「師匠やメンターを見つければエネルギーを節約できる」自分の師匠やメンターを見つけることは、生きる上ですごい重要な事だと思っています。生きる上で、自分で考える事、決断することはすごく重要なことです。ですが、同時にすごくエネルギーを使うことでもあります。そんな時、自分よりも一歩先にいる人生の先輩を、師匠やメンターとして観察することで、何かを考えるときや決断する時のエネルギーを減らすことができます。こうして、エネルギーを節約した分、また別のことに向ければ将来的にはそのメンターよりも上に行けると僕は考えています。 via 中高生のうちに知れると楽だったかもしれないエンジニア的な考え方 - Qiita （強調引用者） 2016/12/10 47

Slide 48

Slide 48 text

「自分の師匠を見つけたら、勝手に弟子入りすればいい」僕はこれまで、１年間や半年などの期間で新しい師匠となる人を見つけては、その師匠を見てその期間に学ぶことを考えてきました。ですが、今まで１度として弟子入りをさせてくださいと言ったことはありません。今の世の中、SNS やブログなど、色んな発言の場があり、直接話さなくても多くの考えを知ることができます。何処かに通ったりする必要はありません。ただ、自分の師匠にしたい人を見つけたら、図々しく SNS やブログをフォローして、勉強会などでたまに会える機会を作れれば、その時点で弟子入り完了です。 via 中高生のうちに知れると楽だったかもしれないエンジニア的な考え方 - Qiita 2016/12/10 48

Slide 49

Slide 49 text

最初はかなりハードルが高いかもしれない 2016/12/10 49

Slide 50

Slide 50 text

まずはお手本・師匠を見つけて真似するところから！ 2016/12/10 50

Slide 51

Slide 51 text

新人は、先輩が描いた動きのパターンを掴んで真似する。自分なりの表現っていうのはそれから。パターン…。学ぶっていうのは、真似ぶっていうじゃん？みんな最初は誰かの真似。おんなじおんなじ。 via ムサニ看板アニメーター井口祐未の魅力 | TRIAL DANCE 2016/12/10 51

Slide 52

Slide 52 text

Enjoy so ware testing @izumin 5210 2016/12/10 52

Slide 53

Slide 53 text

References 2016/12/10 53

Slide 54

Slide 54 text

基礎知識ゼロから学ぶソフトウェアテスト【改訂版】関連: 『知識ゼロから学ぶソフトウェアテスト』読んだ - ✘╹◡╹✘ 第3 回「テスト」という言葉について ── Developer Testing ，Customer Testing ，QA Testing ：［動画で解説］和田卓人の“ テスト駆動開発” 講座｜gihyo .jp … 技術評論社 TDD TDD のこころ @ OSH 2014 TDD を学ぶべき10 の理由 #TddAdventJp - やさしいデスマーチいまさら聞けない TDD /BDD 超入門（1）：テスト駆動開発／振る舞い駆動開発を始めるための基礎知識 (1/3) - ＠IT 2016/12/10 54

Slide 55

Slide 55 text

テストの区分について Google Testing Blog : Test Sizes Google Testing Blog : Just Say No to More End -to -End Tests テストの種類に関して振り返ってみた and Web /Mobile アプリ業界の品質管理とは？ – 徒然なるままに続・テストの種類に関して振り返ってみた、Google の S /M /L もね – 徒然なるままにその他 Testing approach in android // Speaker Deck 使える RSpec 入門・その3「ゼロからわかるモック（mock ）を使ったテストの書き方」 - Qiita 組織にテストを書く文化を根付かせる戦略と戦術中高生のうちに知れると楽だったかもしれないエンジニア的な考え方 - Qiita ムサニ看板アニメーター井口祐未の魅力 | TRIAL DANCE 2016/12/10 55

Slide 56

Slide 56 text

Next step Ruby / Ruby on Rails なひと Ruby on Rails チュートリアル：実例を使って Rails を学ぼう初学者がテストも含め全部やろうとするのはかなりしんどい最初はテストと難しいのは飛ばして，2 周目以降がんばるのが吉 Everyday Rails … by Aaron Sumner et al . [Leanpub PDF /iPad /Kindle ] RSpec の入門とその一歩先へ～RSpec 3 バージョン～ - Qiita Android なひと Testing approach in android // Speaker Deck JUnit 実践入門 ~ 体系的に学ぶユニットテストの技法 (WEB +DB PRESS plus ) googlesamples /android -testing : A collection of samples demonstrating di ﬀerent frameworks and techniques for automated testing JS なひとここに書くには余白が足りない（困ったら気軽に聞いてください）その他のひとがんばって（師匠にはなれないけど相談にはのります） 2016/12/10 56