{"id":1097,"date":"2012-04-17T13:00:00","date_gmt":"2012-04-17T13:00:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/integration-testing-with-selenium.html"},"modified":"2012-10-21T23:31:13","modified_gmt":"2012-10-21T23:31:13","slug":"integration-testing-with-selenium","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2012\/04\/integration-testing-with-selenium.html","title":{"rendered":"Integration Testing with Selenium"},"content":{"rendered":"
Overview <\/strong><\/p>\n

I’ve been using this for sometime and I’ve come across a few things that appear to make life easier. I thought I’d share this as a tutorial, so I’ll walk you through these parts: <\/p>\n

    \n
  1. Setting up a web project using Maven, configuring Selenium to run as an integration test on a C.I.<\/li>\n
  2. Look into good ways to model the pages in your site using “page objects” and other ways to create points of protected-variation.<\/li>\n
  3. Use JPA and Hibernate to perform CRUD operations on a database, and have Maven perform integration tests on them, without any of the costly and often undocumented set-up that this sometimes entails. <\/li>\n<\/ol>\n

    This post assumes you’re comfortable with Java, Spring, Maven 2 and, of course, HTML. You’ll also want Firefox installed on you computer. This tutorial is intended to be otherwise technology agnostic. <\/p>\n

    Creating a Webapp <\/strong><\/p>\n

    Firstly we’ll need a webapp to test. Create an project using the maven-webapp-archetype and call it “selenuim-tutorial”. <\/p>\n

    To run integration tests (ITs) we’re going to use the Cargo plugin. This starts and stops containers such as Jetty and Tomcat. You can use Cargo to start your site using Jetty (its default) in one command without any changes: <\/p>\n

    mvn cargo:run\r\n<\/pre>\n
    And check it in you browser at: <\/p>\n
    http:\/\/localhost:8080\/selenuim-tutorial <\/a><\/p>\n
    You’ll get a 404 without welcome file set-up, so add that to the web.xml file:   <\/p>\n
    <welcome-file-list>\r\n <welcome-file>\/index.jsp<\/welcome-file>\r\n<\/welcome-file-list>\r\n <\/pre>\n
    If you run cargo:run again you’ll now see the “Hello World!” page that was created by Maven.  <\/p>\n
    Configuring Cargo  <\/strong><\/p>\n
    We can set-up Cargo to start a Jetty container prior to running the tests, and then stop it afterwards. This will allow us to start our site, run the integration tests, and then stop it afterwards.   <\/p>\n
    <plugin>\r\n <groupId>org.codehaus.cargo<\/groupId>\r\n <artifactId>cargo-maven2-plugin<\/artifactId>\r\n <version>1.2.0<\/version>\r\n <executions>\r\n  <execution>\r\n   <id>start<\/id>\r\n   <phase>pre-integration-test<\/phase>\r\n   <goals>\r\n    <goal>start<\/goal>\r\n   <\/goals>\r\n  <\/execution>\r\n  <execution>\r\n   <id>stop<\/id>\r\n   <phase>post-integration-test<\/phase>\r\n   <goals>\r\n    <goal>stop<\/goal>\r\n   <\/goals>\r\n  <\/execution>\r\n <\/executions>\r\n<\/plugin>\r\n <\/pre>\n
    You can test this work with:   <\/p>\n
    mvn verify\r\n <\/pre>\n
    One thing to note at this point is that Cargo runs on port 8080. If you’ve already got a process listening on that port you might see an error similar to this:   <\/p>\n
    java.net.BindException: Address already in use\r\n <\/pre>\n
    This might be because you’re already running another container on this port. If you want to run this on a C.I. (which may itself run on port 8080), this is likely to be something you’ll want to change. Add these lines to the plugin set-up:  <\/p>\n
    <configuration>\r\n <type>standalone<\/type>\r\n <configuration>\r\n  <properties>\r\n   <cargo.servlet.port>10001<\/cargo.servlet.port>\r\n  <\/properties>\r\n <\/configuration>\r\n<\/configuration>\r\n <\/pre>\n
    Now the app will be here:  <\/p>\n
    http:\/\/localhost:10001\/selenuim-tutorial\/ <\/a><\/p>\n
    Setting-up Integration Test Phase  <\/strong><\/p>\n
    Next, we need to be able to run the integration tests. This requires the Maven failsafe plugin with appropriate goals added to your pom:   <\/p>\n
    <plugin>\r\n <groupId>org.apache.maven.plugins<\/groupId>\r\n <artifactId>maven-failsafe-plugin<\/artifactId>\r\n <version>2.12<\/version>\r\n <executions>\r\n  <execution>\r\n   <id>default<\/id>\r\n   <goals>\r\n    <goal>integration-test<\/goal>\r\n    <goal>verify<\/goal>\r\n   <\/goals>\r\n  <\/execution>\r\n <\/executions>\r\n<\/plugin>\r\n <\/pre>\n
    By default Failsafe expects tests to match the pattern “src\/test\/java\/*\/*IT.java”. Let’s create a test to demonstrate this. Note that I haven’t changed from Junit 3.8.1 yet. I’ll explain to why later on.  <\/p>\n
    Here’s a basic, incomplete test:   <\/p>\n
    package tutorial;\r\n \r\nimport junit.framework.TestCase;\r\n \r\npublic class IndexPageIT extends TestCase {\r\n \r\n @Override\r\n protected void setUp() throws Exception {\r\n  super.setUp();\r\n }\r\n \r\n @Override\r\n protected void tearDown() throws Exception {\r\n  super.tearDown();\r\n }\r\n \r\n public void testWeSeeHelloWorld() {\r\n  fail();\r\n }\r\n}\r\n <\/pre>\n
    Test that works:    <\/p>\n
    mvn verify<\/pre>\n
    You should see a single test failure. <\/p>\n
     To test using Selenium you’ll need to add a test-scoped dependency to pom.xml:   <\/p>\n
    <dependency>\r\n <groupId>org.seleniumhq.selenium<\/groupId>\r\n <artifactId>selenium-firefox-driver<\/artifactId>\r\n <version>2.19.0<\/version>\r\n <scope>test<\/scope>\r\n<\/dependency>\r\n <\/pre>\n
    We can now make a couple of changes to our test:   <\/p>\n
    import org.openqa.selenium.WebDriver;\r\nimport org.openqa.selenium.firefox.FirefoxDriver;\r\n \r\n\u2026\r\n \r\n private URI siteBase;\r\n private WebDriver drv;\r\n \r\n @Override\r\n protected void setUp() throws Exception {\r\n  super.setUp();\r\n \r\n  siteBase = new URI(\"http:\/\/localhost:10001\/selenuim-tutorial\/\");\r\n  drv = new FirefoxDriver();\r\n }\r\n \r\n...\r\n \r\n public void testWeSeeHelloWorld() {\r\n  drv.get(siteBase.toString());\r\n  assertTrue(drv.getPageSource().contains(\"Hello World\"));\r\n }\r\n <\/pre>\n
    We’ll remove these hard coded values later on.  <\/p>\n
    Run it again:   <\/p>\n
    mvn verify\r\n <\/pre>\n
    You shouldn’t see any failures. What you will have is a lingering Firefox. It won’t have closed. Run this test 100 times and you’ll have 100 Firefoxs running. This will quickly become a problem. We can resolve this by adding this initialisation block to our test:  <\/p>\n
     {\r\n  Runtime.getRuntime().addShutdownHook(new Thread() {\r\n   @Override\r\n   public void run() {\r\n    drv.close();\r\n   }\r\n  });\r\n }\r\n <\/pre>\n
    Naturally, if we create another test, we’ll soon be violating DRY principles. We’ll come to that in the next part, as well as looking at what happens when we require a database connection, and some other ways to make sure that your tests are simple to write and easy to maintain. 
     
    <\/div> <\/div><\/p>\n
    Spring Context  <\/strong><\/p>\n
    In the previous example, the URI for the app, and the driver used were both hard coded. Assuming you’re familiar with Spring context, this is a pretty straight forward to change these. Firstly we’ll add the correct dependencies: <\/p>\n
    <dependency>\r\n <groupId>org.springframework<\/groupId>\r\n <artifactId>spring-context<\/artifactId>\r\n <version>3.1.1.RELEASE<\/version>\r\n <scope>test<\/scope>\r\n<\/dependency>\r\n <\/pre>\n
    This will allow us to use and application context to inject dependencies. But we’ll also need the correct Junit runner to test this, which can be found in the spring-test package:   <\/p>\n
    <dependency>\r\n <groupId>org.springframework<\/groupId>\r\n <artifactId>spring-test<\/artifactId>\r\n <version>3.1.1.RELEASE<\/version>\r\n <scope>test<\/scope>\r\n<\/dependency>\r\n <\/pre>\n
    We can now update our test to use this. Firstly we’ll need to create src\/test\/resources\/applicationContext-test.xml   <\/p>\n
    <?xml version=\"1.0\" encoding=\"UTF-8\"?>\r\n<beans xmlns=\"http:\/\/www.springframework.org\/schema\/beans\"\r\n xmlns:xsi=\"http:\/\/www.w3.org\/2001\/XMLSchema-instance\"\r\n xsi:schemaLocation=\"http:\/\/www.springframework.org\/schema\/beans\r\n           http:\/\/www.springframework.org\/schema\/beans\/spring-beans-2.5.xsd\">\r\n \r\n <bean id=\"siteBase\" class=\"java.net.URI\">\r\n  <constructor-arg value=\"http:\/\/localhost:10001\/selenuim-tutorial\/\" \/>\r\n <\/bean>\r\n \r\n <bean id=\"drv\" class=\"org.openqa.selenium.firefox.FirefoxDriver\" destroy-method=\"quit\"\/>\r\n<\/beans>\r\n <\/pre>\n
    Spring will clear up the browser when it finishes, so we can remove the shutdown hook from AbstractIT. This is more robust than having the test case do this.  <\/p>\n
    The spring-test doesn’t work with JUnit 3, it needs at least JUnit 4.5. Lets update to version 4.10 in our pom.xml:   <\/p>\n
    <dependency>\r\n <groupId>junit<\/groupId>\r\n <artifactId>junit<\/artifactId>\r\n <version>4.10<\/version>\r\n <scope>test<\/scope>\r\n<\/dependency>\r\n <\/pre>\n
    Finally, we need to update our test to work with both Spring and JUnit 4.x:    <\/p>\n
    package tutorial;\r\n \r\nimport static org.junit.Assert.assertTrue;\r\n \r\nimport java.net.URI;\r\n \r\nimport org.junit.Test;\r\nimport org.junit.runner.RunWith;\r\nimport org.openqa.selenium.WebDriver;\r\nimport org.springframework.beans.factory.annotation.Autowired;\r\nimport org.springframework.test.context.ContextConfiguration;\r\nimport org.springframework.test.context.junit4.SpringJUnit4ClassRunner;\r\n \r\n@RunWith(SpringJUnit4ClassRunner.class)\r\n@ContextConfiguration(locations = { \"\/applicationContext-test.xml\" })\r\npublic class IndexPageIT {\r\n \r\n @Autowired\r\n private URI siteBase;\r\n \r\n @Autowired\r\n private WebDriver drv;\r\n \r\n @Test\r\n public void testWeSeeHelloWorld() {\r\n...\r\n <\/pre>\n
    These changes moved the configuration from hard coded values into XML config. We can now change the location we are testing, e.g. to a different host, and change the web driver we’re using, which is left as an exercise for the user.  <\/p>\n
    A quick note on browsers. I’ve found that after a browser update, tests often start failing. There appears to be two solutions to this: <\/p>\n