You probably noticed that in app/config/database.php by default two database connections are defined: “default” and “test”. Even though “test” is not used often, it is clear for what it is thought: to define a database connection for testing purposes. But I am not quite sure whether you really need such a dedicated database connection for testing. To me it looks like unnecessary overhead. Wouldn’t it be easier to use the “default” connection on the development machine for testing purposes, and on the live server for the real database? What do you think about it?
A test database makes perfectly sense, as you will produce tons of data that also may be incorrect – you want to test everything, right?
So, you have a database for application testing on your development setup and a test database that you can clear each time you do a test and write a lot of nonsense into it.
As long, as there is no “virtual” database connector in Cake, which is able to read fixtures out of a file, but works like a normal database, I would not like to miss the test database.
But the best way is to have two installations of cakephp !
One for your development, with, as default database, the test database.
And the production one, with the production database as default.
With that solution, only one database is needed in your configuration.
The two connection presets come in handy for me personally as i test on my local machine and then deploy on my production server.
The username/passwords are more often than not different for the 2 databases (although they typically share the same name). Having the 2 different set ups makes it easy to facilitate this.
You might have to test functionality that sends a message to a series of email addresses that are in your db. If you setup a test db with false email addresses, your tests won’t go out into the real-world.
Yes, definitely!
My company uses svn and we all work remotely, so everyone checks out the entire app and runs it on their local machine. We have an app_model.php file in /app that checks to see what the host is (everyone edits their host file, so my computer is walker.dev and yours would be daniel.dev, etc) then it uses the db config matched up with that hostname
$walker = array(….)
$daniel = array(….)
etc
Then default is set to whatever the production environment will be. That way, everyone can continue to develop and easily deploy even after the first version of the app has gone live.
I think it depends on how the test config is used. As mentioned at http://joelmoss.info/switchboard/blog/1978:Cakes_easypeasy_database_config I use it in the same way as Walker does. I develop on my local windows machine and deploy to my linux server.
Using the method described in my post above, I never nead to modify the database.php once it is setup.
@all: Thanks for your comments. It seems you guys work quite different then I do. So my decision to use a different database configuration file for the test suite was not that bad ;-)
I never used, certanly. If I want to switch the database I just overwrite database.php.
heya cakebaker!
my 2 cents: i have the same opinion, im my projects i use the $default database for the development, this make my deploys more simples, because i dont have to change any code im my apps, just a ftp “put” =:]
btw, the Joel Moss´s solution it´s a nice aproach to this situation
Actually I think it’s a MUST to have two connections on your development server, and one on your live server. This is how I do it:
Live server has one database, one connection
Dev server has two databases, two connections. Default connection is what’s used for development work and such, daily use. Before shipping code to the live site, I take a dump of the live, production database, and import it into my development ‘test’ database, switch modes, and do one final run-through on a clean, yet valid database with the code I’ve just written – testing every feature I’ve modified (and if I have time those i haven’t – just in case!)
That way I’ve so far (fingers crossed) never had a hiccup with moving code to the production server
@KesheR, RoadHouse and James Booker: Thanks for your comments!
@RoadHouse: I used some time ago a similar approach as described by Joel Moss. But in the meantime I use a different approach: I have two branches (trunk and live) in my repository, in trunk I have the database configuration for my local environment, and in the live branch I have the configuration for the live server. So I do not have to add any logic to switch the database configurations.
@James Booker: Yeah, that’s the way I worked up to now. But now I am trying to move to an approach that uses only one connection on the dev server as I use the second connection rather seldom.
Well
With two branches it’s more easily to liberate small release, following the web2.0 principles