Ninja Testing at Toteka03

Preview:

DESCRIPTION

とてか03 で発表した「忍者式テストをやってみた」の発表資料です。 - とてか03(http://d.hatena.ne.jp/tochigitestnokaigi/20141004) - The Model-View-Controller (MVC) Its Past and Present(http://heim.ifi.uio.no/~trygver/2003/javazone-jaoo/MVC_pattern.pdf) - ステートフルJavaScript(http://www.amazon.co.jp/dp/487311554X) - MVP: Model-View-Presenter The Taligent Programming Model for C++ and Java(http://www.wildcrest.com/Potel/Portfolio/mvp.pdf)

Citation preview

忍者式テストをやってみた

2014/10/04 中島 滋 株式会社ラグザイア

とてか03招待講演

自己紹介中島滋(@@lleeddssuunn)WWeebb系受託開発プログラマJJaavvaaSSccrriipptt、CC##

今日の献立

11.. 忍者式テストを超簡単に22.. 忍者式テストはレグレッション33.. 忍者式テストのTTeessttiinngg面44.. 忍者式テストを詳しく55.. 忍者式テストのうれしさ66.. まとめ

11..忍者式テストを超簡単に

毎日テストを実施する受け入�れ試験手で行う

ここでテスト項目を見せる

22..忍者式テストをレグレッションに使う

今日の話のお得ポイント

忍者式テストはレガシーコードと戦う時に

使えた

レガシーコードは存在する!

機能を追加したいリファクタリングしたい

レガシーコードの例22885544行JJaavvaaSSccrriipptt

スコープを意識していない大域変数

((アプリケーションに閉じてる))非モジュール(グループ)化エディタアプリケーション

(GGUUII)テストコードなし

ここで対象となるアプリケーションを見せる

レガシーコードと戦う基礎戦術

基礎戦術11!

仕様が明確な関数を取り出しテストコードを書く

分割されていないコードは仕様を理解して

取り出せる部分が小さい数〜数十行

!

99割がモンスターのまま残る110000〜11000000回やる?

機能を足したいからリファクタリングしたい

レガシーコードでは理解し難い部分が変更したい部分なことが多い

効果が出るまで時間がかかるのでやめました

基礎戦術22!

ソフトウェアを数個のモジュールに分割する

分割にテストコードは必要か

網羅したテストを書くには時間がかかる

テストコードを書かずにリファクタリング

!

スコープをわける大きな変更は

手で動作確認できる(まだ忍者式テストでない)

GGUUIIのモジュール分割の王道!

11.. コンポーネント分割22.. PPrreesseennttaattiioonn--DDoommaaiinn--SSeeppaarraattiioonn(プレゼンテーションとドメイン)33.. SSmmaallllttaallkk--8800 MMVVCC(モデル・ビュー・コントローラー)

33.. SSmmaallllttaallkk--8800 MMVVCCは「TThhee MMooddeell--VViieeww--CCoonnttrroolllleerr ((MMVVCC)) IIttss PPaasstt aanndd PPrreesseenntt」

が手引きになる

SSmmaallllttaallkk--8800 MMVVCCではCCoonnttrroolllleerrがでかい!

!

モデルの更新とビューの更新両方やる

!

44.. SSeeppaarraatteedd PPrreesseennttaattiioonnビューがOObbsseerrvveerrに

モデルが変わったら勝手に更新

44.. SSeeppaarraatteedd PPrreesseennttaattiioonnは「ステートフルJJaavvaaSSccrriipptt」が

手引きになる

OObbsseerrvveerr付きMMVVCCに分けてもCCoonnttrroolllleerrがでかい!

!

作ったオブジェクトを自動選択!

11..モデルつくる22..ビューに表示33..選択状態に更新

55.. MMooddeell VViieeww PPrreesseenntteerr!

選択状態のモデル化sseelleeccttiioonn

ビューはsseelleeccttiioonnも監視

「MMVVPP:: MMooddeell--VViieeww--PPrreesseenntteerr TThhee TTaalliiggeenntt PPrrooggrraammmmiinngg MMooddeell ffoorr CC++++ aanndd JJaavvaa 」を読んでもわからない!

!

このアプリケーションに上手くはまるの?

不安!

適用後のソースコードがイメージできない

!

手探りでの変更

変更中にアプリケーションを

壊したら早く知りたい

やっぱりテストハーネスが欲しい!

テストコードを書く?!

分割したいのはCCoonnttrroolllleerr

ユーザー入�力と密接!

PPhhaannttoommJJSS??SSeelleenniiuumm??

!

そうだ手でやろう!

忍者式テスト

AA44用紙に今までやった確認手順を書き出す

数件実行してみる

次の日にもやる赤ペンも入�れる

なんと言うことでしょう!!

そこには今まで見たこともないバグが

ありました

期待通り!

テストハーネスとして機能する(CChheecckkiinngg)

それ以上に!

未知のバグが見つかった((TTeessttiinngg))

!

引き継ぎ前のバグ引き継ぎ後に入�れいたバグ

いったん確認!

忍者式テストはレガシーコードと戦う一戦術

!

TTeessttiinnggの側面もある?

ここまで22.. 忍者式テストをレグレッションに使う

!

ここから33.. 忍者式テストのTTeessttiinngg面

忍者式テストでは新しいテストが見つかる

!

なぜだろう?

秋山 浩一さんの洞察元・富士ゼロックステストコンサルタント

@@aakkiiyyaammaa992244テスターは、いい加減なテストケースを元に、そこからちょっと外れた操作をしてバグを見つけていると思います。hhttttppss::////ttwwiitttteerr..ccoomm//aakkiiyyaammaa992244//

ssttaattuuss//550066225555440011553377338844444488

これだ!!

忍者式テストでもテストケースから

ちょっと外れた操作をした時バグを見つけている

どういうわけか紙に向�かって

テストケースを考える時には思いつかない

思いついてもテストケースを書くのが

面倒

バグを見つけた手順(CChheecckkiinngg)

!

有効なテストケースは残す

忍者式テストは毎日、人がやる

毎日、ちょっとずつ変わる!

TTeessttiinngg(未知の問題が見つかる)

44..忍者式テストを詳しく

準備11..新機能の確認テストを追加

!

テストを実行22..既存のテストを改�善

33..新しく発見したテストを追加44..要らなくなったテストを削除

11..その日追加した新機能のテストを追加

!

雑機能確認程度

正しい動作のメモ代わり

22..昨日までのテストを修正わかりやすく早く終わる手順に

!

文章の添削に一日置く感じ

33..新しく発見したテストを追加

新しいテストは一番上に追加実行頻度を高く

44..バグを発見できなくなったテストを止める

!

基準は感性「めんどくさいなー」多分合っているけど不安

気合い

疲れていると気合い不足

テストが減らない!

すごく疲れていると何でもめんどくさくなるテストが減らない

テストは健康な状態でやらなければならない

55.. 忍者式テストをやるとうれしいこと

最初に完璧なテストを書かなくてよい

!

フォーマットカバレッジ効率

最初のハードルは低い!

毎日やるとちゃんとバグが見つかる

テストを足してから一週間ぐらいは

新しいテストとバグが見つる!

ただし毎日やらないとバグが見つからない

毎日テストしないと恐い

大きなリファクタリングが終わっても(二ヶ月経過)やめていないのは

TTeessttiinnggの面が大きいから

まとめ

忍者式テストで!

テストコードが書けなくてもレガシーコードと戦える

!

未知のバグも発見できるテストにちょっと自信がもてる

忍者式テストをやろう!

書けるなら最初からテストコードを

書いてくれ

ご清聴ありがとうございました

Recommended