Summer Sale! All accounts are 50% off this week.
Hello, we have internal discussion in our team about testing enviroment.
Especially if database on which tests are running should be clear on start? or tests should automatically migrate/seed DB before start? or this is developer/CICD responsibility to prepare database "manually" in step before test starts?
How this process looks in your organizations or in your expirience ?
Thank you
I suggest viewing some videos on testing from here.
I only test to see where I can refactor code. Most other test technically don't tell you a lot. If they did, then why are there failed test yet app works correctly in real World.
How do you "test the test.
Then you would have to test the test that test the first test.
It can get ridiculous. I suggest just some test looking for places to refactor.
When I first started, I used a dummy database to start each test with live data filled in. It had some advantages, mostly that it was easy to start running tests from it and have it reset between each test (That was using the old DatabaseTransactions trait, which essentially reset the database to the state it started at).
A few years later, I moved to a "Tests start with empty migrations, and just build the world you need for each test" paradigm, which broadly I like. It has the benefit of allowing you to essentially just run your migrations, and then have each test suite be responsible for adding the bare minimum of data needed for those tests.
As much as I typically agree with jlrdw's posts, I fall into the opposite camp of testing... Every app I've built over the last 10 years or so has been heavily tested, probably over-tested... but it's saved me a ton of headache over the years, being able to quickly identify errors that I wouldn't have caught on my own.
For years, I've had all of my new developers do the first ~30 lessons in this series: https://laracasts.com/series/lets-build-a-forum-with-laravel
It's still one of my favorite resources on testing (that and the fantastic Adam Wathan TDD series), though admittedly I haven't looked at the newer entrants into the market (JMac's series, Mateus Guimarães series, or Christoph Rumpel's new series).
My suggestion for you re: database setup at the start of tests.... If you're primarily unit testing, then use a clean database (or no database). If you're feature testing (IE testing that complex behavior on a Livewire component works), then try to get as far as you can with the clean database, and consider using a Seeded database only if you find that the test setup is getting more complex than the tests themselves.
In one of my projects right now, at about 1,500 tests, we're likely going to move to some Seeding for some tests... The hard part about that is that it's one more thing to keep up to date (ie your seeds can get out of date as you update your migrations / database), which is why I've worked to avoid them for as long as possible.
Please or to participate in this conversation.