バグ退治の最強ツール！「テストケース・リデューサー」を使いこなそう

皆さんは「テストケース・リデューサー」を活用していますか？実はこれ、デバッグにおいて過小評価されがちな超強力なツールなんです。巨大で複雑なエラーログや再現手順を、問題箇所だけを抽出した最小限の構成まで自動的に削ぎ落としてくれるため、修正のスピードが劇的に上がります。まだ使っていないなら、今のうちにワークフローに取り入れておくことを強くおすすめします！

コンパイラ経由でしか知らなかったけど、すごく面白いね。あるプロジェクトでいろいろあって、デッドコード削除が全く機能しなかったんだけど、ある手法の理論上の改善を見せたかった。でもその時は原因がわからなくてさ（結局あとで1週間かけて根本原因を追いかけたから、まあ振り返れば価値はあったかも…）。一時期は手動でやってたんだけど、誰かがコードを縮小するためにCReduceを使うことを提案してくれた。間違いなく面白いテストとイテレーションのループだったな。

さらに悪いことに、これらを最も徹底的に採用しているコミュニティはコンパイラの開発者たちで、彼らは多くのプログラマから信じられないほど熟練したエリートだと思われている。この記事のアプローチはすごくその場しのぎに見えるね。一生懸命考えて、全ての作業をこなして、全ての失敗を自分で経験しなきゃいけない。別の道を行くなら、問題を分割統治してみるのがいいかも。任意のPair<A,B>は、任意のAと任意のBから簡単に構築できる。だからもし文字列と数値を生成できるなら、数値と文字列のフィールドを持つUserだって生成できるはず。もし生成関数が文字列の複雑さを指定する数値を受け取れるようにすれば、Userをどれだけ複雑にするかも選べるようになる。シュリンキング（縮小）に必要なのはそれだけだよ。問題（ユニットテストのどれかが失敗すること。わざわざ追加の「面白さ」判定テストを書く必要なんてない）が再現する間、繰り返し小さいNを試すだけ。CLIから正しいバイト列を並び替えようと期待するより、入力の構造を利用して興味深いバリエーションを作る方が、境界ケースに遭遇する確率はずっと高いはずだ。

プロパティベースのテストフレームワークも、よくテストケースの削減（いわゆるシュリンキング）を行うよ。

この記事の最初の部分を読んだあと、諦めて「Test-case Reducers」でググったよ。記事の失敗なのか（大量のテキストやCコードの詳細を読みたくなかったから）、それとも成功なのか（このトピックに興味を持たせてくれたから）よくわからないな。たぶん両方だね。

shrink rayに似たbonsai っていうツールを作ったよ。単一ファイルの例を簡略化するのと、複数のファイルをまたいで作業する両方の目的で、コードのインライン化と削減ができるように設計した。構文を認識するためにTree-Sitterを使っていて、簡略化の手法としてはPerses algorithm を採用してる。もし興味がある人がいたら、フィードバックもらえると嬉しいな。