Testing and Environment Variables

phillup on 2004-07-22T17:50:44

Here is the "problem of the moment":

I'm writing tests for some web modules and I've broken the test down into separate files for testing separate things. Now, this is the backend code for a web app and the whole process is started by logging in. This sets up a session with a SID that is passed back to the user and is used in the future to re-establish the session. Pretty standard stuff.

So, what I want to do is create the session in one test file and run some tests... but, I want to store the SID into the %ENV for the next test to use and re-establish the session.

The kicker seems to be that I'm using Test::Harness to drive the testing and it seems to fork off each test, so changes to %ENV aren't propagated to the next script.

I've also tried setting (and exporting) the environment via the system command using every variant I can think of and I keep getting something along the lines of "export file not found".

Now, I know that export is specific to the bash shell so my first thought was that the test aren't even running in a bash shell, even tho I am. Is this true?

So, I changed my system command to:

system ("/bin/bash export GB_TEST_SID=$sid");

Which I thought would at least not cause the error... and... it still reports:

export GB_TEST_SID=: No such file or directory

So, how do I set the environment variable in one test script to be read in the next one when Test::Harness is running the test scripts?

Or, more generically... how do I set an environment variable in Perl and have it persist (in the shell environment) after the program exits?

(And... I don't wish to imply that this is the fault of Test::Harness. It seems to be an issue of running each script in a separate child process.)

---

UPDATE:

I wanted to take Perl out of the equation for a moment to confirm it was a child process issue... I did this at a bash prompt (comments inserted):

#show the current env
phillip@prometheus:~$ echo $MY_TEST

# launch a child shell
phillip@prometheus:~$ bash
phillip@prometheus:~$ ps
  PID TTY          TIME CMD
28108 pts/12   00:00:00 bash
28119 pts/12   00:00:00 bash
28124 pts/12   00:00:00 ps

# export and confirm
phillip@prometheus:~$ export MY_TEST="hello world"
phillip@prometheus:~$ echo $MY_TEST
hello world

# launch a child from the child
phillip@prometheus:~$ bash
phillip@prometheus:~$ ps
  PID TTY          TIME CMD
28108 pts/12   00:00:00 bash
28119 pts/12   00:00:00 bash
28125 pts/12   00:00:00 bash
28130 pts/12   00:00:00 ps

# check the environmnet... it works
phillip@prometheus:~$ echo $MY_TEST
hello world

# exit the child of the child
phillip@prometheus:~$ exit
exit

# reconfirm env still set
phillip@prometheus:~$ echo $MY_TEST
hello world

# exit the child... now back in the parent
phillip@prometheus:~$ exit
exit

# and test the env
phillip@prometheus:~$ echo $MY_TEST

phillip@prometheus:~$

It looks to me like there isn't a way to set the environment in a child and then have it present in the next sibling.

So... back to the drawing board.

BTW, I'd still like to know why my system command above returned an error... if anyone knows.

TIA

---

children messing with their parents

rjbs on 2004-07-22T19:33:16

A child can't muck with a higher-level process's environment. It's part of the joy of unix!

Having sequential siblings mess with environment is usually something like:

in script0:
  eval `script1`
  eval `script2`

script1 prints out bash commands like "export FOO=bar" which the running then evaluates into its own environment, leaving it there for script2 to see.

In brief: the environment is not a good way for children to perform IPC.

Use Module::Build-notes

autarch on 2004-07-22T21:14:11

Module::Build has a feature that helps with this, the notes() method. You can get the Module::Build object inside your tests. This is really handy.

Re:Use Module::Build-notes

phillup on 2004-07-22T21:56:16

That does look handy... thanks!

I just really wish I'd started with this (and the tests!!) two years ago when I started writing the modules!!

The customer wants some pretty significant changes and I've convinced them that we need some tests to insure that the functionality doesn't degrade with all of the changes... so... I'm basically backporting tests into the system while trying to provide new features.

And, the new features are needed soon (of course).

Yuck.

(OK... enough complaining. Back to work.)

Again, thanks!