100 Test Runs Is a Lie: Property-Based Testを実際にどうサイジングすべきか
Property-based testingのデフォルト100例は統計的戦略ではなく社会的妥協だ。自分の信頼性の要件とCI予算にマッチする実行回数の選び方を解説する。
Property-based testをデフォルトの100例で実行しているなら、最悪の両方を手に入れている。CIは必要以上に遅く、それでも大事なバグは見逃している。…
property-based-testing
4 posts
Rustのプロパティベーステストが単体テストでは見逃すバグを見つける
例ベースのテストは思いついた入力だけをカバーする。プロパティベースのテストはランダムデータを生成し、不変条件を検証し、失敗を最小の反例まで縮小する。
関数を書いた。 と でテストして、パスした。リリースした。 ユーザーが1要素のスライスを渡すと、関数はそれを黙って落とす。Issueが立つ。テストファイルを見つめながら、こんな当たり前のことにどうして気づかなかったのかと思う。…
AI Safety Stack: types、contracts、property tests、mutation gates
AI-generated code を production で持たせたいなら、code review だけでは足りません。type constraints から mutation testing、runtime containment までの layered safety stack が必要です。
AI-generated code の危険なところは、常に間違っていることではありません。 危険なのは、merge できてしまう程度には正しく見えることです。 そこが本当のリスクです。明らかに壊れている code は止まります。もっともらしく見え、いくつかの happy-path tests を通り、しかも重要な…
優れたエンジニアリングの考え方が AI で経済的になるまでニッチのままだった理由
Design by contract、property-based testing、mutation testing、model checking は悪い考え方だったわけではありません。継続運用に必要な専門知が重すぎただけです。AI はその前提を変えます。
ソフトウェアエンジニアリングには、読んだ瞬間に「これは正しい」と分かる考え方がたくさんあります。 function が受け取ってよい値と返してよい値を contracts で定義するのは当然です。tests が数個の例だけでなく properties を検証するのも当然です。coverage…