テストゼロからイチに進むための戦略と戦術
•
8 likes•4,712 views
JJUC-CCC - Japan Java Users Group Cross Communiy Conference - 2016 Spring 講演資料。 テスト、書いてますか？はい、我々は書いていませんでした。しかし今は違います。将棋の駒を動かすかのように一手ずつテストを書き進めるための戦術と戦略のようなものを、お話しできればと思います。このセッションは同じチームの同僚による昨年秋のセッション「JJUG-CCC 2015 Fall CD-2 Java8移行から始めた技術的負債との戦い」の続編のようなものです。
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to テストゼロからイチに進むための戦略と戦術
Similar to テストゼロからイチに進むための戦略と戦術 (20)
Recently uploaded
Recently uploaded (9)
テストゼロからイチに進むための戦略と戦術
- 3. 3 ● 渡辺 祐 ● （株）ビズリーチ ● ビズリーチ エンジニアブログ ○ http://tech.dcube.io ● Twitter: @nabedge ● https://github.com/nabedge ● http://www.slideshare.net/nabedge ● http://mixer2.org ● http://nabedge.mixer2.org
- 6. 6
- 7. 7
- 9. 9 綺麗な海をテストで 守ってくれる人を We are HIRING ! http://www.bizreach.co.jp/recruit/
- 11. タイトルはあのお方より拝借 11
- 12. ▸ 今日話さないこと ▹ TDD, テストファースト ▹ C0, C1, C2 ▹ カバレッジ50%超えたらその後どうする？ ▹ 例外処理のテストとか ▸ 話すこと ▹ 何を準備すべきか、そのコツ ▹ なにから始めるか ▹ その障害はなにか 12
- 13. 13
- 15. 業界によっても話は違う ▸ 受託開発 (SIer) ▸ 業務パッケージ開発 ▸ 組み込み系 ▸ Webサービス 15
- 16. 一手ずつ指すしかない 16 Yet Another 式年遷宮 ...
- 18. 18 1. 自分たちがいまどこにいて 2. あとどのくらいがんばれば 3. あのあたりに行けるかもね。 4. これをチーム全員が 見れるようにする
- 19. 19 SonarQube 一択
- 25. 25 ローカル開発環境の構築作業 1. git clone 2. vagrant up でOracleVBoxに仮想OSを起動し、 RDB, 検索エンジン等をインストール 3. DBFluteのreplace-schemaで テーブル構築＆初期データINSERT 4. バッチスクリプトで検索エンジンにデータ投入 5. Mavenプロジェクトとして IDE(Eclipse/IntelliJ)にインポート 6. ServerStarter.javaを起動
- 26. 26 Jenkins上でのmvn test 1. git clone 2. vagrant up で別EC2インスタンスを起動し RDB, 検索エンジン等をインストール 3. DBFluteのreplace-schemaで テーブル構築＆初期データINSERT 4. バッチスクリプトで検索エンジンにデータ投入 5. mvn jacoco-prepare-agent test sonar:sonar 6. vagrant destroy (インスタンスは使い捨て）
- 27. 27 ポイント 1. ローカル開発環境のデータ層を、 仮想OSもろともvagrant upの 一撃で作れるようにしてある。 a. 初期データ投入も自動スクリプトあり。 2. ならばそれをテスト自動実行の 環境(Jenkins)にも使えばいい。 a. 環境差分は仮想OSのIPアドレスくらい
- 28. 28 実際、さらに話が飛びますが
- 29. 29 テスト「だけ」が開発じゃない 1. 機能の追加、変更、廃止 2. バグの対応 3. インフラ、フレームワークの メンテ 4. セキュリティ的な対応 5. 新人育成、新メンバーの 立ち上がりサポート 全体を テストで 支える
- 31. 31 将来構想（の一部） ▸ ローカル開発環境 ▸ 結合テスト環境 ▸ 社内β環境 ▸ 本番環境 すべて Docker コンテナ化 インフラ用ansibleをローカル環境でも使えたら!?
- 32. “ 32 詳しくは 「12−factor App」 「開発 本番 一致」 でググる。
- 33. 33 話をテストに戻します。
- 34. 34 テストのカバレッジってなんぞ？ 緑=テストが通過している 赤=テストが通過してない 黄色=テストが一部だけ通過 このクラスに対する カバレッジは67% ➗ コード全体 テストが 通過した箇所
- 35. 35 本体コード 116 KStep テストコード 91,577 KStep 本体に対して 787倍のテスト もちろんカバレッジ100%
- 36. 36 オライリー本「実践JUnit」より ▸ 14.4.1 望ましいカバレッジの値 ▹ 「EclEmmaの開発者も含むほとんどの人々は、 70%以下のカバレッジは不十分だと...」 ▸ 14.4.3 カバレッジの意義 ▹ カバレッジの値は単体ではほとんど意味がありま せん。重要なのは、値の増減の傾向です。カバ レッジの値を落とすことなく、徐々に上昇させてゆ くことを目指しましょう。
- 39. 39 hamcrestのmatcherも悪くは ないんだけど assertThat("hoge", is("hoge")); assertThat("hoge", is(not("HOGE"))); assertThat("not null", is(notNullValue()));
- 40. 40 AssertJが便利! import static org.assertj.core.api.Assertions.*; assertThat("hoge").isEqualTo("hoge"); assertThat("hoge").startsWith("h").endswith("e") assertThat("not null").isNotNull();
- 41. 41 IDEをメンテしよう ▸ EclEmma ▹ 手元のeclipseでカバレッジを見る ▸ Quick JUnit ▹ テストクラスとテスト対象クラスを行き来する ▹ ただしEclipse-luna/marsでは一部メニューが 動かない！ ▸ IntelliJ IDEAなら上の機能はだいたいデフォルト搭載。
- 43. 43 レガシーコード改善ガイド 16.4 「使用していないコードを 削除する」 ▸ 邪魔以外の何者でもない。 ▸ 古いコードが見たければ VCSから掘り起こせ。
- 44. 44
- 45. 45 ▸ さすがに1.7万行消したら カバレッジ少し上昇。 ▹ 後日加筆の補足：不要に残ったコメントアウトではない（その悪習は 初めから無い）。うっかりコミットしてしまっていた不要な logファイルで もない。本当に丸ごと未使用のビジネスロジッククラス等だった。
- 47. 47 理想: レガシーコード改善ガイド 2.1 「単体テストとは」 次にあてはまるものは単体テストではない。 1. データベースとやり取りする 2. （以降 割愛） 上記に該当するテストが悪いというわけではない。 … … （以下、テストが遅くなりがちだからダメという 話）
- 48. 48 開発現場の現実 ▸ これでは ↓ お話にならない ▹ 「手順書通りにソースをIDEに インポートしてアプリを起動したら、データ がほとんど入ってないせいで、画面がま ともに動きません！」 ▸ すべての機能を正確に動かせる 初期データを一撃でINSERTする仕組み は（自動テスト云々に関わらず）必須
- 49. 49 ▸ DBFluteのreplace-schema機能を使う 1. テーブルを全DROP 2. CREATE TABLE … 3. *.xlsに用意したデータをINSERT (日時情報は相対指定可能） ▸ 他のツールでも代替可能 ▸ sql-maven-plugin ▸ dbunit-maven-plugin ▸ Gradle, 自作bashスクリプト
- 50. 50 正しいテストデータが常に存在する 前提でテストを書いてもよいことにする @Test public void test_foo() throws Exception { User user = userService.find(5L); Result result = fooService.doBar(user); assertThat(result)........ 会員番号5番のuserはこのテストに必 要なデータを全て持っている
- 51. 51 ただし基本は勉強したうえで 用法用量を守って。 @Test public void test_foo() throws Exception { User user = new User(); user.setHoge = ...//テストに必要な値をその都度書く Result result = fooService.doBar(user); assertThat(result)........
- 53. 53 そこそこ面倒 ▸ ローカルマシンにpostfixとdovecotを入れる ▸ 共有マシンにpostfixとdovecotを入れる ▸ 開発環境では、SMTPではなく *.eml形式でファイルに出力する 自作モッククラスに差し替える ▸ GreenMail, mock-javamail, subethaSMTP...などのライブラリを使う
- 54. 54 ● インストール ○ $ gem install mailcatcher ● 起動 ○ $ mailcatcher ● 1025番でSMTP待ち受け ● 1080番でブラウザでメール閲覧 ● portは起動引数で書き換え可
- 55. 55 メールの情報をjsonで返すAPI ▸ /messages … メッセージ一覧を取得 ▸ /messages/:id.json ▸ /messages/:id.html ▸ /messages/:id.plain ▸ /messages/:id.source
- 56. 56 mailcatcherをvagrantで自動構築 動作チェックと自動テストの両方で使う ▸ vagrant upで”gem install mailcatcher” ▸ アプリケーションの設定値を差し替え ▹ SMTPサーバのIPアドレスとport番号だけ ▸ 開発過程での目視での動作確認用途に使う。 ▸ テストコードではmailcatcherのAPIで 取得したjsonをアサートする。
- 58. 58 Seleniumご存知ですよね @Test public void test_トップページ() throws Exception { WebDriver drv = new FireFoxDriver(); WebElement element = drv.get(“http://localhost:8080/”); assertThat(element.findById(“title”).getText()) .contains(“Hello World”) }
- 60. 60 絶対防衛ラインの存在 ▸ ECサイト ▹ カートに入れる->入力,決済->注文完了メール ▸ ホテル予約サイト ▹ 予約ボタン -> 入力,決済 -> 予約完了メール ▸ 転職サイト ▹ 応募ボタン -> 入力 -> 応募がありましたメール
- 61. 61 1. 是非もなく継続的にやりたい結合テストを Seleniumで書く。 2. 通常のユニットテストと同じ運用で 継続的に実行できるようにする。 3. とにかく必ずやるというのなら、 ついでにカバレッジも取れるようにする。
- 62. 62 前提：アプリは組込Tomcatで起動 public class APStarter { public static start() { Tomcat tomcat = new Tomcat(); tomcat.start(); ... public static void main(String args[] argv) { start();
- 63. 63 @BeforeClass メソッド APStarter.start(); // 起動 @Test メソッド // WebDriverでアプリの画面にアクセス @AfterClass メソッド APStarter.close(); // 停止
- 64. JVM 64 テストクラス テスト対象 Seleniumでもカバレッジ測定 JaCoCo-Agent Jenkins用マシンのOS Vagrant仮想 OS 1. vagrant up 2. 初期データ投入 3. Xvfb起動 4. mvn prepare-agent test sonar:sonarHTTP start()
- 65. JVM 65 テストクラス テスト対象 普通のユニットテストのカバレッジ測定 JaCoCo-Agent Jenkins用マシンのOS Vagrant仮想 OS 1. vagrant up 2. 初期データ投入 3. - 4. mvn prepare-agent test sonar:sonar
- 70. 70 ログを追うにも ● 実際には200MByte前後。 ● log4j.properties / logback.xml を 長い間 整理していないツケ
- 71. 71 ▸ 手元では再現しない。 ▹ AWS(EC2)でしか発生しない。 ▸ たまにしか発生しない。 ▸ Jenkinsがオオカミ少年化するのが 嫌だからチャットへの投稿botを停止。 ▸ 忙しくてしばらく停止しっぱなし ▸ 本当にバグってテストが失敗してても 誰も気づいてない。
- 72. 72 巨大ログをよくよく目grepすると ==> default: Existing lock /var/run/yum.pid: another copy is running as pid 3744. ==> default: Another app is currently holding the yum lock; waiting for it to exit... ==> default: The other application is: yum ● テストではなくvagrant の段階 ! ● yum install hogehoge でコケている。 ● 他のyumが動いている？？
- 73. 73 vagrant up AMI起動 (vagrant-aws-plugin) yum update ... 他のOS起動シーケンス sshデーモン開始 vagrant provision yum install hogehoge yum lock 微妙に時間が かかることがある テスト実行ジョブスタート
- 74. 74 ▸ テスト用EC2インスタンスを使い捨て しているからこそ発生する事象。 ▸ つまらない原因でCIサーバでのテストが 事実上止まってしまうことはありうる。 ▸ わずらわしさに負けたらそこで 試合終了。
- 75. 75 八手目 教育、啓蒙
- 76. 76 ▸ 幸いなことに ▹ 否定的な感覚のメンバーは皆無 ▹ テスト書かないと気持ち悪いという者も。 ▸ いずれにせよスキルにバラつきはある。 ▹ テストを書き慣れることが必要
- 77. 77 テストを書くタイミングだけは 守ろう 1. バグ対応のときは必ずテストを書く 2. クラスの中の一部のメソッドを 修正または追加した場合は、 そのメソッドに対するテストだけでも書く。 3. そのために private -> protected に 変更するのはOK ※他にもいろいろあるけど上記はその一例です
- 78. 78 九手目 金の弾丸
- 79. 79 富豪テストを支える基本環境 Mac Book Pro 3GHz Core i7 16GB memory 250GB SSD Jet Brains All Products Pack
- 80. 80 まとめ ● 時間を確認
- 81. 81 1. テストが無いコードはレガシーコードだ！ 2. テストを書こう。 3. しかし現実の開発現場は、 それがすべてではない。
- 82. 82 1. 自分の手元の開発環境で、アプリの実行に必 要なミドルウェア群を 一撃でインストールする仕組み (not 手順書） 2. すべての機能を正確に動かせる 初期データを一撃でINSERTする仕組み テスト書くのとは無関係に必須
- 83. 83 ならばそれらの自動化ツールを テストの実行にも活かして手間を省く 1. vagrant/dockerでデータ層を作る 2. DBFluteのreplace-schemaで テストデータ投入 3. あるいは a. sql-maven-plugin b. dbunit-maven-plugin c. gradle関連でももちろんOK
- 84. 84 IDE(のplugin)依存は避ける 1. それJenkins上で動かせるの？ 2. QuickJUnitがEclipse luna以降では... 3. WTP, Sysdeo, RunJettyRunよりも 組み込みtomcatでアプリコード化
- 85. 85 道標はあるほうがいい ▸ なにを、どこまでがんばれば、 どうなりそうか？ ▹ ステップ数 ▹ テストカバレッジ ▹ テストの成功、失敗、スキップ ▹ 重複ステップ数 ▸ 上記すべての過去の値との比較
- 86. 86 便利ライブラリは積極的に導入 ▸ Javaライブラリ ▹ AssertJ ▹ “J”Mockito ▸ Javaライブラリ以外の方法もある ▹ mailcatcher
- 87. 87 言語やフレームワークは 最新ですか？ ▸ If文の分岐網羅を気にするよりも Java8 の Stream API で書き直して 見通しを良くする方が建設的。 ▸ Spring-testフレームワーク便利！ ▹ ただしspring4.2以上
- 88. 88 ゴミ掃除をしよう ▸ もう使われていないコードのテストを がんばって書く悪夢 ▸ Log4j.properties, pom.xml を メンテする。 ▹ 不要なログ、無駄な依存関係は トラブルシューティングの邪魔
- 89. 89 Seleniumは用法用量を守って ▸ 絶対防衛ラインで使う ▸ やり方次第でカバレッジも採れる ▸ テスト実行環境の自動構築を徹底すれば、 富豪テスティングなやり方も可能。 ▹ スポットインスタンス安っ！
- 90. 90 ▸ テストの原則は ▹ 繰り返し可能である ▹ 独立している ▸ これを↑実行環境レベルの自動化で 実現する方法「も」ある ▸ ただし実行スピードが犠牲に なりやすい。考えて使いわける。 基本は基本で知っておこう