分かっているようで意外と知らない
ソフトウェアテスト
@nefrock in 大岡山
Kohei Kariya -> koka
Freelance Engineer
Q. “テストって何の為にするんだっけ”
“バグを未然に防ぐため”
本当に?
Q. “そもそもバグってなに?”
“仕様です! と言い張れないような挙動”
→ ユーザが被害を被るようなもの全般
バグを未然に防ぐ ← もちろんある
“技術的負債を増やさない” ← こっちの方が大事
バグを未然に防ぐ
バグはどうしても生じる
バグを全て見つけるのは不可能
バグの存在は示せるがバグの不在は証明できない
“そもそもなぜテストを書くんだっけ”
まだ表面的
→ ユーザが被害を被らないため
x 目的と手段を履き違えない
バグを減らし、バグが生じた際に修正コストを低く保つ為に技術的負債を増やさないための手段
よっしゃテスト書くで!
…あれ、どうやって書けばええんや?
バグを全て防ぐのは不可能
→ 全てを網羅するテストが書けないから
バグが発生しうるテストケースを考慮できるならバグは起こらない
テスターを無限人雇うと
→ テスターの品質・テスターのテストはどうやって保障するのか
プロダクトを理解したエンジニアが兼任するのがベスト
自分で書くしかない
ホワイトボックス
ブラックボックス
→ 実装を気にしないテスト
→ プログラムの分岐条件各々に対してフローテスト
両方やりたいけどコストが…
“どこをテストすればいいの?”
“バグの8割はプログラムの20%の部分に集中している”
複雑な部分・バグりやすい部分は大体同じ
→ 普段からテストを書いていればここが落ちやすいというのがわかる
→ Test-Driven Development
カバレッジ計測を行うことでバグの埋まりやすい部分、テストの薄い部分が可視化される
→ ホワイトボックステスト
→ ブラックボックステスト
閑話休題
静的型付けと動的型付け
Q. “型の有無でバグ数に有意差が生じるのか”
A. ほぼない
→ 型よりもプロダクト・チームにあった言語を採用するほうがよい
とはいっても今回は型システムの恩恵を紹介します
型システムを用いることで(ある種の)バグの不在を証明出来る
テストデータを型情報に基づいて乱数生成する
→ 入力値の組み合わせを自動生成出来る!
例(RustのProptestというライブラリ)
#[test]
fn parses_all_valid_dates(
s in "[0-9]{4}-[0-9]{2}-[0-9]{2}"
) {
println!("{}-{}/{}", y, m, d);
// 1667-77-67
// 5076-51-20
}
例(RustのQuickcheck)
quickcheck! {
fn prop(xs: Vec<u32>) -> bool {
xs == reverse(&reverse(&xs))
}
}
関数の挙動もテストできる
ユーザーが不利益を被らないようにする
そのために
ユーザに価値を届ける為にテストをしよう
参考文献・リンク