Level 4
@nikospkrk have you made sure that your tests are not using the DatabaseMigrations trait?
Mar 14, 2016
6
Level 19
Seeding in memory tests only once in 5.1
I need to seed my tests only once, unfortunately I cannot get it done with sqlite :memory: feature.
To do so my idea was to create a custom bootstrap file to run the migration command once only:
passthru('php artisan -q migrate --seed --env="testing"');
require __DIR__.'/autoload.php';
Which is working as expected, but unfortunately my tests don't see anything in the sqlite memory database, so it gets flushed at some point, but when and how can I avoid this behaviour ? My real question here I guess is how does this :memory: database is handled ?
I've also looked into using the sqlite file but that takes way too long to generate even only once that it's not worth it.
Level 19
@ifpingram yes, no trait used regarding DatabaseMigrations or DatabaseTransactions.
Level 4
@nikospkrk In that case I guess the :memory: sqlite will get refreshed after each test, as it is in memory. Have you tried it with file based sqlite, or postgres/mysql?
Level 19
@ifpingram yes I know, but I'd like to know how this :memory: is supposed to work indeed, as the sqlite might be an option but is way too long to bootup once each phpunit call.
Level 4
@nikospkrk well, as per the SQLite docs, the in memory database only lasts the duration of the connection. As the createApplication() method of Laravel's TestCase bootstraps a new instance of the Laravel Kernel for every test (as part of the setUp() method of Illuminate\Foundation\Testing\TestCase, then the connection will never persist between tests.
You may be able to hack something together with the "In-memory Databases And Shared Cache" or "Temporary Databases" from the SQLite docs above, by opening a connection to this in the constructor of your TestCase, so that it keeps a connection open for the duration of the TestSuite run, but I've never tried such a thing before, and you may need to also hack Laravel too to achieve this...
Good luck!
Level 19
@ifpingram Thank you for the reply, that's really helping, although I should have try to look for the SQLite docs myself !
The "Temporary Database" solution is actually just the in memory one with a file fallback in case there's not enough space in memory available, and has the same behaviour as the in-memory one, so that's not an option. On the other hand, the "Shared Cache" option is worth a try although I fear the first migration will get erased before I hit any test, but I'll try to find a solution tonight once I'll get back home. If none of them work then I guess I'll have to use the (SQLite) file option and just refresh the database everytime my migrations or my seeds change, which is not ideal but will still be faster than running the migrations and seeds on every single integration test I think.
Cheers!
Please or to participate in this conversation.