続・【Selenium WebDriver】wait処理のCustomConditionを作る

http://www.softwaretestingclass.com/what-is-selenium-webdriver-selenium-training-series/より引用

前回に書いた記事の waitのCustomConditionなのですが、微妙な気がしたので書き直しました。

　どこが微妙か

端的にいうと、無駄にクラスが量産され、処理が見えにくい気がしました。
（自分で作っておいてなんですが笑）

ExpectedConditionの具象クラスを作るということは１クラスに対して、
1つのwait条件メソッドしか書けないということになります。
org.openqa.selenium.support.ui.ExpectedConditionsクラスを
確認していただければわかると思いますが
LocatorとWebElementに対して同様の処理を行うメソッドが用意されています。
つまり、引数が異なるのみでほぼ同様のチェック処理を行うメソッドを提供するようになっています。
これに倣うためには、具象クラスを作るのはなかなか面倒なことになるなと考えなおしました。

前回のまとめに「数が増えてきたらCustomConditionsクラスを作る」みたいなまとめにしてしまったのですが、
それならはじめに作ってしまったほうが良いなと・・・。

　どう実装するか

ExpectedConditionsクラスを模倣した拡張クラスのみで充分です。

　ソース

こんなかんじで良いと思います。
前回と同様に任意の属性に含めれる値のチェックをするような処理です。

import org.openqa.selenium.By;
import org.openqa.selenium.StaleElementReferenceException;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.ui.ExpectedCondition;

public class CustomExpectedConditions {

    public static ExpectedCondition<Boolean> textToBePresentInElementAttribute(final WebElement element, final String attributeName,
            final String expectedValue) {

        return new ExpectedCondition<Boolean>() {
            @Override
            public Boolean apply(WebDriver driver) {
                try {
                    String elementText = element.getAttribute(attributeName);
                    if (elementText != null) {
                        return elementText.contains(expectedValue);
                    } else {
                        return false;
                    }
                } catch (StaleElementReferenceException e) {
                    return null;
                }
            }

            @Override
            public String toString() {
                return String.format("text ('%s') to be the value of element %s", expectedValue, element);
            }
        };
    }

    public static ExpectedCondition<Boolean> textToBePresentInLocatorAttribute(final By locator, final String attributeName,
            final String expectedValue) {

        return new ExpectedCondition<Boolean>() {
            @Override
            public Boolean apply(WebDriver driver) {
                try {
                    String elementText = driver.findElement(locator).getAttribute(attributeName);
                    if (elementText != null) {
                        return elementText.contains(expectedValue);
                    } else {
                        return false;
                    }
                } catch (StaleElementReferenceException e) {
                    return null;
                }
            }

            @Override
            public String toString() {
                return String.format("text ('%s') to be the value of element %s", expectedValue, locator);
            }
        };
    }
}

　まとめ

前回の記事では、具象クラスを作ると説明しましたが、
むしろインターフェース型の無名クラスを作ったほうが柔軟性が増すというところを
あまり気にせず書いてしまったかなぁと思っています。
こういった実装の方が、変更に閉じて拡張に開いているのではないかなぁとか思います。