Closed Noogic closed 5 years ago
I can confirm I have this issue too with the same error. Steps to reproduce:
<?php
namespace Tests\Browser;
use Tests\DuskTestCase;
use Laravel\Dusk\Browser;
use Tests\Browser\Pages\HomePage;
use Illuminate\Foundation\Testing\DatabaseMigrations;
class ExampleTest extends DuskTestCase
{
/**
* A basic browser test example.
*
* @return void
*/
public function testBasicExample()
{
$this->browse(function (Browser $browser) {
$browser->visit('/')
->assertSee('Laravel');
});
}
public function testAnotherBasicExample()
{
$this->browse(function (Browser $browser) {
$browser->visit(new HomePage)
->assertSee('Laravel');
});
}
}
The first test should pass, but the second one doesn't and gives you the error above.
@Noogic @davidhemphill do the tests pass when you comment out the DumpWatcher
in your telescope.php
file? Think this might be the culprit.
We've fixed that, will be available next release.
I still get the same error with v.0.1.8.
Is this supposed to be fixed?
@driesvints
Can confirm that commenting out DumpWatcher fixes the problem.
Still occuring in v1.0.5
Edit: Interestingly enough, this fixes one system but doesn't fix another.
@zanechua not for me. In my case, I have to disable this watchers in order to make it work:
Command, Dump, Log, Model, Notification, Query and Schedule
@Noogic
yep agreed. Honestly can't be bothered to try disabling anything to test since it seems to be so random. After upgrading disabling DumpWatcher doesn't work either., but this still exists in the latest revision which is 1.0.6
ping @themsaid
I am experiencing this issue as well, but only when I run all my tests, when run individually, they all pass, when run together only one of them passes. Here is an example of the failure message:
30) Tests\Feature\DailyCheckins\WeeklyCheckinsControllerTest::it_allow_users_to_record_a_weekly_checkin_for_themselves
ReflectionException: Class env does not exist
/var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php:779
/var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php:658
/var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php:609
/var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:735
/var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php:1222
/var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:482
/var/www/html/app/Providers/TelescopeServiceProvider.php:22
/var/www/html/vendor/laravel/framework/src/Illuminate/Support/HigherOrderCollectionProxy.php:60
/var/www/html/vendor/laravel/framework/src/Illuminate/Support/HigherOrderCollectionProxy.php:60
/var/www/html/vendor/laravel/framework/src/Illuminate/Support/Collection.php:455
/var/www/html/vendor/laravel/framework/src/Illuminate/Support/HigherOrderCollectionProxy.php:61
/var/www/html/vendor/laravel/telescope/src/Telescope.php:232
/var/www/html/vendor/laravel/telescope/src/Telescope.php:201
/var/www/html/vendor/laravel/telescope/src/Telescope.php:235
/var/www/html/vendor/laravel/telescope/src/Telescope.php:358
/var/www/html/vendor/laravel/telescope/src/Watchers/QueryWatcher.php:43
/var/www/html/vendor/laravel/framework/src/Illuminate/Events/Dispatcher.php:360
/var/www/html/vendor/laravel/framework/src/Illuminate/Events/Dispatcher.php:209
/var/www/html/vendor/laravel/framework/src/Illuminate/Database/Connection.php:826
/var/www/html/vendor/laravel/framework/src/Illuminate/Database/Connection.php:682
/var/www/html/vendor/laravel/framework/src/Illuminate/Database/Connection.php:635
/var/www/html/vendor/laravel/framework/src/Illuminate/Database/Connection.php:459
/var/www/html/vendor/laravel/framework/src/Illuminate/Database/Connection.php:411
/var/www/html/vendor/laravel/framework/src/Illuminate/Database/Query/Processors/Processor.php:32
/var/www/html/vendor/laravel/framework/src/Illuminate/Database/Query/Builder.php:2595
/var/www/html/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Builder.php:1318
/var/www/html/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php:823
/var/www/html/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php:788
/var/www/html/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php:651
/var/www/html/vendor/laravel/framework/src/Illuminate/Database/Eloquent/FactoryBuilder.php:206
/var/www/html/vendor/laravel/framework/src/Illuminate/Support/Collection.php:418
/var/www/html/vendor/laravel/framework/src/Illuminate/Database/Eloquent/FactoryBuilder.php:207
/var/www/html/vendor/laravel/framework/src/Illuminate/Database/Eloquent/FactoryBuilder.php:181
/var/www/html/tests/Concerns/AttachJwtToken.php:33
/var/www/html/tests/Feature/WeeklyCheckins/WeeklyCheckinsControllerTest.php:20
Which version of Telescope fixed this @themsaid? It seems to still be present in version 1.0.7
.
Using Laravel 1.0.7
my dusk tests pass. Why do you have Telescope enabled while running Dusk tests?
I am using 1.0.7
and both my Dusk tests and my PHPUnit tests are failing, but as @foxted said, only when I run them all and not when I run them individually. Actually it's the second test and all trailing tests which fails (so the first passes, and then the rest fails).
I have installed Laravel Telescope in production (so composer require
instead of composer require --dev
) and when testing locally then I am running both PHPUnit tests (vendor/bin/phpunit
) and Dusk tests (php artisan dusk
).
What commit should have fixed this @themsaid?
setting TELESCOPE_ENABLED=false
in my .env.dusk.local
or .env
solved the issue.
Not sure this is really an issue but maybe needs to be documented.
@bilfeldt disable Telescope while running your tests as @mikeminckler suggests.
The problem before was a cache key stored very early by dusk and causing Telescope::filter
callback to be invoked and by this time there's no access to the environment available.
I agree with @mikeminckler that this should probably be documented especially with such a breaking incompatibility.
Thanks for the explenation @themsaid and @mikeminckle, so here is what I did for PHPUnit:
Only register the TelescopeServiceProvider
when the environment is not testing
this is done in app/Providers/AppServiceProvider.php
as such:
/**
* Register any application services.
*
* @return void
*/
public function register()
{
if ($this->app->environment() != 'testing') {
$this->app->register(TelescopeServiceProvider::class);
}
}
This works since PHPUnit sets the APP_ENV=TESTING
as described in the documentation. An alternative solution could be to add TELESCOPE_ENABLED=false
to the phpunit.xml
file.
For Dusk
I simply added the TELESCOPE_ENABLED=false
to the .env.dusk.local
as suggested by @mikeminckle
Even though this solves the issue, I don't really think this is a viable solution. This means that all of our tests are only run without Laravel Telescope, but our production server will be running with Laravel Telescope. Does anyone know what is causing this?
You could just add <env name="TELESCOPE_ENABLED" value="false"/>
to the phpunit.xml
-file.
@Livijn just as proposed here:
An alternative solution could be to add TELESCOPE_ENABLED=false to the phpunit.xml file.
But my concern is still that this means Laravel Telescope is disabled while we are running Dusk or PHPUnit tests, but in production Laravel Telescope is running, so the tests are no longer valid as I see it.
I add TELESCOPE_ENABLED=false to my testing environment file and it's work fine. Thanks
I add TELESCOPE_ENABLED=false to my testing environment file and it's work fine. Thanks
What about dusk tests. I am still getting a lot of problem with dusk tests even after adding this flag
this is still happening on 1.0.7
@Livijn's solution works good. This is not only causing Dusk tests to fail but also regular phpunit tests
Wish this was documented, or the line should be added to the phpunit.xml file when running telescope:install
v5.7.16
v1.0.8
phpunit
ReflectionException: Class env does not exist
Just needed an hour or so to figure this out :unamused:
@themsaid can't anything be done about this? it's affecting all new installs for those of us that use tests
See the installation docs. Not sure if it was always there but solved my issues.
Installing Only In Specific Environments
Remove it from config/app.php and only allow it to be included on the environments you want it.
eg
if (! $this->app->environment(['dusk', 'testing'])) { $this->app->register(TelescopeServiceProvider::class); }
@mvdnbrk Another example (as happened to me):
phpunit
- all tests passphpunit
- ReflectionException: Class env does not exist
While this is easy to fix (either with TELESCOPE_ENABLED=false
in phpunit.xml
or, as @lionslair mentioned, in AppServiceProvider
) the first impression certainly isn't great.
I ran into this same issue when updating packages with composer update
in one of my projects.
This updated Telescope from v1.0.6 to v1.0.8.
Run phpunit
and everything blows up with ReflectionException: Class env does not exist
.
This can be really confusing to figure out that this is caused by Telescope.
This seems to be introduced since version 1.0.7.
My issue only occured with dusk. I was able to run individual dusk tests but not a file or directory. Threw that "ReflectionException: Class env does not exist." and also malformed corrupted database.
After removing the service provider from app/config.php and loading it when not in testing and dusk environments problem was instantly solved. But took a few weeks to work out. Was aware it started as soon as telescope was added though but WHY is still unknown. I guess it's to do with bootstrapping or something.
This issue has been driving me up the wall for hours.
As suggested by @Livijn , by adding <env name="TELESCOPE_ENABLED" value="false"/>
to the phpunit.xml
file it fixes this issue.
@themsaid since this is an issue with a fresh install of laravel + laravel/telescope, would it be possible to have this note in the official documentation in laravel website? Thanks a lot for the great work and support 😃
IMHO this should be the default configuration of phpunit.xml
. Either that or upon installation of Laravel Telescope, it should be added automatically.
It probably needs to be documented too.
This was a very hard to diagnose issue, at least for me. I googled for hours and didn't find this specific issue until very late in my attempts.
I'll look into making a PR for this if no one else beats me to it.
the
Also dusk appears to create its own phpunit xml file. Did not solve the issue when I added it there either.
I am still having this exact issue as well. Laravel 5.7.16 and Telescope 1.0.9 . I have TELESCOPE_ENABLED=false
set in phpunit.xml
, phpunit.dusk.xml
, and .env.dusk.local
. I am only only registering the TelescopeServiceProvider
if the environment is not dusk
or testing
and I am still getting the error.
UPDATE:
I was able to fix it by including in my test file Laravel\Telescope\Telescope and in my setUp method Telescope::stopRecording()
. It seems that Telescope continues to monitory queries even if it is disabled.
Temporary solution, set:
'enabled' => env('TELESCOPE_ENABLED', env('APP_ENV') !== 'testing'),
in telescope.php
+1 for documenting.
TELESCOPE_ENABLED=false
in .env.testing
works for me.
I've runned
php artisan clear
php artisan config:clear
Solved for me
You could just add
<env name="TELESCOPE_ENABLED" value="false"/>
to thephpunit.xml
-file.
This worked for me like a charm
Two Solutions:
Solution One: (mentioned several times above):
phpunit.xml
<env name="TELESCOPE_ENABLED" value="false"/>
Solution Two:
.env
to .env.testing
.env.testing
TELESCOPE_ENABLED=true
to TELESCOPE_ENABLED=false
If Testing With Dusk:
.env
to .env.testing
.env.testing
TELESCOPE_ENABLED=true
to TELESCOPE_ENABLED=false
.env.testing
to .env.dusk.local
None worked for me.
I have manually paused monitoring from /telescope
dashboard and it worked.
adding TELESCOPE_ENABLED=false to my .env solved the problem
I am not using Dusk and this error still persist in some tests. This should definitely be documented.
just ran into this issue, can't telescope check if testing
?
<env name="TELESCOPE_ENABLED" value="FALSE" />
added to my phpunit.xml
What if I want to track a single test with telescope ?
just ran into this issue, can't telescope check if testing?
added to my phpunit.xml
I still have this issue with Laravel 5.8 and Telescope 2.0.2.
Obviously, disabling stuff for tests is a terrible workaround. If Telescope would cause any errors in production, they wouldn't be caught, and the application would crash once deployed.
Please create a fix for this.
I noticed it was still somehow getting involved. In order to stop it I'm only allowing the service provider to get loaded for the environment I want it. Seems to be the best solution. Using the disable flag still does nothing
Sent from my mobile
On 27 Mar. 2019, 6:10 pm, at 6:10 pm, Wouter Florijn notifications@github.com wrote:
I still have this issue with Laravel 5.8 and Telescope 2.0.2.
Obviously, disabling stuff for tests is a terrible workaround. If Telescope would cause any errors in production, they wouldn't be caught, and the application would crash once deployed.
Please create a fix for this.
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/laravel/telescope/issues/347#issuecomment-477076681
I was getting the same error, and even with TELESCOPE_ENABLED=false
in phpunit.xml
it didn't work. I only got the tests to pass after runnnig php artisan optimize:clear
first.
Has this issue been solved? I am still having this issue with Laravel 5.7.28 and Telescope 1.2.
Update phpunit.xml or .env files works for me. But I would rather not doing so.
If anyone else gets confused like I did about where to put the env variable in phpunit.xml, it goes inside the php tag.
<phpunit>
<php>
<env name="TELESCOPE_ENABLED" value="false"/>
</php>
</phpunit>
Why is this closed? Lots of people are still having this issue.
Update for those still experiencing this issue, if you commonly run config:cache
while developing, the suggested solution of adding TELESCOPE_ENABLED=false
to phpunit.xml
will only actually work if you run optimize:clear
.
I commonly run config:cache
during dev, should cached config take precedence over phpunit.xml
? Is this something that can be checked when running tests? Not sure if this the intended behavior @taylorotwell @themsaid ?
So first, config:clear
fixes the error for me.
Regarding config:cache
- I actually inherited an app where config:cache
could not be run without error, so now that I have fixed that -- I am hoping my tests CAN test against the config:cache
values to prove through testing that the cached config does not break anything. Based on all this though, so far it seems you cannot do a config:cache
and then run tests without this error. :(
After installing Telescope, all my Dusk tests are throwing this error:
The only "test" that is passing is the login test.
I'm using laravel version v5.7.12 and phpunit tests are working well, only dusk is failing.