Re: Migrating Code From Test to Production: How to do it right, how to set up an environment that leaves nothing to chance

[Herkum]

in reply to Migrating Code From Test to Production: How to do it right, how to set up an environment that leaves nothing to chance

I wrote a bunch of tests that depended on a database for holding my data. The tests deleted all the rows from the tables that I was working with and then inserting the test data into the tables. If I did this against the production database I was going to delete the production data as well, that would be bad.

I decided to have a production and a test database. I wanted something that would be easy to include in my test code and would not require a major change in production code. I thought, if I am working with my test modules I make my DB connection code look like this what would I have to do.

use Base::DB::Connect 'test';

The only thing I had to do was include a import subroutine/method. It changed the $database variable from 'Prod' to 'Test' and I was done! I was happy because I did not have to change the code to support 'Test' and 'Production' as separate environments.

[tphyahoo]

What is an "import" subroutine? Why did you boldface this term? Does it have a special meaning?

What terms do I search the web on to learn more?

[Aristotle]

It has to do with the use function, which is really just syntactic sugar. One of the things it does is to call the static import method on the package you’re loading, passing it the parameters you gave on the use line to process them. The common behaviour of import is to export functions from the package it’s in into your current one, usually by calling upon Exporter. However, all of that is entirely conventional, and you can actually do whatever you want with those parameters – like using them as a names for configurations to choose between, as Herkum does.

The use docs have the details.