The Disco Blog

In Selenium, you can author hip tests programmatically using the language of your choice or via Fit-style tables. From a testing standpoint, the process and results aren’t much different regardless of which one you choose; however, with table driven tests, fixtures aren’t necessarily present. You have to concoct your own.

For example, if I want to use a fixture when programmatically building Selenium tests, I just plug into which ever copasetic test framework happens to be driving my Selenium code– I can use TestNG, JUnit, heck anything I want to– Selenium doesn’t really care. The point being though is that if I use TestNG, for instance, I can then put reusable setup code into a fixture. In the case of web testing, I may need to set up some database records before I run a bunch of acceptance tests.

Conversely, table tests in Selenium don’t hook into an existing test framework– they exist on their own and Selenium acts according to the hip commands placed in a particular table. For example, below is a Selenium test that verifies that one can create words in an online dictionary. The table reads quite easily– the far left column represents browser commands. The middle column corresponds to how the first column should act. In row one, the command is to open the web page located at ../CreateWord.html.

The far right column in a Selenium table test represents input data corresponding with a command. In the second row from above, the first column instructs the browser to type, in the input element whose id is word, the string clepsydra. Rows three and four are similar– three selects the Noun element in a drop down list whose id is partOfSpeech.

This test is fine and dandy (plus copasetic), however, it suffers from a lack of logical repeatability– if this test is run twice, the second test will most likely fail (assuming the database is designed to constrain unique values, like words in a dictionary). What I need, of course, is a way to ensure that this test can be run in a repeatable manner; accordingly, this is where a framework like DbUnit shines.

DbUnit essentially is a fixture framework that manages database data so that you don’t have to during testing. This is a hip point– DbUnit ensures a database is ready for tests– either by inserting look up data or pre-requisite rows before a test is run. What’s more, DbUnit can also remove data after a test. In turns out that DbUnit can both insert desired data and remove test data at the same time before a test is run, thus obviating the need to run database logic after a test completes too.

Putting the database in a clean state before I run a test (like the Selenium above) is fine and dandy; however, it doesn’t really help me yet as I need some way of invoking DbUnit via my Selenium table test. Because Selenium is ultimately a web testing framework that drives a browser, I can essentially force a fixture via embedding fixture logic in a web page. This is where a diet rich in Selenium, by the way, can start to get Groovy.

Groovy shines as a medium for creating hip applications quickly– I use this fine language all the time to knock simple stuff out. Accordingly, with Groovy, because it’s my bag, I can create a quick and dirty (but albeit clearly useful) Groovlet that uses DbUnit to put the database in a known state before I run any of my Selenium tests; what’s more, because the Groovlet is a web resource, I’ll create a Selenium table test to invoke it before running the other tests.

Groovlets do require a slight container configuration tweak and the addition of Groovy’s uber jar to the associated web application’s classpath; however, once you’ve taken care of those two requirements, you’re good to go to drop in Groovy scripts that are executed as web resources. What’s more, Groovlets don’t have to follow any associated framework pattern– you don’t have to implement a doGet method or anything like that; in fact, you don’t have to even define a class– just code away in a normal script and that code will be executed within the context of a Servlet.

For example, the following groovy Groovlet does exactly what I need and is a fixture that ensures I can run the create word test from above in a repeatable manner by employing DbUnit.

import org.springframework.context.support.ClassPathXmlApplicationContext
import org.dbunit.database.DatabaseConnection
import org.dbunit.dataset.xml.FlatXmlDataSet
import java.io.ByteArrayInputStream
import org.dbunit.operation.DatabaseOperation;

def scontext = new ClassPathXmlApplicationContext("spring-config.xml")
def datasource = scontext.getBean("dataSource")

def data = """<?xml version='1.0' encoding='UTF-8'?>
<dataset>
 <word WORD_ID="1" SPELLING="pugnacious" PART_OF_SPEECH="Adjective"/>
 <definition DEFINITION_ID="10" DEFINITION="Combative in nature; belligerent."
    WORD_ID="1"
    EXAMPLE_SENTENCE="The pugnacious youth had no friends left to pick on."/>
 <synonym SYNONYM_ID="20" WORD_ID="1" SPELLING="belligerent"/>
 <synonym SYNONYM_ID="21" WORD_ID="1" SPELLING="aggressive"/>
</dataset>
"""

def dataset = new FlatXmlDataSet(new ByteArrayInputStream(data.getBytes()))
def conn = new DatabaseConnection(datasource.getConnection())
DatabaseOperation.CLEAN_INSERT.execute(conn, dataset)
conn.close()

println "fixture executed successfully"

Because the web application being tested uses Spring, the Groovlet obtains a reference to a copasetic DataSource object (that is consequently used by associated Hibernate code) in order to obtain a connection to the underlying database. Next, a String instance is created that contains XML representing the data I want placed in the database before my tests are run. DbUnit has a few different formats for data representation; however, I find that the FlatXmlDataSet format is most intuitive.

Using DbUnit’s API, I then insert the corresponding XML in the dataset String. Note that because it’s my bag baby, I use DbUnit’s CLEAN_INSERT command, which first deletes all existing data and then inserts the data found in the XML. This means I don’t need to worry about a tear down fixture– the set up removes old data and puts in new requisite data. Lastly, the connection is closed and the fixture is considered complete. Not bad, considering the fixture look 5 minutes to code and about 10 lines of code, eh?

From Selenium’s standpoint, I don’t really need to do anything but create a table test that opens this page before running any tests, man. Then I need to update my suite file and ensure that the fixture is the first URL hit before any tests are run.

Now I’ve got a repeatable suite of Selenium tests– and all it look was a little help from Groovy and DbUnit. Dig it?

Trackback this Post | Feed on comments to this Post