in reply to Established convention for testing using mysql?

What I do is to have my app's database initialization code create two (structurally) identical databases, appname and appname_test. My tests are then written to run against appname_test, which shouldn't have anything else using it, so there's no concern that I might clobber meaningful data. This also allows the tests to use the same connection information (modulo appending a _test to the db name) and credentials as the real app, which both simplifies things and will also cause the tests to catch any problems that may come up with connecting to the db in the first place.

As far as the MySQL vs. SQLite concerns, I get the impression that you're only including SQLite for testing purposes and using MySQL for the real app. If this is accurate, then I'd say to drop SQLite. Tests work best when they're running as much of the same code as the real app as possible and setting up a duplicate _test db allows them to safely use the exact same db handling code.

  • Comment on Re: Established convention for testing using mysql?

Replies are listed 'Best First'.
Re^2: Established convention for testing using mysql?
by roboticus (Chancellor) on Jan 13, 2008 at 12:55 UTC
    I (often) use a variation of this. I create a version of the database loaded with all my test cases, then copy that database on top of the test database at the beginning of each test run, so the tests may be as destructive as they like to the database. When I discover a new data variation in the production data, I create a test case in the prototype database....

    (Yeah, I know I should use Mock objects, but I've never been comfortable with them...)

    ...roboticus