Level 102
Yeah that should be completely fine. Each member just adds their own .env.testing file and set their own env. Just remember to ignore it it gitignore
Nov 18, 2022
10
Level 1
How to handle testing DB data setup in new project
Hello Guys, We always in team have problem how to set DB data for whole team to be ok and simple. (we dont use dockers and sqlite in memory)
For now we are adding "testing" connection in config.database:
(...)
'host' => env('DB_TEST_HOST', 'localhost'),
'database' => env('DB_TEST_DATABASE', 'testdb'),
'username' => env('DB_TEST_USERNAME', 'root'),
'password' => env('DB_TEST_PASSWORD', 'secret'),
(...)
And then adding it to phpunix.xml:
<php>
<env name="APP_ENV" value="testing"/>
<env name="BCRYPT_ROUNDS" value="4"/>
<env name="CACHE_DRIVER" value="array"/>
<env name="DB_CONNECTION" value="testing"/> <--
<env name="MAIL_MAILER" value="array"/>
<env name="QUEUE_CONNECTION" value="sync"/>
<env name="SESSION_DRIVER" value="array"/>
<env name="TELESCOPE_ENABLED" value="false"/>
</php>
and finally each team member set his own credentials via .env file variables
DB_TEST_DATABASE=xxx
DB_TEST_USERNAME=xxx
DB_TEST_PASSWORD=xxx
and Im not sure if this is the best way.
If you know better/other way to do this then I'm very interested in your opinion :)
Thank you! K
Level 1
@Sinnbeck thank you for your answer. .env.testing is for me a bit over loaded option and in the past we have problems with this, because when some variables are added to project env file (during project development) in most cases devs dont remember to add them to env.testing.
our current approach is in this area fine because we always working on current set of env configuration parameters.
Level 102
@bor1904 So how would each developer set their own database information if not inside the .env.testing file (I know it can read from the regular .env but often you dont want exactly the same env as when developing) ? If they need to set any env value different than in their normal env, they cannot ?
Level 1
@Sinnbeck as I described above in first post we set test DB access data in .env. In my expirience devs can change testing env file this way that tests finishes as green but on prod env functionality doesnt work (because env parameters was different).
Of course I we assume that dev do everything properly your approach is ok. But in real world this is a place for potential "problems" in my opinions :)
Level 102
@bor1904 they can use both. I do. I have both an env file I use while developing and a env.testing that kicks in when I run tests. But using only env is valid, but can be limiting. All you need to do is to add it to gitignore and each developer can decide for themselves
Level 74
I suggest using a local testing database for each developer instead using a remote shared one. This is to guarantee the data integrity when running your tests.
Level 1
@Tray2 Hello. Thank you for your quick answer but Im not sure what you exactly mean wrote "using a local testing database"
Level 74
@bor1904 I mean a database installed on each developer's computer (localhost)
Level 1
@Tray2 we do this using devs local host DBs.
If its not a problem maybe you can shortly describe how you suggest to do this (add to project unified setup for all team members) Thank you
Level 74
@bor1904 You use migrations and seeders that are hosted on a central git repository. If you don't want to put it on GitHub, you can set up a GitLab server and host it on your intranet. Then a simple update can be done every morning. This article covers some of that https://www.neonscience.org/resources/learning-hub/tutorials/git-setup-remote
Please or to participate in this conversation.