Hi,
I was wondering what folks are using to make their tests data driven.
I am testing a Rails app using Selenium RC and Ruby.
One option seems to be RubyFIT but it doesn't seem to be very active -
the last release was on May 21, 2006. Maybe I am incorrect in my
assumption and it is being widely used and maintained? The other
option is to go with a simple text file/csv to store input and
expected output data and write my own code to read it.
I am looking for recommendations on which approach to take, bearing in
mind that the organization has very minimal staffing - think one part
time QA (test developer) so something simple and quick to implement
and maintain would be best.
> Hi,
> I was wondering what folks are using to make their tests data driven.
> I am testing a Rails app using Selenium RC and Ruby.
> One option seems to be RubyFIT but it doesn't seem to be very active -
> the last release was on May 21, 2006. Maybe I am incorrect in my
> assumption and it is being widely used and maintained? The other
> option is to go with a simple text file/csv to store input and
> expected output data and write my own code to read it.
> I am looking for recommendations on which approach to take, bearing in
> mind that the organization has very minimal staffing - think one part
> time QA (test developer) so something simple and quick to implement
> and maintain would be best.
> try using a ruby gem called Faker. google it and see if it helps.
> On Fri, Apr 3, 2009 at 9:46 AM, sangeeta <sangeeta.naraya...@gmail.com>wrote:
>> Hi,
>> I was wondering what folks are using to make their tests data driven.
>> I am testing a Rails app using Selenium RC and Ruby.
>> One option seems to be RubyFIT but it doesn't seem to be very active -
>> the last release was on May 21, 2006. Maybe I am incorrect in my
>> assumption and it is being widely used and maintained? The other
>> option is to go with a simple text file/csv to store input and
>> expected output data and write my own code to read it.
>> I am looking for recommendations on which approach to take, bearing in
>> mind that the organization has very minimal staffing - think one part
>> time QA (test developer) so something simple and quick to implement
>> and maintain would be best.
> On Sat, Apr 4, 2009 at 6:29 AM, Joaquin Rivera Padron
> <joahk...@gmail.com> wrote:
>> faker is a good one, I tipically use it with machinist (at github)
>> and it's
>> a charm
>> there are some others, among them that I recall:
>> fixture replacement
>> factory girl
>> dm-sweatshop
I also have been wrestling with this issue of DDT (data driven
testing). I am a believer of the KISS (keep it simple stupid)
methodology, and the simplest way to store data when using HTML
(seleneese) based test scripts in selenium IDE or RC is to create a
local HTML document that is simply a table of data. Then have your
selenium script first go to this HTML table of data and store text
data to be used for the remainder of the test and then go to you login
page to perform the rest of the test. Below is a output from my
results file that illustrates a simple login example.
COMMAND
ID
VARIABLE_NAME
store file:///C:/Selenium/Tests/dataSuite.html dataSuite
store http://yourTestSiteHere.aspx demoAPP
store ctl00_MasterContentPlaceHolder_butLogin login_btn
store ctl00_MasterContentPlaceHolder_UserName userNameTXT
store ctl00_MasterContentPlaceHolder_Password userPasswordTXT
open ${dataSuite}
storeText //tr[2]/td
userName
storeText //tr[3]/td
userPassword
open ${demoAPP}
assertTitle Login
type ${userNameTXT} ${userName}
type ${userPasswordTXT} $
{userPassword}
clickAndWait ${login_btn}
assertTitle Home
I understand that this a most primitive way of doing data with
selenium, but i strive for simplicity, and this works great. One
drawback is that you must manually fill up the dataSuite table with
data first, and then you can only read data not write to it. Hope this
helps!