Testers - Thou Shall Not Cut Code!

okay, so its been a while since my last post, and we have some very frustrating times, i'll try to remember them now.

One of our 500lb gorillas is the fact that Fitnesse out of the box comes with limited functionality. By that i mean if you want to pull a value from a database and assert that it is being displayed in the users browser (via selenium) then you have to write your own Java class. As i said before we are a team of dedicated web testers, and while we are very technical testers, we are not Java programmers. So we looked round for some possible solutions to our dilemma.

First up is Anubhava’s Generic Fixture. Anubhava has had the same thoughts as me, but has the skills to actually put the idea into fruition. His generic fixture allows the fitnesse scriptee to write in DSL without writing a single line of Java, eureka!

i tried using the generic fixture for connecting to the DB. However we use Oracle 10G and our connection string details two nodes. In the examples Anubhava gives, the fixture accepts the usual server, port, dbname, user, password strings.

I thought i would share this with any other visitors who may use generic fixture and use similar JDBC connection strings to us. OracleDataSource will accept a url, so i amened Anubhavas example fitnesse tables to

| Generic Fixture | oracle.jdbc.pool.OracleDataSource |
| setDriverType | thin |
| setURL | jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST =(ADDRESS=(PROTOCOL=TCP)(HOST=node1)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=node2)(PORT=1521)))(CONNECT_DATA =(SERVICE_NAME=WEB)))
| setUser | db_user |
| setPassword | db_user_password |
| conn=getConnection |

and we can now connect to our DB, and script without writing Java.

Next up is Gojko Adzic's DbFit another fixture for fitnesse, and comes with some examples for .net and Java and Oracle.

A little bit more of a learning curve with this one, but still within the realms of what we can manage as testers. We can use DbFit with the WebTest fixture and again accomplish a lot without writing any Java.

I guess i should point out here that its not just writing the Java, its where to store it (CVS), compiling the code, keeping it up to date, making sure we are using the right versions of drivers (ojdbc14), that we have the right environment variables set-up and so on. All of a sudden the line between the bounds of a tester and developer have become so blurred. Well okay, maybe i wouldn't just test the "happy path" :-)