はじめに

本記事はいくつかのパートに分割して執筆していきます。
本パートは 「なぜ、このOSSを開発しようと思ったか？」 という話をしていきます。

どういうOSS

sazanami

現在の差分から単体テストすべき関数だけを導出します。
普段の開発でこんなことありませんか？たった1関数しか変更していないにも関わらず全件分の単体テストを実行して不必要なテストまで行い、コストが勿体無いと感じること。
それを解決するOSSがsazanamiです。(Kotlinプロジェクト専用)

とはいえ、まだsazanamiはα段階です。
そのため、完璧な検出はできていません。(DI、高階関数など...)
また、そもそも完璧な検出は技術的に困難です。

ariadne

sazanamiをAI Agent MCP用としてラップしたOSSです。
コード変更後に関連テストだけ回して結果をループに戻す、というイメージです。
上でお伝えしたようにまだ不安定な側面が目立つためこれをCIに組み込んで利用することはリスクです。
そこで、CIではなくMCPとして利用するようにすればこの問題は比較的許容されやすいと考えました。
ariadneはあくまで、Agentループを加速することが目的で完璧な品質を提供するものではありません。
最終的な防衛ラインはCIで守ればいいと考えました。

思いついた理由

ことの発端は競技プログラミング、LeetCodeを解いていたときに思いついたのです。
その時解いていた問題というのが...

994. Rotting Oranges

問題は下記です：

m × n のグリッドが与えられます。各セルの値は次の3種類のいずれかです。

0 — 空のマス
1 — 新鮮なオレンジ
2 — 腐ったオレンジ

1分ごとに、腐ったオレンジと上下左右に隣接している新鮮なオレンジは、すべて腐ります。

新鮮なオレンジが1つも残らなくなるまでに必要な最小の分数を返してください。
すべてを腐らせることが不可能な場合は -1 を返します。

問題の解き方は省きますが、ここで私が着目した本質は「あるマスの変化が他のマスへ伝播する」という点です。
ここで、問題をグラフとして捉えるとマスはノードと置き換えることができます。
つまり、 「あるノードの変化について辺を辿って影響を追う」 ということです。

ここで、今回はノードの中身は数字でしたが他に置き換えられないか？と考え、色々調べました。
そこで思いついたのが、ノードの中身を関数として、エッジを呼び出し関係として置き換えれば関数同士の関係を探索で追える。
つまり、単体テストのテスト範囲の絞り込みもこの発想を使えばできるのではないだろうか？と考え、sazanami / ariadneの開発に取り組みました。

終わり

今回は課題発見なのでかなり短いです笑
次からはKotlin Analysis APIなどを深掘りしていくので一気に深くなります！