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
テストコードってすごい!
Search
Sudo Mayu
November 18, 2023
Programming
0
41
テストコードってすごい!
2023.11.18 JavaDoでしょう#23
Sudo Mayu
November 18, 2023
Tweet
Share
More Decks by Sudo Mayu
See All by Sudo Mayu
大学×環境構築
sudom
0
26
大学生活から見えたラフなアジャイルの形
sudom
0
31
Other Decks in Programming
See All in Programming
今年もTECHSCOREブログを書き続けます!
hiraoku101
0
120
どんと来い、データベース信頼性エンジニアリング / Introduction to DBRE
nnaka2992
1
330
「効かない!」依存性注入(DI)を活用したAPI Platformのエラーハンドリング奮闘記
mkmk884
0
180
Takumiから考えるSecurity_Maturity_Model.pdf
gessy0129
1
160
DevinとClaude Code、SREの現場で使い倒してみた件
karia
1
1.1k
Rで始めるML・LLM活用入門
wakamatsu_takumu
0
200
Kubernetesでセルフホストが簡単なNewSQLを求めて / Seeking a NewSQL Database That's Simple to Self-Host on Kubernetes
nnaka2992
0
180
生成 AI 時代のスナップショットテストってやつを見せてあげますよ(α版)
ojun9
0
300
Vuetify 3 → 4 何が変わった?差分と移行ポイント10分まとめ
koukimiura
0
190
SourceGeneratorのマーカー属性問題について
htkym
0
220
ポーリング処理廃止によるイベント駆動アーキテクチャへの移行
seitarof
3
1.3k
20260320登壇資料
pharct
0
120
Featured
See All Featured
Side Projects
sachag
455
43k
Building AI with AI
inesmontani
PRO
1
820
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
64
54k
The Curse of the Amulet
leimatthew05
1
10k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Speed Design
sergeychernyshev
33
1.6k
Build your cross-platform service in a week with App Engine
jlugia
234
18k
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
390
Code Reviewing Like a Champion
maltzj
528
40k
Chasing Engaging Ingredients in Design
codingconduct
0
150
The Illustrated Children's Guide to Kubernetes
chrisshort
51
52k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Transcript
テストコードってすごい! 11/18 JavaDo
自己紹介 須藤真由 公立千歳科学技術大学 情報システム工学科に通う4年生 山川研究室に所属 特技:ダンス 趣味:推し活
きっかけ
きっかけ 研究活動の一環で ・リファクタリングしたい ・コードの読みやすさを意識したい! →テスト駆動開発に着目
テスト駆動開発とは テストレッド ↓ テストグリーン ↓ リファクタリング 失敗予定でテストを書き、 コンパイルを通す 成功するように実装をつける 実装内で無駄・今後のトラブルの元に
なりそうなコードを書き換える
書き方
使ったもの ・intellij 学校で使ってるIDE ・Java ・JUnit Javaでの単体テスト用のフレームワーク
テストケースの命名 ユビキタス言語を使用 開発者・ステークホルダー、双方で使う言語 ・クライアントからのドキュメント ・読みやすさ 例えば ◯足し算ができる(✕a=1,b=1でc=2になるか)
None
すごいと思ったこと
システムの振る舞いが分かる これからシステムを管理する後任開発者の疑問 「このシステムは何をするの?」 「何を入力したらどんな出力が返ってくるの?」 実際に使う?前任開発者に聞く? コードを読む? →テストコードを読もう!
コード外のエラーにも気づける システムをサーバーに上げようとしたときの話 リファクタリングが完了してるバージョン フレームワークを最新版にアップデートしたバージョン →統合後テストが通らなくなった! フレームワーク最新版の仕様変更が原因
難しかったこと
どんなテストケースを用意するか システムの振る舞いを把握してないと書けない 振る舞いにも2種類 開発者目線とステークホルダー目線 開発者目線 a=1, b=1, c=a+b=2 ステークホルダー目線 1+1=2
他にも… ・間違ったテストコードを書いちゃった ・テストコードで網羅しきれていないところからのバグ
結論 もっと後輩にテストコードを広めたい