記事
· 2024年9月23日 6m read

UnitTest(ユニットテスト)の自動化について考察

コミュニティの皆さんこんにちは。

突然ですが、皆さんはIRISの機能にある「ユニットテスト」は利用されているでしょうか。
筆者はまだ実装まで行えていませんが、各関数の品質保証を担保するため導入を検討している段階です。

現状、IRISのユニットテストには下記2点の対応すべき点があると考えています。

  1. テスト結果の可読性が低い(先日vscodeで拡張機能が出ていましたが、やはり見ずらいと感じました)
  2. ユニットテストを自動で実行する手段がない

特にテストが継続的に自動で実施されないと、ユニットテスト自体が次第に陳腐化し、実行されなくなり忘れ去られる恐れがあると考えます。
ただし、意味もなく定期的にテストを実行しても効果がありません。
そこで、Gitのpushのタイミングで行おうと考えました。

次にテスト環境です。
テスト環境の構築は、テスト自動化の観点からみるとCI/CDツール等を利用するのが一般的だと思います。
ただ今回は、テスト環境の構築を簡易にすませたいと考え、IRISの既存技術を組み合わせて構築しようと考えました。

そこで運用幅の広いInteroperabilityとユニットテストを組み合わせて、テストの自動化が可能か考察していきたいと思います。

 

【ユニットテスト全体概要】

 

 

【全体の流れ】

 ■ユーザの開発環境

  ①ユーザは改修したクラスをGitへpushする

 ■Git用のサーバ

  ②GitリモートリポジトリのHook「post-receive」が、テストサーバへHTTP通信を実施

 ■ユニットテスト用のサーバ

  ③RestAPIから②を受け取り、interoperabilityのサービス「ServiceRest」をキック

  ④Interoperability処理
    プロダクションは下記となっています。 ※主要な機能しかまだ作っていません。

    

プロダクション説明
項目 名称 説明
サービス ServiceRest RestAPIよりキックされ、プロセス「TestProcesse」をキックする。
「TestProcesse」が起動中の場合は、更新が重複するため何もしない。
  ServiceTimer 「TestProcesse」が動作中に発生したGitの更新は、定期的な監視を行っているこのサービスでフォローする
プロセス DeleteProcess 指定日を越えたユニットテストのデータと出力したファイルを削除する
  MainProcesse テスト結果を検証し、HTMLファイル・CSVファイルを出力する
オペレーション「SendMail」とプロセス「DeleteProcess」をキックする
  TestProcesse Gitの更新・テストクラスの配置・クラスのインポート・テスト実施を行う
プロセス「MainProcess」をキックする
オペレーション SendMail MainProcessよりテスト結果を受け、出力したファイルを添付してメールする

 


【一連の連携で追加した機能】

 ■テスト結果を参照するHTMLファイル・CSVファイルの作成
  IRISの機能であるテスト結果参照ページは、テスト結果の可読性が低いです。
  そこで、HTMLファイル・CSVファイルの出力を別途行うようにしました。


 ・既存のユニットテスト・ポータル画面
    

  TestAssertsまでドリルダウンしていかないと、エラーが発生の詳細な原因を判別するのが難しい。
  テスト全体を見渡すことが難しい。

 

 ・HTMLファイル出力

   

  テストデータをHTMLファイルに含んでいるため、スタンドアロンで表示させる事が可能。
  また、データ量が多くなる事を踏まえて、スクロールバーを下げる事で一定行数毎に結果を追加する仕様。
 

 ・CSVファイル出力

   

  ただのCSVファイルのため、特筆すべき点はありません。

 

■各テスト関数の処理時間を検証

 データの取得・登録を含んだ関数を改修した際、ごく稀に処理時間が想定外にかかるような場合があります。
 大概はロジックが悪いケースですが、処理時間の比較は割と見落としてしまう点だと思います。

 そこで、ユニットテストついでに処理時間の比較を行おうと考えました。
 ただ各テスト毎に処理時間の比較機能を組み込むのは、手間がかかるため困難です。

 そこで、ユニットテストの処理時間(関数実行時の処理時間)に着目しました。

 この「処理時間」をプロセスの処理で記録し、そこから得た中央値を利用して比較しようと考えています。
  ※注)テスト関数の処理時間を比較に利用するため、テスト関数内部の個々の処理自体に対する速度検証にはなりません。

 処理時間の比較は、下記流れにそって行っています。 ※フラグ制御にて比較自体を不可にもできる

   ①テスト関数のステータスが「passed(成功)」している事を確認する
   ②該当テスト関数が2回目以降である事を確認する(初回の場合は比較対象が無い為)
   ③過去の処理時間リストより、中央値を取得する
   ④ ③より、係数を利用して比較用の値を算出する
    係数は、テストクラスにパラメータとして設定します。パラメータ名は下記仕様に準じています。
     ・関数名 + 「ADD」→中央値にパラメータの値を加算する
     ・関数名 + 「MUL」→中央値にパラメータの値を乗算する
       

    テスト関数の係数(パラメータ)が設定されていない場合は、下記値を係数としています。
     ・プロセス「MainProcess」のプロパティ「BaseTime」に設定している値と中央値を乗算する

    ⑤ ④の値と比較し、今回実行時の処理時間が大きい場合、テスト関数のステータスを「passed」から「timeout」へ変更する
     timeoutへのステータス変更は、出力されるファイルへ反映する事になります。

       例)中央値から外れた場合のHTMLファイルの表現
        

    ⑥今回の処理時間を特定のグローバルに保存する。

 


【出力したファイルをメールの添付ファイルとして送付】

  オペレーション「SendMail」では、Embedded Pythonを利用してメールを送付しています。

  恥ずかしながら、interoperabilityのメール機能で複数のファイルを添付する方法が分からなかった為、Pythonで実行するように切り替えました。
  困ったら別の手段が検討できる、この柔軟さがIRISの良いところだと思います。

    例)エラーが発生した場合のメール内容

     

 

 


以上になります。

今回は考察が主なため、細かい作り込みは行っていません。
エラー処理や、GIT更新後のクラスインポート・コンパイルを更新があったクラスのみに絞る等々、まだまた実用化には長い道のりだと感じています。
他にも実装したいロジックはありますが、一旦ここで筆を置きたいと思います。


Interoperabilityの機能を使うことで、ユニットテストの自動化を実現する事は可能だと考えています。
拙筆ではありますが、何かの参考になれば幸いです。

サンプルPGはGithubに置いてあります。

ディスカッション (0)1
続けるにはログインするか新規登録を行ってください