![テスト自动化
必要なもの
? CIを支援するツール
オンプレの場合：
Jenkins一択
※弊社標準もJenkins
クラウドサービスの場合：
選択肢は色々あるけど、プライベートリポジトリは大体有料
例外として、werckerは無料で作り放題(多分今だけだけど)
でも、Java使えない
CI何ぞやは、以下を読んでください。判らないことは聞いてください
[顿别惫翱辫蝉を支える技术勉强会(颁滨编)]
http://www.slideshare.net/sh-ogawa/dev-opsci](https://image.slidesharecdn.com/random-170216003419/85/-30-320.jpg)
![テスト自动化
ソースはこんな感じで、Groovyで書きます
node {
stage('update') {
git([url: 'https://github.com/sh-ogawa/auto-test-
demo.git', branch: 'sonar'])
}
stage('test') {
bat 'mvn clean jacoco:prepare-agent test
jacoco:report -e | echo "ignore failure"'
}
stage('analyze') {
bat 'mvn sonar:sonar -e'
}
}
ソースの更新
テストコードの
実行＆カバレッジ取得
テスト結果の解析](https://image.slidesharecdn.com/random-170216003419/85/-34-320.jpg)
More Related Content
What's hot (20)
Viewers also liked (19)
![[db tech showcase Tokyo 2014] B25: [In-Memory DB: SAP HANA] 障害?災害対策のメカニズム by...](https://cdn.slidesharecdn.com/ss_thumbnails/dbtstokyo2014b25sapin-memorydbsaphana-141119235609-conversion-gate02-thumbnail.jpg?width=560&fit=bounds)
![[C33] 24時間365日「本当に」止まらないデータベースシステムの導入 ～AlwaysOn＋Qシステムで完全無停止運用～ by Nobuyuki Sa...](https://cdn.slidesharecdn.com/ss_thumbnails/c33sqlserversasaki-131128193643-phpapp01-thumbnail.jpg?width=560&fit=bounds)
Similar to テストコード入门 (17)
More from 小川 昌吾 (17)
テストコード入门
- 2. 目次 ? はじめに ? テストコードとは ? テストコードのメリット、デメリット ? テストコードとの付き合い方 ? テストコードの书き方 ? テスト自动化 ? デモ ? レガシーシステムとテストコード
- 5. はじめに 私は最初、以下のように思いました。 ? そもそも、どうやって書くの？ ? テストコードのテストもするの？ それって２度手間では??? ? つまり、テストコードを书くと何が嬉しいの？
- 7. はじめに ちなみに
- 9. テストコードとは
- 10. テストコードとは ? 書いたコードが、開発者目線で思ったとおりに 動いているか検査する ? つまり、機能仕様を検査するわけではない ? 书いたコードの仕様を表す
- 11. テストコードとは 書いたプログラムについて、 そのロジックが想定通りの動きをしているか 確認するためのプログラムです。 以下のようなメソッドがあった場合、 public int add(int x, int y) { return x + y ;} addメソッドに「xに1」、「yに2」を渡したら、 戻り値が「3」になっていれば合格！ ということを、コードベースで確認します。
- 14. テストコードのメリット、デメリット メリット ? 中のロジックが変わらなければ、結果は同じに なる（ようにプログラムを書く） ? 逆に結果が変われば、何か内部的に変わったこ とを気付ける ? 人が実行して目で確認するよりも、 圧倒的に早く終わって、何よりも正確である リファクタリング しやすくなる
- 15. テストコードのメリット、デメリット メリット(応用編) ? 特定の条件で起こる不具合について、テスト コード上で再現させれば、何度でも瞬時に現象 を確認できる ? 不具合を対応したら、テストが成功になるため、 実装者レベルでの確認はスグに終わる ? 他人が作った機能であっても、テストコードが あれば、テストコードを実行することで、どん な機能かが概ね判る
- 18. テストコードのメリット、デメリット テストコードは、 以下のようなプロジェクトには向きません ? クイック案件 ? 作り切の案件 逆に、以下のようなプロジェクトでは 積極的に採用したいです ? 細かい仕様がよく変わる ? 開発終了後に、保守することが決まっている ? 人の出入りが、結構ある
- 19. テストコードとの付き合い方
- 20. テストコードとの付き合い方 テストコード書くぞ！！ と決めたプロジェクトで失敗する事例(個人編) ? 量産されるコピペのテストコード ? プロダクトコードのテスタビリティが低い (端的に云うと、コーディングセンス×) ? １つのテストコードに複数パターンを混ぜ込む ? テストコードに実行順序を持たせる テストコードは、プロダクトコードと同じように、 しっかりと設計して書かないと死にます
- 21. テストコードとの付き合い方 テストコード書くぞ！！ と決めたプロジェクトで失敗する事例(組織編) ? C0カバレッジ100%を目指す ? テストコード書けば工数が浮くという勘違い ? テストコードを書けば品質が担保できるという 勘違い ? テストコードのメンテナンスをしない ? なんでもかんでもテストコードを書かせる ? 性能試験などを書いてしまう こういうことをされると、 開発者が死にます
- 22. テストコードとの付き合い方 テストコードとの上手な付き合い方(個人編) ? 共通的に使うものは、テストコード共通みたい な形で、周りに提供する ? テストコードをレビューする、してもらう ? テスト可能なプロダクトコードを書く ?メソッドの戻り値voidは、本来おかしい テストしやすいプロダクトコードを上手く書く ということは、関数型プログラミングを学んでみると 個人的には良いと思います。
- 23. テストコードとの付き合い方 テストコードとの上手な付き合い方(組織編) ? カバレッジは85%程度を目指させ、カバレッジ の変化に着目するようにする ? テストコードはコストがかかることを認識する ? 新規開発では、テストコードだけに頼らず、打 鍵確認も行う(正常系だけでも良い) ? テスト自动化して、テストが失敗したら通知す る仕組みを構築する ? テストコードを書くのに、十分な時間を取れな い場合は、対象を重要機能のみに絞る ? 性能試験は、別フォルダに実装して行う ガチガチにやる必要はない
- 24. テストコードの书き方
- 25. テストコードの书き方 ? テスト用のライブラリを必ず使う ? テスティングフレームワークを使って、 カバレッジを取得する ? モックを上手く利用する ? テストコードの実行は一瞬で終わる構成にする
- 26. テストコードの书き方 //プロダクトコード public class Calculation { /** 加法を行う */ public static int add(int x, int y) { return x + y; } /** 減法を行う */ public static int sub(int x, int y) { return x - y; } /** 乗法を行う */ public static int multi(int x, int y) { return x * y; } /** 除法を行う */ protected static int div(int x, int y) { if(y == 0) throw new IllegalArgumentException("Please pass a non-zero value to y."); return x / y; } }
- 27. テストコードの书き方 //テストコード public class CalculationTest { //例外を検知する @Rule public ExpectedException expect = ExpectedException.none(); @Test public void 加法の確認(){ assertEquals(3, Calculation.add(1, 2)); } @Test public void 減法の確認(){ assertEquals(4, Calculation.sub(6, 2)); } @Test public void 乗法の確認(){ assertEquals(12, Calculation.multi(6, 2)); } @Test public void 徐法の確認(){ assertEquals(2, Calculation.div(8, 4)); } @Test public void 徐法でゼロ除算させようとした場合に例外が発生することの確認(){ //デバッグすれば判るが、Ruleは毎回インスタンスを作り直すため、変更したら、変更しっぱなしにしておいて問題ない expect.expect(IllegalArgumentException.class); expect.expectMessage("Please pass a non-zero value to y."); assertEquals(2, Calculation.div(8, 0)); } } かなり端折ってますが、 ?メソッド名が項目になる(日本語OK) ?try-catchしなくても、 例外とそのメッセージの検査が可能 ?protectedまでは小細工しないで検査可能
- 28. テスト自动化
- 34. テスト自动化 ソースはこんな感じで、Groovyで書きます node { stage('update') { git([url: 'https://github.com/sh-ogawa/auto-test- demo.git', branch: 'sonar']) } stage('test') { bat 'mvn clean jacoco:prepare-agent test jacoco:report -e | echo "ignore failure"' } stage('analyze') { bat 'mvn sonar:sonar -e' } } ソースの更新 テストコードの 実行＆カバレッジ取得 テスト結果の解析
- 35. テスト自动化 余談ですが、Pipelineスクリプトを書く理由は、 ? 画面からCIで回すシナリオを変えた場合に、何 を変えられたのか判らない ? GUIベースは便利だが、職人技になりがち ? シナリオをソースで残しておけば、何を変更さ れたか判るし、ソースを見れば何しているか判 る ? Gitのホスティングサービス(GitBucketとか GitHub)を使っていればP-Rでレビューして、 OK -> マージという戦略が取れるため、属人化 しづらい
- 36. デモ
- 40. レガシーシステムとテストコード
- 42. レガシーシステムとテストコード 仕様化テストの書き方 ? テストコードから対象のメソッドを呼ぶ インプットは実体に合わせるのが良い （実際の画面などを動かして、 入っているObjectを保存するとかいう 荒業を使ってもOK） ? 戻り値や、IN/OUT兼用パラメータに何が入っ ているかを見ながら、assertを書けば良い ? カバレッジは上がらないはずなので、 半日～１日で上げられるところまでを対応して、 見切りをつける(これやらないと泥沼化します)
- 43. レガシーシステムとテストコード このようにして仕様化テストを作っておくことで、 将来、以下のようなイベントが発生した場合、 楽になります。 ? システム老朽化によるリプレース ? フレームワークを載せ替えたい ? 言語のバージョンを上げたい ? リファクタリングして、ソースを綺麗にしたい etc..
- 44. 质疑応答
- 45. ご静聴ありがとうございました