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
8yabusa
March 19, 2018
Programming
0
69
テストデータについて
AndroidTestNight#3の発表資料です
8yabusa
March 19, 2018
Tweet
Share
More Decks by 8yabusa
See All by 8yabusa
BLEアプリ設計パターン / ble_app_pattern
tomohikosato
10
3.1k
Bluetoothわかんねぇよなぁ!ハム太郎! / Bluetooth_hamutaro
tomohikosato
4
1.1k
効率よく勉強する(Androidアプリ開発編)
tomohikosato
1
270
いかにして問題を解くか
tomohikosato
0
210
Other Decks in Programming
See All in Programming
ゼロからの、レトロゲームエンジンの作り方
tokujiros
3
1.1k
ErdMap: Thinking about a map for Rails applications
makicamel
1
650
rails newと同時に型を書く
aki19035vc
5
710
Findy Team+ Awardを受賞したかった!ベストプラクティス応募内容をふりかえり、開発生産性向上もふりかえる / Findy Team Plus Award BestPractice and DPE Retrospective 2024
honyanya
0
140
Lookerは可視化だけじゃない。UIコンポーネントもあるんだ!
ymd65536
1
130
PHPとAPI Platformで作る本格的なWeb APIアプリケーション(入門編) / phpcon 2024 Intro to API Platform
ttskch
0
390
アクターシステムに頼らずEvent Sourcingする方法について
j5ik2o
6
700
カンファレンス動画鑑賞会のススメ / Osaka.swift #1
hironytic
0
170
Androidアプリの One Experience リリース
nein37
0
1.2k
オニオンアーキテクチャを使って、 Unityと.NETでコードを共有する
soi013
0
370
知られざるDMMデータエンジニアの生態 〜かつてツチノコと呼ばれし者〜
takaha4k
1
440
Package Traits
ikesyo
1
210
Featured
See All Featured
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
192
16k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.3k
Building Applications with DynamoDB
mza
93
6.2k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.2k
Producing Creativity
orderedlist
PRO
343
39k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.6k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
98
18k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Speed Design
sergeychernyshev
25
740
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
How to train your dragon (web standard)
notwaldorf
89
5.8k
Transcript
テストデータについて Tomohiko Sato
⾃⼰紹介 • Tomohiko Sato @8yabusa • Qrio.inc (2017年10⽉~) • テストは主に本で読んだ知識で実践
テストデータについて 具体例で考えよう
視聴回数、どんな⾵に表⽰されるか? • 万、億単位がある (例: 32回、 256 万回、3億回) • 3桁⽬にカンマがある (例:
1,353 回、3,245万回) 例: Youtube
ViewCount(58).show() // 58回 ViewCount(43453).show() // 4万回 実装したとする
ViewCount(58).show() // 58回 ViewCount(43453).show() // 4万回 テストどうしよう?
• テストは特定のケースで成功/失敗することしか⽰せない • Intが取りうる値の範囲 = 2^32通りのテストするのか? • じゃあどのケースでテストする? 完璧なテストなど存在しない
Q. そもそも何のためにテスト しているのか A1. テスト対象が仕様通りに動いて欲しいから A2. テスト対象がバグって欲しくないから
A1.テスト対象が仕様通りに 動いて欲しい • 仕様をグループ分け(同値分割)、グループに属する適当 な値を選びテスト • 億回、万回、回とグループ分けし、適当な値でテ スト • カンマあり、カンマとグループ分けし、適当な値
でテスト
A2. テスト対象がバグって欲しくな い • バグを引き起こしそうなテストデータを⽤意する • グループの変わり⽬ ( = 境界値)
• 9999, 10000 -> 9,999回、1万回 (桁の変わり⽬) • 300, 3,000 -> 300回、 3,000回 (カンマが付く、付 かないの変わり⽬) • 特殊な値 • 0, INT_MAXとか
こんな感じ(?) * いろんな桁でテスト * 単位の変わり⽬目、カンマがつく、付かないに特に着⽬目 * 0とか9999, 10000でテスト * -1とか異異常な値は、インスタンス⽣生成時に弾かれる。テストしたければ別途テスト
どこが失敗したかわかり⾟い
パラメタライズドテスト JUnitParams
まとめ • 完全なテストは存在しない、それっぽい値でテストする必要がある • 仕様を満たしていると⾔えそうな値を⽤意 • 仕様をグループ分けして適当な値でテスト • プログラマがミスりそうな値を⽤意 •
例えばメソッドの出⼒が変わる境界の値 • いろんな値をテストする場合はパラメタライズドテストが便利 • JUnit4標準のは微妙なので、JUnitParamsか、JUnit5を使おう
• 完全なテストは存在しない、それっぽい値でテストする必要がある • 仕様を満たしていると⾔えそうな値を⽤意 • 仕様をグループ分けして適当な値でテスト • プログラマがミスりそうな値を⽤意 • 例えばメソッドの出⼒が変わる境界の値
• いろんな値をテストする場合はパラメタライズドテストが便利 • JUnit4標準のは微妙なので、JUnitParamsか、JUnit5を使おう ありがとうございました !
参考リンク • テスト7原則について http://www.itmedia.co.jp/im/ articles/1111/07/news192.html • テストは⽋陥があることしか⽰せない • 全数テストは不可能 •
JUnitParams https://github.com/Pragmatists/JUnitParams • JUnit5 ParameterizedTest https://junit.org/junit5/docs/ current/user-guide/#writing-tests-parameterized-tests