this line is wrong for many reasons

$this->assertNotEquals(0, Session::whereUserId($this->user->id)->count());

not only will it fail for any other session driver than database, but you shouldn't be testing framework internals at all. What your test should care is if user is authenticated or not after hitting each endpoint, not if the internal framework session handling works.

Writing to the DB on every single request will definitely crush your database once you start seeing real traffic.

That's a massive hyperbole, unless your definiton of "real traffic" is thousands of requests per second. And then you're hitting other bottle necks first.

If Laravel accesses the DB during each request, e.g. by pulling a user model, the additional cost of updating a single timestamp is minimal. Most of the overhead comes from establishing a database connection.

I think it depends on how often you end up doing this, and for the given case this is fine. Manipulating data in migrations is fine depending on the complexity and occurrence but I have seen this go wrong when you overdo it, now the new team member can't setup their local db bc the migrations are a mess.

The data you updated turned out to have a bug so now you either need to revert the migration on prod to run it again or create a new migration with no schema changes and just data updates.

Data updates are much more likely to fail midway due to data complexity of production and edge cases than predictable schema changes and now your production is down with half ran migrations.

A safer way would be a multi step migration/deployment (where possible assuming you have the time and resources)

First you change the schema to support both options, (like having the col nullable, adding a secondary column without removing the original, etc) and the business logic to fill new entries, while supporting old entries for now.

The second step would be to create a command to migrate the old data to the new structure.

And the third step, after you verify all data follows the new requirements, make the schema change the only option and fully deprecate the old logic, (like making the col non nullable, remove the command of step 2, deprecate old logic, etc)

I have some thoughts against that.

Manipulating data in migrations makes sense on production only.

Migrations are "replayable" - they are applied one after another many times during development and testing. You can launch php artisan migrate:fresh hundred times while developing on your local dev machine. If you have data manipulation inside one of your migrations which data is actually manipulated on dev machine? And why? Testing/dev data is seeded many times (and AFTER all migrations, not among them), it doesn't need to "evolve" along with migrations.

To have "data migration" properly tested I have to seed database with various sets of data instead of only latest version. I have to track different data sets to always match with different DB schemas/migrations. I don't think this is worthwhile.

Therefore, I wouldn't place data manipulation inside migration. Instead I would use Artisan command which is launched manually on production only and one time only, after a corresponding migration is applied.

This package offers something similar: https://github.com/TimoKoerber/laravel-one-time-operations

Quote from description:

This package is for you if... ... you often seed or process data in a migration file (which is a big no-no!)

why not just unset those two keys in this component and not touch the rest? having to alter the rules to fit everything feels like a hack to me.

you shouldn't need to add 'sometimes' to your global rules, the place where the rules are used can decide what to do with the rules in it's particular case, like how and where to apply them.

->paginate(20) makes ->limit(100) redundant