Javaで簡単にUIテストを書けるSelenideを使おう～Selenideの概要とテストの保守性を上げるPage Objectパターンの紹介

ソースコード

　全体のソースコード一式はGitHubで公開しています。ライセンスの範囲内でご自由にご利用ください。

拡張・修正のポイント

　実際にSelenideを使ってテストを書いたりメンテナンスをする際に起こるいくつかのこと、拡張修正のポイントについて解説します。

ページデザイン変更時の対応

　一番よくあることが、テストを実装した後に画面デザインが変更され、要素の位置なども変わることです。

　IDで取得している部分はIDが変更されない限りはそれまで通りで動きますが、それ以外については大抵修正が必要となります。

　このとき、今回のようにPage Objectを使用しているとテストシナリオは修正する必要がなく、Page Objectのうち要素取得のみを記述したAbstract Classのみの修正で対応できます。

　シナリオ、振る舞い、要素取得を分離したことの強みがここで出てきます。

複数画面で共通している部分の対応

　今回の例ではありませんでしたが、常にメニューが表示されている場合にはPage Objectを使用しても重複が発生してしまいます。共通なものはどこか一か所で定義したいですよね。共通の親クラスを作りそこに定義するという方法もありますが、Javaでは多重継承は許されていないため、共通要素が複数あり、それが画面によってあったり無かったりということだと対応しきれません。

　このような場合は、Java 8で導入されたInterfaceのdefault methodを使うのがよいでしょう。Interfaceは一つのClassに複数implementできます。ただし、default methodは可視性がpublicしか指定できないため、要素取得と振る舞いの分離が完全にできません。Java 9ではdefault methodにpublic以外の可視性でメソッドが定義できるようですが、Java 8ではdefault methodでは共通部分の振る舞いを定義したPage Objectを返すようにすることで対応できます。

public interface Menu {
    public MenuPage menu(){
        return new MenuPage();
    }
}

public class MenuPage extends MenuPageBase {
    // メニューの振る舞い
}

public class MenuPageBase {
    // 要素取得メソッド
}