【ITニュース解説】Construí un buscador de disponibilidad para las bibliotecas del metro de Madrid (y un sistema para verificar que no se rompe)

マドリードの地下鉄駅には、「ビブリオメトロ」という名の小さな図書館があり、市民に本の貸し出しを行っている。しかし、この図書館の公式カタログシステムは使い勝手が悪く、利用者はどの駅に目的の本があるか、あるいは貸し出し中であればいつ返却されるかといった情報を簡単に調べることができなかった。システムエンジニアを目指す上で、このような現実世界の問題を発見し、技術を使って解決しようとすることは非常に重要だ。

この問題を解決するため、ある開発者は「Librometro.es」というウェブサイトを構築した。このサイトは、公式の公開カタログから情報を取得し、目的の本が現在開いている6つのビブリオメトロのどのモジュールにあるか、貸し出し中であればいつ返却されるかを明確に表示する。広告もなく、アカウント登録も不要で、無駄な機能もない。このサイトの目標は、視覚障碍者や音声読み上げ機能（TalkBack）が必要な人を含め、誰もが3回以下の操作で必要な情報を得られるようにすることだった。このようなユーザーフレンドリーな設計は、システム開発において常に考慮すべき点である。

しかし、ウェブサイトを構築すること自体は「簡単な部分」だったという。本当に興味深く、かつ難しいのは、一度作ったシステムが3ヶ月後も、あるいはそれ以降も正しく機能し続けることをどう保証するか、という点だった。システムは時間が経つにつれて、予期せぬ変化やバグによって機能しなくなることがある。これを防ぐための活動が「テスト」であり、特にユーザーが直接操作する部分、つまりユーザーインターフェース（UI）のテストは、多くのシステム開発者にとって悩みの種である。

従来のUIテストでは、「ボタンに『検索』と表示されているか」のように、具体的なテキストや要素の存在を「アサート」（主張・検証）することが一般的だ。しかし、この方法には大きな問題がある。例えば、ボタンの表示テキストが「検索」から「探す」に変わっただけで、テストは「壊れてしまった」と判断され、開発者はテストコードを修正しなければならない。これは非常に手間がかかり、システムの小さな変更のたびにテストが失敗し、修正が必要になるため、開発プロセスを遅らせ、ストレスの原因となることがある。また、UIは常に変化する可能性があり、このような脆弱なテストは、システム開発の柔軟性を損なう。一方、何もアサートしなければ、画面が壊れていてもテストは何も教えてくれないというジレンマがあった。

そこで、開発者は「オラクル（判断基準）を書かない」という新しいアプローチを採用した。このアプローチでは、システムがどのような状態であるべきかを開発者があらかじめ厳密に定義するのではなく、ユーザーが実際にシステムを利用する際の「利用経路」（シナリオ）を具体的に列挙する。例えば、「空のダッシュボードを表示する」「検索結果が表示される検索を行う」「検索結果がない検索を行う」「特定の駅のパネルを表示する」「著者の一覧を表示する」といった具合だ。

それぞれの利用経路において、システムは画面上で「何が見えるか」「どこにフォーカスがあるか」「特定のセクションが表示されているか否か」といった「観測された事実」をテキスト形式で記録する。この記録されたテキストが、その時点でのシステムの「状態」を示すスナップショットとなる。最初のテスト実行時に記録された状態は「過去」（ベースライン）として保存される。そして、その後のテスト実行では、現在のシステムの「状態」を再度観測し、これをベースラインと比較する。

このシステムの重要な点は、比較結果に基づいて「正しいか間違っているか」を判断するのではなく、「何が変わったか」を開発者に報告するだけである、というところだ。例えば、ボタンのテキストが変わった場合、システムはその変更を報告するが、テストは「失敗」とはならない。開発者は報告された変更を見て、それが意図した変更であればそのまま受け入れ、バグによるものであれば修正を行う。この方法では、意図しない変更によってのみ開発者が介入すればよいため、開発プロセスがスムーズになる。テストが「壊れる」のではなく、「変化を報告する」ことで、開発者はより効率的にUIの変化に対応できる。

具体的な例として、共有リンクの挙動に関するバグが挙げられる。Librometro.esには、特定の検索結果や駅の情報を直接共有できるURLがある。モバイル版では、この共有リンクを開くと指定された駅のパネルが直接表示されたが、デスクトップ版ではなぜかそのパラメータが無視され、期待通りの表示にならなかった。デスクトップ版の画面は「機能しているように見えた」ため、通常の目視ではこのバグに気づきにくい。

このバグを発見し修正するために、開発者は新しい利用経路をテストに追加した。それは、問題の共有URLを読み込み、画面がどのように表示されるかを観測するというものだ。バグ修正前の「過去」の状態の記録は、「パネルは空で、選択されたチップもなく、board_viewed イベントのみが発火した」と示していた。これは、共有リンクが正しく機能していないことを示唆する記録だった。

バグを修正した後、同じ利用経路で再度システムの状態を観測した。すると、新しい記録には「パネルがデータで満たされ、sierra-de-guadalupe というチップが選択され、board_opened に加えて sheet_opened というイベントも発火した」と記録された。この記録の変化は、共有リンクがデスクトップ版でも正しく機能するようになったことを明確に示していた。このアプローチの利点は、修正によって意図した変更のみが正確に検出され、他の予期せぬ変化がないことを確認できる点にある。システムは「これは正しい」とは言わないが、「前回見たときから何が変わったか」を正確に伝えてくれる。

このようなテストシステム自体も完璧ではないため、その信頼性を測る必要がある。システムが「嘘をつかない」、つまり誤った報告をしたり、重要な変化を見落としたりしないことが重要だからだ。そのため、開発者は自身のテストツールが「いつ間違ったか」の記録を取るようになった。これには、実際には問題がないのに変化があったと報告する「偽陽性」と、問題があるのに変化を見落とす「偽陰性」の両方が含まれる。

具体的な改善事例もある。例えば、ある時、パネルのアニメーションが途中で停止した状態で画面をキャプチャしたため、ピクセル比較による差分検出が誤って「変化があった」と報告したことがあった。これは偽陽性で、実際にはバグではない。この問題は、キャプチャを行う前にアニメーションを一時停止するように修正することで解決された。また、テキストとリンクが混在する段落の一部を、画面上のテキストを読み取るセンサーが見落とすという問題も発生した。これは偽陰性で、画面は正しくレンダリングされているのに、センサーがその一部を認識しなかったために変化を見落とす可能性があった。これもセンサーのロジックを修正することで対応された。

さらに、特定の要素を選択するセレクターが画面上で一致しなくなり、結果として null（値がない状態）を返した場合、ベースラインもたまたま null だったりすると、システムは「変化なし」と判断してしまうことがあった。これでは、実際には画面が壊れているにもかかわらず、テストが見過ごしてしまう恐れがある。この問題に対しては、単に「値がない」ことを示す null とは別に、「要素が存在しない」ことを明示的に示す absent という状態を導入した。そして、値が absent に変化した場合、システムがこれをサイレントに受け入れることなく、必ず開発者に報告するように修正を加えた。

このように、システム開発においてテストは不可欠な要素であり、特にUIテストは複雑で挑戦的な領域である。今回紹介されたような「アサーションなしのテスト」という新しいアプローチは、従来のテスト手法が抱える課題を克服し、開発者がより効率的かつ確実にシステムの品質を維持するための強力なツールとなり得る。システムを構築するだけでなく、それが将来にわたってどのように機能し続けるかを保証するための工夫は、システムエンジニアが常に考え続けるべき重要な課題である。