Best Practice For Testing Against Databases

[Dale DeMott]

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 ]

[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.

[Dale DeMott]

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 coderanch. I don't like the idea but for now its what we are using. Your thoughts.

[Lasse Koskela]

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]

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]

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]

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]

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:

public class MyProperties {
  private static MyProperties singleton;
 
  public MyProperties getSingleton() {
    // logic to instantiate singleton as appropriate
    return singleton;
  }
 
  public static clearCache() {
    singleton = null;
  }
}

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.