Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
JUnit導入の成功と失敗.pdf
Search
SHIMANE, Yoshikazu
October 28, 2015
Technology
0
2.9k
JUnit導入の成功と失敗.pdf
JUnit導入の成功と失敗
SHIMANE, Yoshikazu
October 28, 2015
Tweet
Share
More Decks by SHIMANE, Yoshikazu
See All by SHIMANE, Yoshikazu
ソフトウェア開発温故知新 古典で紐解く、ソフトウェア開発の課題 / Software_Development:Learning_from_the_Past
shimashima35
0
48
入り口から考えるソフトウェアテストエンジニアのキャリア / Thinking_About_a_Software_Test Engineer's_Career_from_the_Starting_Point
shimashima35
0
1.6k
テスト技法を使ったテストケースの表現方法/How to express test cases using test techniques
shimashima35
0
1.3k
VSTePのテスト観点出しで失敗した事例についての紹介/Failure case of test viewpoint derivation
shimashima35
0
760
組織横断部門におけるバグ数可視化の全社導入の事例/Example_of_company-wide_bug_number_visualization in_cross-organizational_departments
shimashima35
1
380
JaSST Tokyo実行委員のお仕事/Job of JaSST executive committee
shimashima35
0
800
What is “Quality” ?
shimashima35
0
1k
品質"実質"無料キャンペーン始めます / Start_quality_real_free_campaign
shimashima35
2
5.7k
明日から始めるSelenideによるブラウザテスト 2018年版/ Browser_test_by_selenide_to_start_from_tomorrow_in_2018
shimashima35
1
880
Other Decks in Technology
See All in Technology
OpenTelemetry が拡げる Gemini CLI の可観測性
phaya72
2
930
MCP ✖️ Apps SDKを触ってみた
hisuzuya
0
110
[VPoE Global Summit] サービスレベル目標による信頼性への投資最適化
satos
0
190
OAuthからOIDCへ ― 認可の仕組みが認証に拡張されるまで
yamatai1212
0
140
フレームワークを意識させないワークショップづくり
keigosuda
0
230
物体検出モデルでシイタケの収穫時期を自動判定してみた。 #devio2025
lamaglama39
0
250
ローカルLLMとLINE Botの組み合わせ その2(EVO-X2でgpt-oss-120bを利用) / LINE DC Generative AI Meetup #7
you
PRO
0
130
AIとともに歩んでいくデザイナーの役割の変化
lycorptech_jp
PRO
0
670
OCIjp_Oracle AI World_Recap
shinpy
1
120
FinOps について (ちょっと) 本気出して考えてみた
skmkzyk
0
180
Introdução a Service Mesh usando o Istio
aeciopires
1
250
CoRL 2025 Survey
harukiabe
1
230
Featured
See All Featured
Principles of Awesome APIs and How to Build Them.
keavy
127
17k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.7k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
55
3k
Embracing the Ebb and Flow
colly
88
4.9k
The Cost Of JavaScript in 2023
addyosmani
55
9k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
190
55k
KATA
mclloyd
PRO
32
15k
Facilitating Awesome Meetings
lara
56
6.6k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
990
How to train your dragon (web standard)
notwaldorf
97
6.3k
Transcript
JUnit導入の成功と失敗 #Java騎士団 第一回円卓会議@2015/10/27 @shimashima35
自己紹介 @shimashima35 http://srad.jp/~shimashima/ 中小SI勤務(基本下請けなし) Java歴 14年くらい 好きなもの maven, テスト, ソフトウェエ
ア工学全般 最近IoTで遊んでいます JaSST(ソフトウェアテストシンポジウム) Tokyo 実行委員 JSTQB-FL取得 (New @2015/10/26)
本日の内容 JUnitによるUnitTest導入の成功事例と失敗事例の紹介。 成功要因/失敗要因についての考察。 時間があれば「JMeterによる疲れないリグレッションテスト」も……。
UnitTestとは 今回の講演でのUnitTestはTDDのUnitTestではありません。 自分は書いたプログラムが自分の意図通りに動くことを確認・保証 するためのもの。 一般的な品質保証の考えでの「単体テスト」です。
成功事例 概要 ❏ 金融系大規模案件 (300人月以上かな?) ❏ 最大プログラマだけで40名程度 ❏ 2007年頃 ❏
Java5+Spring 2.5+Hibernate3.2(Annotation)+Spring MVC ❏ まだSpring MVCもHibernate 3.2も事例がない ❏ 受注したベンダ中に複数の協力会社社員で構成 ❏ 大半は特定の1社 ❏ 自分も協力会社(Not 特定の1社)として入った一人
成功事例 JUnit導入経緯と結果 ❏ 金融系で高品質を求めた ❏ アーキテクトが主導した ❏ 最終的にお客様とコードカバレッジ100%でコミットした ❏ 厳密はgetter/setterなどは除外してよい
❏ それでも最終的には95%程度まで達成 ❏ テストチームによる結合テスト中でも気軽にリファクタリング ❏ コードに対して責任を持つ
成功事例 要因 ❏ 初期段階からUnitTestを意識し設計 ❏ レイヤーアーキテクチャ、DIなど ❏ アーキテクトの力量 ❏ UnitTest用フレームワークを一人で作成
❏ アーキテクトによる適度なコードレビュー ❏ おしなべて高かったスキル ❏ プロジェクトとしてのコミットメント ❏ プロジェクト内の意識の高さ
失敗事例 概要 ❏ 広告サイト構築案件 (200人月程度?) ❏ 最大プログラマだけで60名程度 ❏ 2009年頃 ❏
Java6+Seasar2+S2JDBC+SASturts ❏ 自社で受注 ❏ 協力会社多数参加
失敗事例 JUnit導入経緯 ❏ JUnit成功体験があった自分が参加 ❏ アーキテクトも「できるだけUnitTestは書きたい」という思い ❏ マネジャー的には「どうでもよい」 ❏ あった方がよい
❏ でも、それで進捗が遅れるのはなぁ…
失敗事例 JUnit導入結果 ❏ カバレッジ率なにそれ? ❏ UnitTestはほぼなし ❏ 皆があらゆるところを修正するのでテストメンテが事実上破た ん ❏
mvn -Dmaven.test.skip=true
失敗事例 要因 ❏ アーキテクトがテストにコミットできなかった ❏ マルチタスク ❏ マネジャーからの扱い(UnitTestはなくてもよい) ❏ スケジュールプレッシャー
❏ テストよりまず動くもの ❏ プログラマのアサインが画面単位
失敗事例 アサインの問題 1. アサインが画面単位 2. 一人が全てのレイヤまたがって実装を行う 3. 画面に近い部分は別としてService・Domain・Persist層を全 員触る a.
共通化されない、Interfaceが契約的ではない、APIが壊れ る b. 全員が全レイヤーのテストの書き方を覚えなければならな い
成功事例 アサインは? 1. アサインがレイヤー単位 2. 画面近く画面/機能単位でアサインされる 3. Service層/Domain層/Persist層はごく少のアーキテクチーム が受け持つ a.
業務単位である程度分割されるので、業務単位でクラスの オーナーが決まる b. オーナーがそのクラスの責任者として実装およびテストを 書く
まとめ
まとめ ❏ スケジュールプレッシャーは天敵 ❏ マネジャーの支援があると導入しやすい ❏ 「テストのための設計・準備」は必要 ❏ 意外なところでアサインの単位も重要
JMeterによる疲れないテスト
Selenium(WebDriver)あるある ❏ テストが壊れる ❏ メンテナンスコストが高い ❏ 時間がかかる
JMeterによる簡易テスト ❏ http(s)によるリクエストレベルでのテスト ❏ とりあえずhttpステータスコードのチェック ❏ 400番台、500番台は自動的にNG ❏ 200番台はOK ❏
302などの自動リダイレク対応 ❏ テストシナリオはキャプチャー&リプレイをベースに修正
SeleniumとJMeter ❏ Seleniumのつかいどころ ❏ 画面の動きを見たい・確認したい場合 ❏ Ajax ❏ レイアウト検証 ❏
JMeterのつかいどころ ❏ Web画面からロジックまで含めて検証 ❏ UIの細かい部分は意識しなくてよい場合 ❏ 何を検証したいかによって使い分けましょう
ご清聴ありがとうございました。