6.2. LoginPage
ログイン画面の仕様が変更されたので、LoginPageを修正します。具体的には、ログインに成功した場合は、ホーム画面ではなくパスワード変更画面に遷移するように修正します。
// 省略
public PasswordPage submitLoginExpectingSuccess() {
loginButton.click();
return new PasswordPage(driver);
}
// 省略
読者の多くはEclipseなどのIDEをお使いのことと思いますが、上記の修正を保存した結果、何が起こったでしょうか？ ログインに成功した場合を表すメソッドのシグネチャを変更したため、下図のようにテストケースでコンパイルエラーが発生しているはずです。
これはとても良いことです。Selenium2によるテストの実行は時間が掛かるので、テストを実行することなく、どのテストが失敗するのか分かるということは、PageObjectパターンの大きな利点です。
6.3.修正したテストケース
最後に、仕様変更に対応するようテストケースを修正しましょう。ここでは、古いパスワードが間違っている場合、または新しいパスワードと確認用の新しいパスワードが一致しない場合はパスワード変更に失敗するものとします。
// 省略
public class SampleTest {
// 省略
@Before
public void setUp() throws Exception {
driver = new FirefoxDriver();
baseUrl = "http://se2sample3.herokuapp.com/";
driver.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS);
}
@Test
public void testSample() throws Exception {
// 省略
loginPage.typeUsername("username");
loginPage.typePassword("password");
PasswordPage passwordPage = loginPage.submitLoginExpectingSuccess();
assertEquals("Password", driver.getTitle());
passwordPage.typeOldPassword("badpassword");
passwordPage.typeNewPassword1("newpassword");
passwordPage.typeNewPassword2("newpassword");
passwordPage = passwordPage.submitUpdateExpectingFailure();
assertEquals("Password", driver.getTitle());
passwordPage.typeOldPassword("password");
passwordPage.typeNewPassword1("newpassword");
passwordPage.typeNewPassword2("badpassword");
passwordPage = passwordPage.submitUpdateExpectingFailure();
assertEquals("Password", driver.getTitle());
passwordPage.typeOldPassword("password");
passwordPage.typeNewPassword1("newpassword");
passwordPage.typeNewPassword2("newpassword");
HomePage homePage = passwordPage.submitUpdateExpectingSuccess();
assertEquals("Home", driver.getTitle());
// 省略
}
// 省略
}
仕様変更対応後のサンプルアプリケーションを参照するよう、baseUrlの値を変更してあるので注意してください。
修正が完了したら、JUnitテストケースとして実行して、引き続きテストが成功することを確認してください。
7. 終わりに
今回はSelenium IDEが生成する冗長なテストコードを、PageObjectパターンを用いて実践的に改善する方法を紹介しました。工夫次第でテストコードの保守性が大きく向上することや、保守性の高いテストコードを書くにはそれなりの時間が掛かることをご理解いただけたのではないでしょうか。
本連載の第1回の終わりでも述べましたが、なんでもかんでもSelenium2でテストしようとすると、とても大変です。細かい境界値チェックや業務ロジックのパターン網羅などは単体テストでしっかりと行い、画面の表示や画面遷移に関する簡易な確認をSelenium2でテストし、UI/UXに関する部分は従来どおり人の目で確認するなど、費用対効果を考慮したテスト計画を立てるように気を付けましょう。
今後は、JavaScriptフレームワークがますます存在感を増していくと思われます。そのため、JavaScriptテスティングフレームワークとの分担についても考慮する必要があります。また、スマートフォンやタブレットなどのモバイル端末におけるテストについても考えていかなければならないでしょう。
2013年のクリスマスにリリースが予定されているSelenium3では、モバイル端末のサポートを強化していくことがSelenium公式ブログで発表されています。これらにもついても、リリースされ次第、なんらかの形で読者の皆さんに紹介できればと思います。
最後まで読んでいただき、ありがとうございました。
