Recommended Practices regarding test database initialisation and test independence

[Jussi Mononen]

Hi all,

is there a recommended way to isolate database states between
individual tests using Robot Framework? I'm currently working with a
web application and we want to keep tests independent so we need every
test to see the database in a pristine state.

I've looked at Robot Framework DatabaseLibrary and its Execute SQL
keywork but that seems awfully cumbersome executing inserts in the
beginning of each test and deletes afterwards. So I would like to know
what you guys have done to get over these kind of issues?

--
"Progress doesn't come from early risers — progress is made by lazy
men looking for easier ways to do things." - Robert. A. Heinlein
[ http://www.agilefinland.com - http://www.scan-agile.org ]
[ http://www.jussimononen.org - http://www.twitter.com/agilepoodle ]

[Mikko Korpela]

Hi Jussi,

I haven't used robot for database testing but... :)

Assuming that you can get your database to a (initial)state that
almost all of your tests can use: Could you use rollback mechanism of
the database?
I think this is a fairly fast operation if the individual tests don't
do many changes. You wouldn't have to know what kind of changes have
happened after the safe point - so no cumbersome data related inserts
and deletes.

2011/5/26 Jussi Mononen <agile...@gmail.com>:

> --
> You received this message because you are subscribed to the Google Groups "robotframework-users" group.
> To post to this group, send email to robotframe...@googlegroups.com.
> To unsubscribe from this group, send email to robotframework-u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/robotframework-users?hl=en.
>
>

--
Mikko Korpela

[Jussi Mononen]

Hi,

Our scenario is that we test a web application which may cause changes
in the database and the browser can't start a transaction, at least
not easily. What I am looking for is a way to easily initialise the
database for each test. Cucumber does it nicely in the Ruby world.

It may well be that we end up using a static DB for our tests but at
the moment we don't want to make such decision.

Br,

-j

[Mikko Korpela]

Hi,

Sounds interesting. I thought that Cucumber was just some sugar on top
of rspec..
How does Cucumber do this?

If the code is Rails specific, I would imagine that you could do
something similar in a Django project with Robot Framework..

2011/5/26 Jussi Mononen <agile...@gmail.com>:

--
Mikko Korpela

[Jussi Mononen]

> Sounds interesting. I thought that Cucumber was just some sugar on top
> of rspec..
> How does Cucumber do this?

Not excalty Cucumber but Ruby has nice little gems that generate the
DB, think Ruby Db migrations.

> If the code is Rails specific, I would imagine that you could do
> something similar in a Django project with Robot Framework..

It is not. It's Java and we haven't really thought about writing our
own extensions yet...

[David]

I haven't used the DB libraries yet, but I would think perhaps
something like the following might work or be worth a try?

Create stored procedures that initialize the database, and any needed
ones to teardown the database after test, unless the initialize one
serves as a teardown as well by reverting/restoring base state. The
stored procedure would handle all the DB transactions needed.

Then with RF DB libraries, just call keyword to execute (SQL/script)
stored procedure(s). And if that works, can then wrap those keyword
calls into a test case/suite setup, or put into custom "user keyword"
and call that from test case/suite setup.

In theory, simple as 1 or 2 keyword calls, no inserts/deletes needed
in test. You set that up within database stored procedures itself.