You may be running a critical job that should only have one instance running at a time. That’s where withoutOverlapping() ensures that a scheduled task won’t overlap, preventing potential conflicts.
<?php namespaceApp\Models; // use Illuminate\Contracts\Auth\MustVerifyEmail; useIlluminate\Database\Eloquent\Factories\HasFactory; useIlluminate\Foundation\Auth\UserasAuthenticatable; useIlluminate\Notifications\Notifiable; usePHPOpenSourceSaver\JWTAuth\Contracts\JWTSubject; classUserextendsAuthenticatableimplementsJWTSubject { useHasFactory, Notifiable; /** * The attributes that are mass assignable. * * @var array<int, string> */ protected$fillable = [ 'name', 'email', 'password', ]; /** * The attributes that should be hidden for serialization. * * @var array<int, string> */ protected$hidden = [ 'password', 'remember_token', ]; /** * Get the attributes that should be cast. * * @return array<string, string> */ protectedfunctioncasts(): array { return [ 'email_verified_at' => 'datetime', 'password' => 'hashed', ]; } /** * Get the identifier that will be stored in the subject claim of the JWT. * * @return mixed */ publicfunctiongetJWTIdentifier() { return$this->getKey(); } /** * Return a key value array, containing any custom claims to be added to the JWT. * * @return array */ publicfunctiongetJWTCustomClaims() { return []; } }
# Set up `.env.demo` cp .env .env.demo echo "\nEXAMPLE_SETTING=demo" >> .env.demo # Use the `demo` env php artisan tinker --env=demo # Or set APP_ENV APP_ENV=demo php artisan tinker
如果查询到, Laravel 会加载 .env.demo 文件而不是 .env 文件。
在 PHPUnit 测试中使用 .env.testing
Building on what we know about the Laravel framework loading a specific ENV file if it exists, running Laravel feature tests in PHPUnit will use the .env file by default. Using .env for tests and local development could quickly cause issues such as configuring a separate database for testing. You could define database connection details in phpunit.xml, but let’s also look at setting them in .env.testing.
PHPUnit defines an APP_ENV environment variable in phpunit.xml, which means that Laravel looks for a .env.testing file when bootstrapping Feature tests because the phpunit.xml file defines APP_ENV before the Laravel framework gets bootstrapped in Feature tests:
1
<envname="APP_ENV"value="testing"/>
That means we can copy the stock .env file to .env.testing and avoid mixing the two files during testing:
You can configure environment variables in phpunit.xml. However, I like using the .env.testing file to ensure a clean environment specifically for testing. It’s also up to you whether you version control .env.testing or ignore it in .gitignore.
After copying the .env file, you can verify that .env.testing is loaded by adding the following to a test in your tests/Feature folder. Tests in the tests/Unit folder won’t bootstrap the Laravel framework:
1 2 3 4 5 6 7 8 9 10 11 12 13
/** * A basic test example. */ publicfunctiontest_the_application_returns_a_successful_response(): void { logger('Which environment file is Laravel using?', [ 'file' => $this->app->environmentFile() ]); $response = $this->get('/'); $response->assertStatus(200); }
When I run phpunit, I get the following log confirming that I’m using the .env.testing file:
1
[2024-05-24 00:22:42] testing.DEBUG: Which environment file is Laravel using? {"file":".env.testing"}
If you ignore this file in your VCS, you could add an example file .env.testing.example with your team’s conventions or let them decide how to configure tests locally. I recommend setting system-level environment variables in CI to configure things like test databases.