What Do Contribution Guidelines Say About Software Testing?

オープンソースソフトウェアのプロジェクトを、活気あふれる巨大なコミュニティ・キッチンだと想像してみてください。誰でも中に入って、包丁を手に取り、より良い料理を作るために野菜を切る（コードを書く）ことができます。しかし、キッチンを円滑に運営するために、ヘッドシェフ（プロジェクト・メンテナー）はカウンターの上に「ルールブック」を置いておきます。このルールブックは、新しい助手に対し、どのように手を洗い、どこで食材を見つけ、そしてスープを台無しにすることなく、どのように切った野菜を提出すべきかを教えてくれます。

この論文は、ある研究チームが、これら200の有名なコミュニティ・キッチン（具体的にはPythonとJavaScriptという言語を使用しているもの）に入り込み、ルールブックを読んで、そこに「テスト」について何が書かれているかを調査したものです。

料理の世界において、「テスト」とは、料理を出す前に味見をして、石鹸のような味がしないか確認することに似ています。研究者たちは、次のような疑問を持ちました。ルールブックは、新しい助手に「食べ物の味を確かめる方法」を実際に教えているのか、それとも、誰もがそのやり方を知っていると決めつけているのだろうか？

以下に、その調査結果を分かりやすく解説します。

1. ほとんどのキッチンには「味見」のセクションがある（ただし、すべてではない）

研究者たちは、78% のキッチンに、味見（テスト）に特化したセクションがあることを発見しました。

• 場所はどこか？ 多くの場合（58%）は、「CONTRIBUTING」という名前のファイル（メインの指示書）の中にあります。時には、別の豪華なパンフレット（外部ドキュメント）の中にあり、稀に、メインメニュー（README）に書き殴られていることもあります。
• ギャップ： 約22% のキッチンには、味見に関する指示が全くありませんでした。もしあなたがこれらのキッチンに入ったとしたら、食べ物が美味しいかどうかをどうやってチェックすべきか、自分で推測しなければなりません。

2. 「やり方」のアンバランス：実行 vs 作成

ルールブックが「味見」について述べている場合、彼らはあることには非常に長けていますが、別のことには不得意でした。

• 「実行する方法」（83.5%）： ほとんどのルールブックは、「これが鍋全体の味を確かめるための魔法の呪文（コマンド）です」と明確に伝えています。これは、「このボタンを押して味をチェックしてください」と言うようなものです。
• 「書き方」（37%）： 新しい味のテストを実際にどのように作るかについて説明しているルールブックは、はるかに少なかったです。これは、「ボタンを押してください」とは言うものの、新しいスプーンをどう作るか、あるいは何が「悪い味」なのかをどう判断するかを教えていないようなものです。
• 結果： 助手たちは既存の食べ物をチェックする方法は知っていますが、自分が加えた新しい食材のために、どのようにテストを作成すべきかについては、多くの場合、推測に頼ることになります。

3. 「テスト・ピラミッド」の問題

ソフトウェアには、異なるレベルのテストがあります。それは、異なる種類の味見のようなものです。

• ユニットテスト（単体テスト）（71%）： これらは、単一の食材を味わうようなものです（例：「この人参は甘いか？」）。ルールブックでは、これについて多く語られていました。
• インテグレーションテスト（結合テスト）（20.5%）： これらは、人参と玉ねぎが鍋の中でどのように作用し合っているかを味わうようなものです。ルールブックでこれに触れていることは稀でした。
• エンドツーエンドテスト（E2Eテスト）（15.5%）： これは、完成した料理全体を味わって、ディッシュ全体がうまく機能しているかを確認することです。ルールブックでこれについて語られることはほとんどありませんでした。

メタファー： シェフたちは、人参が正しく味わえるかどうかについては非常に心配していますが、野菜同士がうまく混ざり合っているか、あるいは鍋全体が焦げてしまわないかをチェックする方法については、助手にほとんど教えていません。

4. 欠けている「秘密兵器」

研究者たちは、テストをより簡単かつ確実にすることを助ける、高度な調理テクニックについても調べました。

• モッキング（Mocking）（9.5%）： 時には、スープの中の本物の海水が味わえないことがあります。その場合、本物の塩の代わりに、海水をシミュレートするための「偽物の塩瓶」を使う必要があります。これが「モッキング」です。10軒に1軒程度のキッチンしか、これらの偽の道具の使い方についての指示を持っていませんでした。
• カバレッジ（網羅率）（25.5%）： これは、レシピのどの程度が実際に味見されたかを示すスコアカードです。約4分の1のキッチンだけが、助手に対して目指すべきスコアを伝えていました。
• ベストプラクティス（推奨される手法）（9%）： 「提供する前に必ず味見をすること」といった一般的なコツは、非常に稀でした。

結論

この論文は、ほとんどのオープンソース・プロジェクトが、助手たちに自分たちの仕事をテストしてほしいと考えている一方で、彼らが残した指示書はアンバランスであると結論付けています。

彼らは、「ここにあるテストを実行する方法」を伝えることには長けていますが、以下については沈黙しています。

• 新しいテストをどのように書くか。
• 複雑な相互作用（インテグレーション）をどのようにテストするか。
• システム全体（エンドツーエンド）をどのようにテストするか。
• 高度なツール（モッキング）をどのように使うか、あるいは品質目標（カバレッジ）をどのように設定するか。

まとめ： もしあなたがこれらのキッチンの新しい助手だとしたら、あなたは「味見」ボタンの押し方は知っているかもしれませんが、新しいレシピのための味見を実際にどうやって作るのか、あるいは自分の作った新しい料理が食事全体を台無しにしないことをどうやって保証するのかについては、一人で解決しなければならない状況に置かれるかもしれません。著者たちは、助手が推測に頼らなくて済むように、プロジェクトのリーダーはより明確で完全な指示を書く必要があると示唆しています。