Selenium Anti-Pattern – Including Setup and Teardown in the script

Another thing that I have noticed with the recent batch of clients is that the Setup and Teardown methods are pretty darn complicated — and are basically duplicated from script to script. It occurs to me then in my quest to remove cruft from script files that actually having these methods in amongst the test methods is an anti-pattern.

Instead you want to (again) create a layer of abstraction that is shared between all tests such as this TestNG script.

<pre lang="java">public class LoginTest extends KlientTest {
    @Test
    public void testSignIn() throws InterruptedException {
        SignIn signin = new SignIn(selenium);
        signin.loginEmailPassword("email", "password");
    }
}

Nice and clean.

Of course what we’re really doing is sweeping things under the rug (and into KlientTest) — but that’s acceptable in this case. Or at least tolerable.

<pre lang="java">public class KlientTest {
    public KlientSelenium selenium;
    
    @BeforeMethod
    public void startSelenium() {
        // and a whole bunch of other stuff
        selenium = new KlientSelenium("localhost", 4444, "*firefox", "http://www.klient.com");
        selenium.start();
        selenium.open("/");
        selenium.windowMaximize();
    }
    
    @AfterMethod(alwaysRun=true)
    public void teardown() {
        selenium.stop();
        // and another bunch of stuff
    }
}

With any big suite of scripts there will be the occasional one that needs its own custom setup or teardown. In that situation you could either make a new class to extend or just redefine the method in the script and the jvm will use that one instead.