t_wの輪郭

互いに依存するパラメーターが6個ある機能のテストに必要なパターンをフェルミ推定したところ8万パターン必要という計算になった。どのパターンも、境界値や閏年となっており、バグの検出において重要な値になっている。

全てを手動で網羅しようとすると一週間はかかるため、代表的な900パターンの自動テストでお茶を濁した。
さらに、一部のパターンをコメントアウトし、200パターンが回帰テストされるようにした。

パラメーターの空間に対してテストの密度が低いので、この機能に対して将来にわたって「バグは起きない」という確信は持てない。祈るしかない。

さりとて、2-3年前の私は手動のテストしかしていなかったため、今よりはるかに低い密度のテストしかしていなかった。1/100程度のパターンしかテストしていなかったと思う。そんなテストでよくもまぁなんとかなっていたなと思うと同時に、現在が過剰品質になっている可能性がある。

一つの機能に対して900パターンの手動テストを品証の人に頼みつつ「これでも厳選したんですよ」などと言おうものなら、頭をはたかれるだろう。前に私がテスターをやっていた時は2人がかりで二週間かけて200件ほどのテスト数だった。

describe.eachの四段掛けとかしてたらテストケースが1000件近くになってきた。テストに4分かかる。アホや。

M2 Macbookでこれなので、Intel Mac使ってるチームメンバーから怒られてまう。テストケース数を削らねば。

ユーザー部門と、テストケースの次元の呪いの話をしたほうが良さそう。

jestでdescribe.eachとtest.eachの重ねがけしたらテストケース数がえらいことになった。

機能一つのテストのために300個のテストケースが生えた。

テストに時間がかかるのは良くないので、ちょっと削りたい。