A Web Developer’s Blog
I am working on an application that needs to be able to login to a Laravel instance via API.
In my usual workflow all the session management and XSRF protection has been automagical but I needed to be able to build a test case - and all the docs seemed to assume it would “Just Work™”
Read more ...
Laravel’s database migrations is a great system and makes it easy for the development team to stay in sync with schema changes as well as ensuring tests can run against a defined database state.
It also makes great use of transactions to efficiently roll back changes after each test
But what if you have some large tables of fairly static data that you don’t want to reload on every test run …
Something didn’t quite click with me about Laravel Eloquent Models.
There is nothing in the Model that defines the fields.
The Model defines which database table the data is stored in.
Whatever fields are in the table will be loaded to the Model.
I wanted to better understand what is happening when I run Laravel tests that hit the database.
TLDR: Database migrations are run on every test run, optionally with seed data.
Each test case runs in a transaction.
(This is written based on Laravel 9)
How to get code coverage reports from PHPUnit to Sonarqube
I started already having an environment using docker-compose but without xdebug the unit tests couldn’t generate coverage reports.
Read more ...