著者:
（１）ジョセフ・ラテッサ、ウェイン州立大学コンピュータサイエンス学部、デトロイトミシガン州、米国（（email protected））
（２）アディ・フリア、セイラム高等学校３年生、ミシガン州カントン、米国（（email protected））
（３）ディーパック・ラジュ、セイラム高校３年生、ミシガン州カントン、米国（（email protected））。
リンク一覧
概要と序論
関連作業
プロジェクトの前提条件
プロジェクトの実施
洞察と考察
結論、謝辞および参考文献
4 プロジェクトの実施
学習を重視しながら、学生に有意義なテストを書いて展開する機会を提供するというプロジェクトの目標を達成するために、HTML バリデーター、リンク チェッカー、および入力パラメータを解析する JETSCAPE フレームワークの機能である JETSCAPE (1) XML リーダーの正確性を確認するための一連の単体テストの 3 つのテストを実装することにしました。最初の 2 つのテストには単体テストが含まれていないため、単体テストと Python UNITTEST フレームワークの紹介は、最初の 2 つのタスクが完了するまで延期できます。
4.1 HTML バリデータ
JETSCAPE (1) および GOMC (2) の Web サイトはどちらも、JETSCAPE および GOMC 科学計算アプリケーションに関する情報を伝えることを目的とした静的サイトです。Web サイトは HTML、CSS、JavaScript で作成されており、GitHub Pages を使用してホストおよびデプロイされています。サイトは、リポジトリのそれぞれのメイン ブランチへのプル リクエストを通じて更新でき、コラボレーションのメンバーはプル リクエストを提案できます。サイトは共同で管理されているため、すべての HTML コードが HTML5 標準に準拠していることを確認するための自動テストがあると便利です。無効な HTML は、見落としがちな小さな外観上の不一致を引き起こすことが多いため、この自動テストは役立ちます。
学生たちは GitHub Actions Marketplace を調べ、私たちのタスクに関連しそうな Marketplace Action (10) のドキュメントを一緒に読みました。Marketplace Action は、Python で構築され、pip から利用できるオープンソースの HTML5 Validator (11) を参照および拡張しました。私たちは、バリデーターをローカルにインストールしてリポジトリ コードでテストし、テストが失敗するように HTML タグの誤字を意図的に追加しました。
バリデーターをローカルで徹底的にテストした後、プッシュ操作とプル リクエストでのテストの実行を自動化する YAML ファイルを共同で作成しました。これまでは、Web サイトにアクセス可能かどうかを確認するためのサンプル YAML ファイルしか見たことがなかったため、そのサンプル ファイルを開始点として参照し、このワークフローに関係のない部分を削除して、バリデーターの Marketplace アクション (10) を呼び出す手順を追加しました。
次に、学生たちはコミットした変更をそれぞれのフォークにプッシュし、GitHub の[アクション]タブで実行中のテストを確認しました。GitHub のランナーでチェックアウトしたリポジトリへのパスをどのようにフォーマットするかという問題が発生しました。ランナー上のリポジトリへのパスはローカル マシン上のリポジトリへのパスとは異なるため、学生たちはテスト ログを読み、ローカルでは合格したテストが GitHub のランナーで失敗する理由を調べる経験を積みました。
HTML バリデータは自動化するのが簡単なテストでしたが、良い出発点だったと考えています。マーケットプレイス アクション (10) はほとんどの作業を実行し、追加のスクリプトを必要とせずにリポジトリのコードを正常に検証するため、学生は実装のテストと自動化を処理する YAML ファイルの作成に集中できました。Git 操作は新しい概念のままですが、学生はコミットとプッシュのシーケンスごとに流暢さを身につけていきました。
4.2 リンクチェッカー
次のテストは、HTML バリデーターの実装で習得したスキルに基づいて行われ、追加のスクリプト作成とトラブルシューティングが必要でした。
リンク チェッカーは、壊れたリンクを識別する便利な Web サイト デバッグ ツールです。プッシュやプル リクエスト時だけでなく、スケジュールに基づいてリンク チェッカーを実行するように設定することの有用性について説明しました。リンク チェッカーは、開発者がコード内で URL を誤って入力したことが原因で壊れたリンクを検出しますが、現在機能しているリンクが、ある時点で機能しなくなることも予想されます。多くの Web サイト リンクは、内部でホストされているページやコンテンツだけでなく、外部の会議ページやジャーナル記事も指しています。古い会議サイトへのリンクは変更されるか、単にオフラインになることがあります。すべてのリンクの有効性を定期的にチェックすることは、手動で行うには面倒な作業です。JETSCAPE (1) および GOMC (2) サイトに関しては、誰も定期的にリンクをチェックしておらず、ツールを実装すると、各サイトでいくつかの壊れたリンクが特定されました。
学生たちは、HTML バリデーターの場合と同様に、GitHub Marketplace Actions やその他の利用可能なオープンソース ツールを調査することから始めました。私たちは、コマンドライン インターフェイスをサポートする Python ツール LinkChecker (12) を見つけました。私たちはこのツールをローカルにインストールしてテストしました。このツールは、URL をコマンドライン引数として受け取り、ページを再帰的に訪問し、最初の URL から到達可能な内部リンクをチェックします。フラグを設定すると、ツールに外部リンクもチェックするように指示できます。
テストでは、ウェブサイトのルート ドメイン (それぞれ https://jetscape.org または https://gomc-wsu.org) を渡すと、index.html ページのリンクはチェックされますが、他のサイト ページは訪問されないことがわかりました。学生たちが調査した結果、ナビゲーション バーは別の nav.html ページのテキストから JavaScript で挿入されており、ツール自体は JavaScript をレンダリングしないことがわかりました。この問題を解決するために、ドメインのルート アドレスではなく、nav.html ページの URL を渡しました。学生たちはテスト ログを調べ、すべての .html ページが訪問されるようになったものの、JETSCAPE ウェブサイトの外部会議やジャーナル リンクの多くはチェックされていないことを突き止めました。
JETSCAPE のサイト設計では、会議や出版物のデータが保存されている JSON ファイルを複数使用しています。JavaScript は、会議や出版物のリンクを含む JSON データを解析し、ページの読み込み時にそれらを関連するテーブルに書き込みます。そのため、ツールは、チェックしたい最も重要なリンクを無視してしまいます。この問題を解決するために、HTML ファイルに具体的に記述されたリンクを正常にチェックするオープンソース ツールを、JSON ファイルにあるリンクを識別してチェックするように設計された独自のリンク チェック スクリプトで補完することにしました。
学生には、実装する関数スタブを含む Python スクリプト スケルトンが提供されました。コード スケルトンの提供は、計算機アプリケーションでバージョン管理を導入するために使用された方法論と馴染みがあり、一貫性がありました。GitHub Actions を導入した URL 到達可能性スクリプトと YAML ファイルのコードも適用可能であり、リンク チェッカーを実装するときに参照できます。学生は、ディレクトリ パスを入力として受け入れ、そのパスで見つかったすべての JSON ファイルのテキストを解析して URL を識別およびチェックする Python スクリプトを作成するように指導されました。このスクリプトをローカルでテストし、関連する JSON ファイルが保存されているリポジトリのデータ フォルダーへのパスを渡しました。
次に、オリジナルのオープンソース リンク チェッカーを使用して HTML ファイルに明示的に記述されたリンクをテストし、独自の Python スクリプトを使用して JSON ファイルで識別されたリンクをチェックするテストを自動化する YAML ファイルを作成しました。次に、意図的に壊れたリンクを含めることで自動化をテストしました。このテスト中に、オリジナルのオープンソース リンク チェッカーが、変更してデプロイしようとしているコードではなく、デプロイされたサイトをチェックしていることに気付きました。これは意図したことではありません。提案された変更によって新しい問題が発生しないように、プッシュしているコードをチェックしたかったのです。この問題を解決するために、GitHub ランナーでローカル サーバーを起動するように YAML ファイルを修正しました。デプロイされたサイトのアドレスをリンク チェッカーに渡す代わりに、GitHub Actions ランナーのローカル サーバーで起動されたサイトのアドレスを渡しました。このソリューションでは、ローカル サーバーを使用して Web サイトをテストする方法と、コマンドラインでプログラムをバックグラウンド プロセスとして実行する方法について説明とデモンストレーションが必要でした。 これらのタスクを完了することで、学生たちは Git 操作の練習、ローカル コマンド プロンプトでの作業、GitHub Actions による自動化を容易にするための YAML ファイル ジョブ ステップとしてのコマンドの記述といった複数の経験を積むことができました。
4.3 ユニットテストの紹介
3 番目の自動テストでは、ユニット テストの概念の紹介が必要でした。この紹介では、バージョン管理の紹介に使用した計算機アプリケーションに戻りました。そのコードを基に、Python の UNITTEST フレームワークを調査し、計算機の算術演算をテストする関数を含むテスト クラスを作成しました。Python スクリプトへの 1 回の簡単な呼び出しで、複数のテスト ケースを実行できることが分かりました。次に、計算機リポジトリへのプッシュおよびプル リクエストでこれらのテストの実行を自動化する YAML ファイルを作成しました。
4.4 XMLリーダーのユニットテスト
最後の自動テストは、Web サイトのリポジトリではなく、JETSCAPE (1) コード リポジトリに適用されます。JETSCAPE アプリケーションは、ユーザーの入力パラメータを受け取るための XML リーダーを提供します。JETSCAPE は、デフォルトのパラメータが設定されている main.xml ファイルを保持します。ユーザーは、別の user.xml ファイルを提供して、main.xml タグの一部またはすべてを上書きできます。user.xml ファイルで発生する可能性のある入力ミスを防ぐため、user.xml ファイルに main.xml ファイルに含まれていないタグが含まれている場合、JETSCAPE アプリケーションはエラー メッセージを表示して終了します。
さまざまなユースケースを示すために、多くのサンプル user.xml ファイルがリポジトリに含まれています。また、新しい機能が追加されるたびに、開発者は新しいサンプル XML ファイルを含めることができます。ここで説明する自動テストでは、Python の UNITTEST フレームワークを使用して JETSCAPE の XML リーダーを呼び出し、リポジトリに含まれるすべてのサンプル user.xml ファイルをテストします。
このテストの要件は、リンク チェッカーと同等の機能を備えています。リンク チェッカーではディレクトリ内のすべての JSON ファイルを識別する必要がありますが、ここではディレクトリのサブツリー内のすべての user.xml ファイルを検索します。これにより、受講者はリンク チェッカー テストで初めて確認したロジックと構文を再確認する機会が得られます。