[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

dynamic evaluation from a database

Peda, Allan (NYC-GIS)

10/13/2008 12:13:00 AM

Hi,

I am writing some functional testing applications in watir and I am most
likely going to have this application store the data in a MySQL or
Oracle database. Since the tests are going to be in a constant state of
change I figure it might be best to store the scripts in the DB as well,
since this would allow me to re-deploy any code changes by updating the
clobs in the DB.

The are several ways to go about this, but was curious as to writing
stubs that just fetch the source directly from the DB using DBI to
evaluate it. In a general sense is this asking for too much trouble in
debugging or using require etc ? I assume require can be overloaded to
search the DB as well as the filesystem.
--
Posted via http://www.ruby-....

1 Answer

Robert Klemme

10/13/2008 8:36:00 AM

0

2008/10/13 Allan Peda <allan.peda@interpublic.com>:
> I am writing some functional testing applications in watir and I am most
> likely going to have this application store the data in a MySQL or
> Oracle database.

What is the reason for this? What else data is there that needs to be
in sync with your test code?

> Since the tests are going to be in a constant state of
> change I figure it might be best to store the scripts in the DB as well,
> since this would allow me to re-deploy any code changes by updating the
> clobs in the DB.

What do you mean by redeploy? Are you doing the tests on multiple systems?

> The are several ways to go about this, but was curious as to writing
> stubs that just fetch the source directly from the DB using DBI to
> evaluate it. In a general sense is this asking for too much trouble in
> debugging or using require etc ? I assume require can be overloaded to
> search the DB as well as the filesystem.

I'd rather not change the default require's functionality but instead
write a db_require or such which can be used for your special case.
This will also avoid any conflicts when there are similarly named
modules in your test suite and other load path. My 0.02 EUR.

Kind regards

robert


--
remember.guy do |as, often| as.you_can - without end