Help us understand the problem. What is going on with this article?

仕事を楽にしたいから評価してみた色々なツール ①(テストツール編)

More than 1 year has passed since last update.

システム業界に入って十ン年、どちらかというとレガシーなシステムに携わることが多かったマイクロソフターな自分。そんな自分にもそろそろ疲れが見え始め、最近はこんなことを考えるようになってきました。

  • コードが長くて読みにくいな・・・
  • 毎日同じことを繰り返しているような気がするな・・・
  • いつも、眠たいな・・・(これは個人的な話)

この状況から脱却すべく、世に出回っている色々なツールを評価してみました。この内容は私独自の検証ですので、参考程度に見てもらえれば幸いです。今回はテストツール編です。

テストツール

レガシーなシステムでは、デザインパターンに則っとっている、あるいは、機能ごとにクラスを分ける、なんていうクラスベースの実装はまず無くて(独自研究w)、1クラスに巨大なメソッドがドーンと鎮座して、所謂、ゴッドメソッド化していることが多いです。このゴッドメソッドは機能毎にコードが適切に分割されていない為、ユニットテストのコードを書くことはまず出来ません。ここでテストツールを導入するという話は詰んでしまいます。

細かいところに手を入れることが出来ないならば、外側からテストすればいいじゃない(いわゆる E2E テスト)。そう思い立ち、Web UI のテストツールを幾つか評価してみました。

最終的に、

  • WebUI で全ての操作を行って、分岐を網羅するのは工数的にも保守的にも無理
  • テストに有効な箇所を見極め、部分導入するのが吉
  • 但し、WebAPI はユニットテストと同じ感覚で分岐を網羅できるので、非常に有効、というか、むしろ、やるべき

という結論に至りました。全ての動作をサポートするのは困難なので、肝心のゴッドメソッド退治には有効な場合とそうでない場合があるでしょう。

今回評価したテストツールと、結果は以下の三種。

1. Puppeteer

  • テストコード記述言語
    • node.js
  • 検証時期
    • 2018 年 5 月頃
  • 対応ブラウザ
    • Chrome (Chromium)
  • 目的
    • ASP.net の画面追加機能の UI テスト、それに伴い追加した WebAPI のテストの為。
  • メモ

検証時点ではテスト実行時に動作が不安定になることもあり、導入は難しいと判断。一方、WebAPI に関しては、問題なく動作しました。但し、WebAPI の Response が Json の場合、予想値との比較をする際にいい感じのメソッドがなく、最終的に文字列に変換するしかなかったのはマイナスポイント。可能な限りリテラルでの実装を避けたいのは、コンパイル時にエラーを検出したいサーバサイド技術者のサガであり、フロント出身の方は気にならないかも。

2. cypress

  • テストコード記述言語
    • node.js
  • 検証時期
    • 2018 年 6 月頃
  • 対応ブラウザ
    • Chrome (Chromium)
  • 目的
    • ASP.net の画面追加機能の UI テスト、それに伴い追加した WebAPI のテストの為。
  • メモ

Puppeteer とほぼ同じ構成に見えるが、実際は多くの部分の異なっています。まず、動作は非常に安定しています。検証した範囲で問題があったのは iframe 内のコンテンツにアクセスできないこと。これは公式の人が現在は対応出来ていないがどこかでしたいと言っているので、いつか実装されるかも(https://github.com/cypress-io/cypress/issues/136)。
テスト実行用の GUI の管理画面が存在するのでそこからテストを実行することも出来ますし、コマンドラインからも可能で非常に使いやすいです。テスト記述時は GUI、リグレッション時は CUI と実践的な使い方が想定されていると思います。
WebAPI に関しては、Puppeteer と同様。個人的にはイチオシのツール。

3. Selenium

  • テストコード記述言語
    • C#(他の言語も対応、今回の検証では C#を使用)
  • 検証時期
    • 2018 年 11 月頃
  • 対応ブラウザ
    • Chrome, Firefox, Edge, IE, etc
  • 目的
    • ASP.net の画面が適切なタイミングでリフレッシュされているか確認する為。同様の検証が複数画面(総計 200 以上!)で必要になった為、実施。
  • メモ

個人的に気に入っていた cypress を使わずに Selenium を試した理由は、EDGE のみ発生する問題を検証する必要があったから。
テストコードを記述できる言語も多く、対応ブラウザも多いです。汎用性は高いが、テストコードは設定する箇所も多く、テストコードが長くなってしまう傾向にある。但し、KatalonStudio や KatalonRecorder を使えば動作を記録してテストコードに変換してくれるので、この機能と併用して負担を軽減可能。
この検証は少々目的が特殊だった為、参考にはならないかも。

今回は以上です。

Why do not you register as a user and use Qiita more conveniently?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away