laravel / telescope

An elegant debug assistant for the Laravel framework.
https://laravel.com/docs/telescope
MIT License
4.83k stars 577 forks source link

ReflectionException: Class env does not exist #347

Closed Noogic closed 5 years ago

Noogic commented 5 years ago

After installing Telescope, all my Dusk tests are throwing this error:

1) Tests\Browser\PatientsTest::it_can_create_a_patient
ReflectionException: Class env does not exist

/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Container/Container.php:779
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Container/Container.php:658
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Container/Container.php:609
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:733
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Container/Container.php:1222
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:497
/Users/noogic/data/projects/fisio/app/Providers/TelescopeServiceProvider.php:22
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Support/HigherOrderCollectionProxy.php:60
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Support/HigherOrderCollectionProxy.php:60
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Support/Collection.php:442
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Support/HigherOrderCollectionProxy.php:61
/Users/noogic/data/projects/fisio/vendor/laravel/telescope/src/Telescope.php:206
/Users/noogic/data/projects/fisio/vendor/laravel/telescope/src/Telescope.php:179
/Users/noogic/data/projects/fisio/vendor/laravel/telescope/src/Telescope.php:209
/Users/noogic/data/projects/fisio/vendor/laravel/telescope/src/Telescope.php:233
/Users/noogic/data/projects/fisio/vendor/laravel/telescope/src/Watchers/CacheWatcher.php:63
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Events/Dispatcher.php:360
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Events/Dispatcher.php:209
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Cache/Repository.php:486
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Cache/Repository.php:92
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Cache/CacheManager.php:323
/Users/noogic/data/projects/fisio/vendor/laravel/telescope/src/Watchers/DumpWatcher.php:43
/Users/noogic/data/projects/fisio/vendor/laravel/telescope/src/RegistersWatchers.php:48
/Users/noogic/data/projects/fisio/vendor/laravel/telescope/src/Telescope.php:94
/Users/noogic/data/projects/fisio/vendor/laravel/telescope/src/TelescopeServiceProvider.php:27
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php:29
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php:87
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php:31
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Container/Container.php:572
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:793
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:776
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:777
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/BootProviders.php:17
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:206
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php:297
/Users/noogic/data/projects/fisio/tests/CreatesApplication.php:18
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Foundation/Testing/TestCase.php:91
/Users/noogic/data/projects/fisio/vendor/laravel/framework/src/Illuminate/Foundation/Testing/TestCase.php:68
/Users/noogic/data/projects/fisio/vendor/laravel/dusk/src/TestCase.php:23
/Users/noogic/data/projects/fisio/tests/Browser/PatientsTest.php:16

The only "test" that is passing is the login test.

<?php

namespace Tests\Browser;

use App\Entities\Patient;
use App\Entities\User;
use Database\Builders\PatientBuilder;
use Tests\Browser\Pages\Login;
use Tests\DuskTestCase;
use Laravel\Dusk\Browser;

class PatientsTest extends DuskTestCase
{
    /** @test */
    function login()
    {
        $this->browse(function (Browser $browser) {
            $browser
                ->visit(new Login)
                ->signIn()
            ;
        });
    }

    /** @test */
    function it_can_create_a_patient()
    {
        $this->browse(function (Browser $browser) {
            $browser
                ->pause(200)
                ->visit('/patients')
                ->resize(1024, 768)
                ->waitFor('@patients.create.showForm')
                ->press('@patients.create.showForm')
                ->waitFor('@patients.create.form')
                ->type('@patients.create.name', 'test patient')
                ->type('@patients.create.email', 'tp@test.com')
                ->press('@patients.create.submit')
                ->pause(400)
            ;
        });

        $this->assertDatabaseHas('patients', ['name' => 'test patient', 'email' => 'tp@test.com']);
    }

I'm using laravel version v5.7.12 and phpunit tests are working well, only dusk is failing.

davidhemphill commented 5 years ago

I can confirm I have this issue too with the same error. Steps to reproduce:

  1. Create a new Laravel app
  2. Install Dusk
  3. Install Telescope
  4. Edit your Dusk test to include:
<?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');
        });
    }
}
  1. Run your Dusk test.

The first test should pass, but the second one doesn't and gives you the error above.

driesvints commented 5 years ago

@Noogic @davidhemphill do the tests pass when you comment out the DumpWatcher in your telescope.php file? Think this might be the culprit.

themsaid commented 5 years ago

We've fixed that, will be available next release.

Noogic commented 5 years ago

I still get the same error with v.0.1.8.

Is this supposed to be fixed?

zanechua commented 5 years ago

@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.

Noogic commented 5 years ago

@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

zanechua commented 5 years ago

@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

foxted commented 5 years ago

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
bilfeldt commented 5 years ago

Which version of Telescope fixed this @themsaid? It seems to still be present in version 1.0.7.

themsaid commented 5 years ago

Using Laravel 1.0.7 my dusk tests pass. Why do you have Telescope enabled while running Dusk tests?

bilfeldt commented 5 years ago

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?

mikeminckler commented 5 years ago

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.

themsaid commented 5 years ago

@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.

zanechua commented 5 years ago

I agree with @mikeminckler that this should probably be documented especially with such a breaking incompatibility.

bilfeldt commented 5 years ago

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?

Livijn commented 5 years ago

You could just add <env name="TELESCOPE_ENABLED" value="false"/> to the phpunit.xml-file.

bilfeldt commented 5 years ago

@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.

adelynx commented 5 years ago

I add TELESCOPE_ENABLED=false to my testing environment file and it's work fine. Thanks

lionslair commented 5 years ago

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

vesper8 commented 5 years ago

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

mvdnbrk commented 5 years ago
ReflectionException: Class env does not exist

Just needed an hour or so to figure this out :unamused:

vesper8 commented 5 years ago

@themsaid can't anything be done about this? it's affecting all new installs for those of us that use tests

lionslair commented 5 years ago

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); }

claytonrcarter commented 5 years ago

@mvdnbrk Another example (as happened to me):

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.

mvdnbrk commented 5 years ago

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.

lionslair commented 5 years ago

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.

sustained commented 5 years ago

This issue has been driving me up the wall for hours.

ermand commented 5 years ago

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 😃

sustained commented 5 years ago

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.

lionslair commented 5 years ago

the solution made no difference for me.

Also dusk appears to create its own phpunit xml file. Did not solve the issue when I added it there either.

nathanbarrett commented 5 years ago

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.

aocneanu commented 5 years ago

Temporary solution, set:

'enabled' => env('TELESCOPE_ENABLED', env('APP_ENV') !== 'testing'),

in telescope.php

talovicnedim commented 5 years ago

+1 for documenting.

TELESCOPE_ENABLED=false in .env.testing works for me.

mateusgalasso commented 5 years ago

I've runned php artisan clear php artisan config:clear

Solved for me

njoguamos commented 5 years ago

You could just add <env name="TELESCOPE_ENABLED" value="false"/> to the phpunit.xml-file.

This worked for me like a charm

zhorton34 commented 5 years ago

Two Solutions:

Solution One: (mentioned several times above):

  1. Open phpunit.xml
  2. Add <env name="TELESCOPE_ENABLED" value="false"/>

Solution Two:

  1. Copy .env to .env.testing
  2. Open .env.testing
  3. Change TELESCOPE_ENABLED=true to TELESCOPE_ENABLED=false

If Testing With Dusk:

  1. Copy .env to .env.testing
  2. Open .env.testing
  3. Change TELESCOPE_ENABLED=true to TELESCOPE_ENABLED=false
  4. Copy .env.testing to .env.dusk.local
yaranliu commented 5 years ago

None worked for me. I have manually paused monitoring from /telescope dashboard and it worked.

M-Farag commented 5 years ago

adding TELESCOPE_ENABLED=false to my .env solved the problem

andriihorpenko commented 5 years ago

I am not using Dusk and this error still persist in some tests. This should definitely be documented.

dillingham commented 5 years ago

just ran into this issue, can't telescope check if testing?

<env name="TELESCOPE_ENABLED" value="FALSE" />

added to my phpunit.xml

Punksolid commented 5 years ago

What if I want to track a single test with telescope ?

bolechen commented 5 years ago

just ran into this issue, can't telescope check if testing?

added to my phpunit.xml

WouterFlorijn commented 5 years ago

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.

lionslair commented 5 years ago

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

amadeann commented 5 years ago

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.

kevinb1989 commented 5 years ago

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.

Screen Shot 2019-06-15 at 6 35 02 pm
Shelob9 commented 5 years ago

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>
sustained commented 5 years ago

Why is this closed? Lots of people are still having this issue.

WyattCast44 commented 5 years ago

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 ?

mikemunger commented 5 years ago

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. :(