[Proposal] Ignore .env file when running tests

[rogervila]

Hello,

I had a test that was not working on Jenkins, and the problem was that, on my local environment, I had that variable set on my .env file.

If the .env file would not have been read while running the tests, I would have seen the error on my local environment instead of getting a false positive.

I would like PHPUnit to skip the .env file and read only the variables set on the phpunit.xml file, or the ones passed directly via command line, in order to avoid false positives/negatives.

[mfn]

Your Jenkins does not have .env per se. Because it's supposed to be in .gitignore because it's supposed not to be commited.

So the only way you have it there is either a) you commited it, which is a no-go or b) you created one with problematic values.

What I'm saying: by default on fresh checkout there's no .env and you have only available what you set it your phpunit.xml; unless you did something to prevent this.

[rogervila]

Hello @mfn Sorry, maybe I didn't explain it correctly.

The .env file is placed on my local environment and, as you say, is missing on the Jenkins workspace. This is why the test was working on my environment and was failing on Jenkins: there was a missing environment variable.

If the .env file would not have been read while running the tests, I would have seen the error on my local environment instead of getting a false positive.

[mfn]

👍 got your point, sorry. I think it makes sense.

[rs-sliske]

i wouldnt mind having a nice way of controlling where laravel gets its environment variables from (disabling .env file entirely or maybe telling it to use a different file name)

however im not sure i agree with this use case for a couple of reasons

• having environment variables (even ones for dev/test which arent sensitive) in a file thats committed to git causes problems when working in a team. simple things like the database connection details. do you really need to enforce that everywhere the test suite would be ran from would connect to the database on the same port with the same credentials? (im using database connection as example because thats the one ive had this issue with in the past)
• it feels almost like its encouragement to cheat the way through the tests. are you going to commit your production environment variables to git to ensure that you dont forget to set up that environment correctly to? :p i know its very easy to make this sound easier than it is but i feel like its too common to try and make tests pass to get that pretty green light in the readme, rather than to try and learn/fix when/why they fail. you ran your app on a different machine and it failed because of missing environment variables, it wasnt production so that shouldnt really be an issue. now you learnt that your app needs those variables and that they arent there by default with a git pull, and personally i would be looking to ensure those required variables are always set as part of the "deploy" process rather than hiding that they are needed when testing