This is a simple issue that does not require something like dbunit to
solve, in my opinion. You are looking for profiles.

Use a profiles.xml file checked into your SCM with activations based
on the OS user name or machine name. So you'd have settings for each
of your developers plus the CI server all checked into one
profiles.xml file that is checked into SCM along with the rest of your
source files.

Then when the CI server runs the database tests, it would
automatically utilize those values to connect to its own local
database. And your developers would insert their own values into their
section of the profiles file with their own database instance values.

Wayne

On 5/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Have a look into dbunit:

http://dbunit.sourceforge.net

We have similar issues with classes relying on stuff from a database and
we dynamically pick a different implementation to point at data access
object implementations picking up dummy data

You should also define a TestSuite and pass it into your CI system to only
run those testcases that can be run automatically instead of simply
running every test case inside your test directory.

-j

---------------------------------------------------
Justin Fung
[EMAIL PROTECTED]
Sr. Analyst, Business Systems
IT Banking Systems, e-Business
HSBC Bank Canada
http://www.hsbc.ca
p: (604) 643-6605
f: (604) 643-6727








Kris Nuttycombe <[EMAIL PROTECTED]>
05/19/2006 10:08 AM
Please respond to "Maven Users List"


        To:     Maven Users List <users@maven.apache.org>
        cc:
        Subject:        Best practices question - junit/database/m2/continuum

      Our Ref:
            Your Ref:


Hi, all,

Here's my problem: much of the code that is written in my organization
makes extensive use of vendor-specific database features (such as
spatial data types, etc.) In order to unit test our code, we obviously
need to be able to configure the database connection information, which
we are doing using filtering such that each developer has a locally
configured filter file that is not checked in to subversion.

The problem arises when running the tests using continuum - since we
don't want to check the connection information into source control
(which we may want to have externally visible), it's not available when
continuum checks out the project. Is there any set of best practices for
how to deal with this issue? Since we're using vendor-specific features,
we cannot use an in-memory database for the tests, as I would have
preferred.

Thanks,

Kris

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to