• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Best Practice For Testing Against Databases

 
Ranch Hand
Posts: 515
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'll setup the situation here...
So I have a team of people coding against a database.

First Database schema is ORACLEDBA
Second Database schema is ORACLEDBA2

The first database (ORACLEDBA) we can only do selects against. Other people in the company are using this database to test their code against. No inserts, updates or deletes can occur here.

The second database (ORACLEDBA2) we can do whatever we want with. This is our copy. I prefer to do destructive tests against this database.

The schema name of the database that the system will be going against will reside in a property file. This way you can swap out the testing system whenever you wish.

We have 1 destructive database and 1 non-destructive database for the team. (team of only 3)

1st problem
If someone is coding inserts, they need to go against the destructive database. They then are the only one that can go against it.

2nd problem
Team is complaining because they don't want to have to swap the values in the property file and restart the web server every time they go against a different database.

They want the solution of passing in the database name into the data access layer. I tried to explain to them that this defeats what the data access layer is supose to do... remove any database contact from the user of the data access layer. Your thoughts and ideas are appreciated.

Has anyone faced this?? What was your solution.
[ January 10, 2005: Message edited by: Dale DeMott ]
 
author & internet detective
Posts: 41919
910
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dale,
We use local developer copies of the database and therefore don't have this problem. But I do have a few thoughts.

1) Are you using different databases or different schemas? Different schemas would make the problem slightly less. Different database may require datasource changes as well.
2) Why can't you give each developer a test schema? Test databases are typically small. (This solves problem 1.) There are only a few people on my team too, but we'd run into tons of conflicts if we had to share tables. Reproduceable tests are so important that this is worth the small cost.
3) You could provide a method to clear out the cached value in the property file. Just have your tests call that method before running (This solves problem 2.) I've done this in the past for other property files and it works well.

I definitely wouldn't pass the database name into the data access layer. Further, it wouldn't help solve either of these problems. It would just move them further up.
 
Dale DeMott
Ranch Hand
Posts: 515
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, the team wanted to create a method that would be used for test. This method would allow the schema to be passed in for JUnit. They also have another method that gets the value from the property file. This would be used for production. Problem is both are public. I don't like the idea but for now its what we are using. Your thoughts.
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't consider a for-test-only being public a bad idea by definition, but I would be interested in seeing the API (method signatures)...

Regarding your problem about destructive tests clashing between developers, I'd very strongly urge you to consider creating private database schemas for each developer.

By the way, how are you managing the data inside the destructive test database?
 
Jeanne Boyarsky
author & internet detective
Posts: 41919
910
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm less than comfortable with having a "for-test-only" API. Unless it calls the real API, you have a branch of code that isn't being tested. If you take this approach, make sure you are aware of the differences. You certaintly don't want code tested for the first time in production!
 
Dale DeMott
Ranch Hand
Posts: 515
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I quite agree w/you. My team is trying to insist it won't hurt. I believe it breaks a major rule. Quite frankly I am not in favor of it
 
Dale DeMott
Ranch Hand
Posts: 515
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How would you clear out the cached version considering this is a singleton? Do all tests do this or is it something that the test suite does?

Originally posted by Jeanne Boyarsky:
Dale,
We use local developer copies of the database and therefore don't have this problem. But I do have a few thoughts.

1) Are you using different databases or different schemas? Different schemas would make the problem slightly less. Different database may require datasource changes as well.
2) Why can't you give each developer a test schema? Test databases are typically small. (This solves problem 1.) There are only a few people on my team too, but we'd run into tons of conflicts if we had to share tables. Reproduceable tests are so important that this is worth the small cost.
3) You could provide a method to clear out the cached value in the property file. Just have your tests call that method before running (This solves problem 2.) I've done this in the past for other property files and it works well.

I definitely wouldn't pass the database name into the data access layer. Further, it wouldn't help solve either of these problems. It would just move them further up.

 
Jeanne Boyarsky
author & internet detective
Posts: 41919
910
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Dale DeMott:
How would you clear out the cached version considering this is a singleton? Do all tests do this or is it something that the test suite does?


The singleton is what makes it possible! It's something like the following:

In my case, I had each test clear out the cache that was going to read it. This was necessary because they were unit tests and could be run in any configuration.

If you always run the suite of integration tests, you could have the suite call the clearCache()_method.
 
Sasparilla and fresh horses for all my men! You will see to it, won't you tiny ad?
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic