JUnit導入の成功と失敗.pdf

JUnit導入の成功と失敗

Transcript

1. JUnit導入の成功と失敗
   #Java騎士団 第一回円卓会議@2015/10/27
   @shimashima35
   

   View Slide

2. 自己紹介
   @shimashima35
   http://srad.jp/~shimashima/
   中小SI勤務(基本下請けなし)
   Java歴 14年くらい
   好きなもの maven, テスト, ソフトウェエ
   ア工学全般
   最近IoTで遊んでいます
   JaSST(ソフトウェアテストシンポジウム)
   Tokyo 実行委員
   JSTQB-FL取得 (New @2015/10/26)
   

   View Slide

3. 本日の内容
   JUnitによるUnitTest導入の成功事例と失敗事例の紹介。
   成功要因/失敗要因についての考察。
   時間があれば「JMeterによる疲れないリグレッションテスト」も……。
   

   View Slide

4. UnitTestとは
   今回の講演でのUnitTestはTDDのUnitTestではありません。
   自分は書いたプログラムが自分の意図通りに動くことを確認・保証
   するためのもの。
   一般的な品質保証の考えでの「単体テスト」です。
   

   View Slide

5. 成功事例 概要
   ❏ 金融系大規模案件 (300人月以上かな？)
   ❏ 最大プログラマだけで40名程度
   ❏ 2007年頃
   ❏ Java5+Spring 2.5+Hibernate3.2(Annotation)+Spring MVC
   ❏ まだSpring MVCもHibernate 3.2も事例がない
   ❏ 受注したベンダ中に複数の協力会社社員で構成
   ❏ 大半は特定の1社
   ❏ 自分も協力会社(Not 特定の1社)として入った一人
   

   View Slide

6. 成功事例 JUnit導入経緯と結果
   ❏ 金融系で高品質を求めた
   ❏ アーキテクトが主導した
   ❏ 最終的にお客様とコードカバレッジ100%でコミットした
   ❏ 厳密はgetter/setterなどは除外してよい
   ❏ それでも最終的には95%程度まで達成
   ❏ テストチームによる結合テスト中でも気軽にリファクタリング
   ❏ コードに対して責任を持つ
   

   View Slide

7. 成功事例 要因
   ❏ 初期段階からUnitTestを意識し設計
   ❏ レイヤーアーキテクチャ、DIなど
   ❏ アーキテクトの力量
   ❏ UnitTest用フレームワークを一人で作成
   ❏ アーキテクトによる適度なコードレビュー
   ❏ おしなべて高かったスキル
   ❏ プロジェクトとしてのコミットメント
   ❏ プロジェクト内の意識の高さ
   

   View Slide

8. 失敗事例 概要
   ❏ 広告サイト構築案件 (200人月程度？)
   ❏ 最大プログラマだけで60名程度
   ❏ 2009年頃
   ❏ Java6+Seasar2+S2JDBC+SASturts
   ❏ 自社で受注
   ❏ 協力会社多数参加
   

   View Slide

9. 失敗事例 JUnit導入経緯
   ❏ JUnit成功体験があった自分が参加
   ❏ アーキテクトも「できるだけUnitTestは書きたい」という思い
   ❏ マネジャー的には「どうでもよい」
   ❏ あった方がよい
   ❏ でも、それで進捗が遅れるのはなぁ…
   

   View Slide

10. 失敗事例 JUnit導入結果
    ❏ カバレッジ率なにそれ？
    ❏ UnitTestはほぼなし
    ❏ 皆があらゆるところを修正するのでテストメンテが事実上破た
    ん
    ❏ mvn -Dmaven.test.skip=true
    

    View Slide

11. 失敗事例 要因
    ❏ アーキテクトがテストにコミットできなかった
    ❏ マルチタスク
    ❏ マネジャーからの扱い(UnitTestはなくてもよい)
    ❏ スケジュールプレッシャー
    ❏ テストよりまず動くもの
    ❏ プログラマのアサインが画面単位
    

    View Slide

12. 失敗事例 アサインの問題
    1. アサインが画面単位
    2. 一人が全てのレイヤまたがって実装を行う
    3. 画面に近い部分は別としてService・Domain・Persist層を全
    員触る
    a. 共通化されない、Interfaceが契約的ではない、APIが壊れ
    る
    b. 全員が全レイヤーのテストの書き方を覚えなければならな
    い
    

    View Slide

13. 成功事例 アサインは？
    1. アサインがレイヤー単位
    2. 画面近く画面/機能単位でアサインされる
    3. Service層/Domain層/Persist層はごく少のアーキテクチーム
    が受け持つ
    a. 業務単位である程度分割されるので、業務単位でクラスの
    オーナーが決まる
    b. オーナーがそのクラスの責任者として実装およびテストを
    書く
    

    View Slide

14. まとめ
    

    View Slide

15. まとめ
    ❏ スケジュールプレッシャーは天敵
    ❏ マネジャーの支援があると導入しやすい
    ❏ 「テストのための設計・準備」は必要
    ❏ 意外なところでアサインの単位も重要
    

    View Slide

16. JMeterによる疲れないテスト
    

    View Slide

17. Selenium(WebDriver)あるある
    ❏ テストが壊れる
    ❏ メンテナンスコストが高い
    ❏ 時間がかかる
    

    View Slide

18. JMeterによる簡易テスト
    ❏ http(s)によるリクエストレベルでのテスト
    ❏ とりあえずhttpステータスコードのチェック
    ❏ 400番台、500番台は自動的にNG
    ❏ 200番台はOK
    ❏ 302などの自動リダイレク対応
    ❏ テストシナリオはキャプチャー＆リプレイをベースに修正
    

    View Slide

19. SeleniumとJMeter
    ❏ Seleniumのつかいどころ
    ❏ 画面の動きを見たい・確認したい場合
    ❏ Ajax
    ❏ レイアウト検証
    ❏ JMeterのつかいどころ
    ❏ Web画面からロジックまで含めて検証
    ❏ UIの細かい部分は意識しなくてよい場合
    ❏ 何を検証したいかによって使い分けましょう
    

    View Slide

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

    View Slide