Quantcast
Channel: パークのソフトウエア開発者ブログ|ICT技術(Java・Android・iPhone・C・Ruby)なら株式会社パークにお任せください
Viewing all articles
Browse latest Browse all 138

CIの実現について考察

$
0
0

はじめに

こんにちは。バグ太郎です。

表題の通りですが、最近身の回りではJenkinsなどを用いて
テストを継続的に行うような環境を作る動きが活発になっているような気がします。

たとえばJavaの場合、Jenkinsでスケジューリングしプロジェクトのビルドをトリガに
findbugsを用いて静的テストを行い、junitやjmokitを用いて単体テストを行い、
coverturaを持ちいてカバレッジの集計なんかができます。

そこまでやるならぜひ結合テストをやりたいと思った所存です。といってもUIテストですが。
そこで白羽の矢が立ったのがSikuliです。

Sikuliとは,

Sikuli scriptといって、画像認識でGUI操作を自動化する所謂マクロツールです。
専用のIDEが存在し、操作の対象を探索するための画像を表示しながら
コーディングすることができるという特徴があります。
他にも色々特徴はあるのですが、今回のミソはJVM上で動作することです。
専用のIDE上ではJRubyやJythonで記載するようですが、
ようはこいつの本体はjarで、中身はjavaです。

なぜSikuli?

JenkinsでCIを実現するにあたって、
一番楽な連携は結果をxmlで出力することだと(勝手に)思っています。
junitなどもビルドから実行が始まり、Jenkins上から集計なんて言ってますが
ただ結果のxmlを参照してるだけです。
ようは、junitと同じように結果を出力してしまえばいいわけです。
SikuliのAPIはjarで提供されていますから、当然JunitTestの実装でもインポートして使えます。
つまり、

JunitでSikuliを用いてUIテストを行い、結果をJenkinsに渡す


という構想なわけです。

JunitとJenkinsの関係性そのままです。特にPluginなどは使いません。
なので実現は非常に簡単な部類かと思います。すごい。


問題点は画像認証のマクロツールという立場上、
テストの手順は必ず再現できるものでなければいけないことでしょうか...
表示や遷移が頻繁に変わることのない画面系のテストか、リグレッションテストが主な用途になるかと思います。


シリーズ化したら、次回は実際に作成してみたいと思います。では。

Viewing all articles
Browse latest Browse all 138

Trending Articles