Building along in 5.4 instead of 5.3

[ghost]

I see people here complaining that testing is different in Laravel 5.4 and using a compatibility package for this. If you have an old project and you want to use the compatibility package that ok. But if you are starting a new project with Laravel 5.4 use the new syntax. In the course we have learned to use $this->get/$this->post instead of the old $this->visit and Laravel 5.4 is doing the exact thing. I think that Taylor Otwell took the course also :) The changes are not big and you will learn to use the correct test for the mission. To do test with visit and insert data to the input field use Laravel Dusk testing tool. Its worth it I think

[nickpoulos]

I am taking the course, but did find it difficult to follow along as much while using 5.4. It wasn't completely obvious using $this->get/post instead of visit. I actually tweeted Adam to ask about using get, when he recommended the compatibility package, but there seems to be an issue with that not using the DatabaseMigrations trait correctly.

@elihayun1 do you have any of your source code from following along the course using 5.4? Or could you make a post or quick file detailing some of the methods and code you are using to substitute? I know that would be super helpful for me, and I am sure many others.

Thanks man.

[sileence]

I'm recommend you all to follow the course with the same version than @adamwathan is using, in this case 5.4. You'll learn to develop apps using TDD with Laravel in general. The version doesn't really matter that much. Upgrading from 5.3 to 5.4 is very easy (especially if you have tests).

I'm sure the problem with the database migrations etc. in 5.4 will be fixed soon.

[nickpoulos]

For the first few lessons, he is almost certainly using 5.3. It is easy to upgrade, yes. There is just some confusion because 5.4 changes Laravel testing, leading to some syntax mismatches with Adam's videos and other things. Not a deal breaker by any means, just a few extra steps to get everything situated correctly. I am moving along just fine using 5.4, but I dont necessarily agree with Eli's comment that it was very easy and obvious to use some of the newer 5.4 syntax. And I wanted to say that if anybody else had tips or tricks, or even just some comments clearing up some of the 5.3 vs 5.4 info to please post, because I think it would be helpful to many people.

[drbyte]

I'm sure the problem with the database migrations etc. in 5.4 will be fixed soon.

Ya, Adam posted over here that a recent 5.4 update fixed issues with db migrations and browserkit: https://github.com/nothingworksinc/ticketbeast/issues/26#issuecomment-276102443

[drbyte]

I'm recommend you all to follow the course with the same version than @adamwathan is using, in this case 5.4.

Yes, it's easiest to use the same version he's using ... which in this case is 5.3 up to and including the latest lesson posted last week: https://github.com/nothingworksinc/ticketbeast/blob/master/composer.json#L9

[adamwathan]

Yeah I would recommend using 5.3 if you are going to build the app alongside the lessons.

Maybe this week I'll do a few lessons on upgrading us to 5.4 though 👍🏻

[joselfonseca]

It is easy to upgrade, and you can still use browserkit, in the upgrade guide there are instructions for that. I just upgraded a project from 5.3 to 5.4 and it took me less than one hour to fix the tests to continue using browserkit while I migrate them later to Dusk. Unit tests are not really affected by it.

[ghost]

@nickpoulos I do have this sample for you

`/* @test / function can_create_a_course() { $response = $this->get(route('courses.index'));

    $me = $this->getUserWithRole('teacher');

    Auth::login($me);

    $response = $this->post(route('courses.store'), [
        'teacher_id' => $me->id,
        'title' => 'Course 1',
        'slug'  => 'test-2',
        'description' => 'xx'
        ]);

    $course = Course::whereSlug('test-2')->first();

    $this->assertNotNull($course);
   $this->assertEquals($me->id, $course->teacher_id);

    $response->assertStatus(302);
}`

As you can see I am using 5.4 syntax

[ghost]

If you want to follow the courses, you should use 5.3. I am developing a brand new application with 5.4 and I am taking the testing techniques from the course and try to use them with 5.4. I am looking at the test class from the source code to find out what to do what I have a problem. As you can see from the example above, you cannot use $this->assertStatus but you have to deal the status from the response. It is a great idea for @adamwathan to make some extra lessons how to upgrade

[drbyte]

You can see the corresponding assertions in the browserkit repo, to know what calls you can make instead: https://github.com/laravel/browser-kit-testing/tree/master/src/Concerns

[zackkrida]

@adamwathan just made a video about this, for anyone still curious: https://adamwathan.me/2017/02/02/upgrading-your-test-suite-for-laravel-54/

[AdamEsterle]

@adamwathan Can you shed some light - perhaps overall architectural reasons - on why Laravel 5.4 decided to move in this testing direction? It seems more complicated (though, I agree, not a big deal) to store the response separately instead of it being store on the state.

I'm sure there are great reasons for the change; I am just ignorant of them.

[ghost]

Watch this video https://course.testdrivenlaravel.com/lessons/module-2/browser-testing-vs-endpoint-testing I guess that Tylor decided to separate the logic feature tests from the visual behavior.

[adamwathan]

I think the primary reason is that it was a bit frustrating having a bunch of testing features that felt like you were using the browser (click this, fill in this field, etc.) but wouldn't work properly as soon as the page had any JavaScript.

So with Laravel 5.4, Dusk was introduced to have proper, full-featured browser testing, and the sort of almost-real-browser-testing stuff was intentionally pared back, so that it's more explicitly about testing at the HTTP level and dealing with requests and responses rather than interacting with pages.

Re: the switch to have a response object returned instead of storing it as state, I think that's just Taylor's preference. It has some advantages when making multiple requests in the same test, and makes things feel a little "tidier" in my opinion.

In Laravel 5.3 for example, there was this sort of implicit rule that you couldn't call $this->assertResponseStatus(404) until you had actually made a request, since the response was stored as instance state.

With 5.4, you don't have to worry about that anymore since it's impossible to even call assertStatus without having a $response to call it on.

Pros and cons to both approaches for sure.

[jartaud]

@adamwathan Hi Adam! I have upgraded a L5.3 app to L5.4 and sqlite :memory: no longer works. I watch https://course.testdrivenlaravel.com/lessons/module-11/upgrading-to-laravel-5-4 and it seems to work. Any tric? Maybe it's because i'm using Browser Tests?

[rnottinger]

same here.

this is what i found when researching this issue.

https://github.com/laravel/dusk/issues/73

splatEic... "You won't be able to use an in memory db because, as Taylor has pointed out, the tests and the web server are running under separate processes. You could use a common mysql db connection or a single sqlite file, and then do a migrate/refresh option (although this does rely on all your migrations supporting down migration steps)."

https://medium.com/@splatEric/working-with-laravel-dusk-54d67cc0241b#.ox58metsz

On Mon, Feb 6, 2017 at 10:13 AM, Josué Artaud notifications@github.com wrote:

@adamwathan https://github.com/adamwathan Hi Adam! I have upgraded a L5.3 to L5.4 and sqlite :memory: no longer works. I watch https://course. testdrivenlaravel.com/lessons/module-11/upgrading-to-laravel-5-4 and it seems to work. Any tric? Maybe it's because i'm using Browser Tests?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nothingworksinc/ticketbeast/issues/27#issuecomment-277730144, or mute the thread https://github.com/notifications/unsubscribe-auth/AGaiNznMuil75lH7i4QJqiU0l_zfVL_Rks5rZ0acgaJpZM4LxrLh .

-- Richard Ottinger Computer Programmer Eastex Crude Company 903-573-3379 Mobile 903-856-2401 x132 Office

[adamwathan]

Ah yeah, if you are using Dusk you won't be able to use an in-memory DB.

We'll eventually switch to a MySQL DB in this course too, but in the mean time here's my recommended approach when using MySQL as a test database:

https://adamwathan.me/2016/11/14/a-better-database-testing-workflow-in-laravel/

[jartaud]

L5.4 php 7 mysql 5.7 Kubuntu 16

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT trans2 does not exist

/vendor/laravel/framework/src/Illuminate/Database/Concerns/ManagesTransactions.php:205
/vendor/laravel/framework/src/Illuminate/Database/Concerns/ManagesTransactions.php:186
/vendor/laravel/framework/src/Illuminate/Foundation/Testing/DatabaseTransactions.php:22
/vendor/laravel/framework/src/Illuminate/Foundation/Testing/TestCase.php:127
/home/me/.composer/vendor/phpunit/phpunit/src/TextUI/Command.php:188
/home/me/.composer/vendor/phpunit/phpunit/src/TextUI/Command.php:118

namespace Tests;

use Illuminate\Foundation\Testing\TestCase as BaseTestCase;
use Tests\DatabaseSetup;

abstract class TestCase extends BaseTestCase
{
    use DatabaseSetup, CreatesApplication;

    protected function setUp()
    {
        parent::setUp();
        $this->setupDatabase();
    }
}

namespace Tests\Feature;

use Tests\TestCase;
use Illuminate\Foundation\Testing\WithoutMiddleware;
use Illuminate\Foundation\Testing\DatabaseMigrations;
use Illuminate\Foundation\Testing\DatabaseTransactions;

class ExampleTest extends TestCase
{
    use DatabaseTransactions;

    /**
     * A basic test example.
     *
     * @return void
     */
    public function testBasicTest()
    {
        $response = $this->get('/');

        $response->assertStatus(200);
    }
}

[adamwathan]

@jartaud Try removing the use DatabaseTransactions trait from your ExampleTest, I think you are getting some doubled up transactions happening which is giving you some trouble.

[jartaud]

@adamwathan Thank you so much!

[erikverbeek]

I've just finished working through the first module while using L5.4, consulting the Laravel docs to adapt the code where needed. I haven't run into any major problems code wise.

I do however notice another annoying change when TDDing the feature tests. When you run your red tests as you're building towards green, you don't get the useful error messages about where your code breaks, just that the response isn't as expected.

An example:

If I go the the show method in the controller and mistype

Concart::published()->findOrFail($id);

All I get is the error message

Failed asserting that '<!DOCTYPE html>
<html>
  <!--  The whole Whoops HTML -->
</html>' contains "The Red Chord".

The actual error that interests me is

testing.ERROR: Symfony\Component\Debug\Exception\FatalThrowableError: Class 'App\Http\Controllers\Concart' not found

which can now only be found by looking in the laravel.log. Is there any way to get these actual errors back into the console when your tests break? It would really help when you're letting the errors drive your coding.

[casperboone]

@erikverbeek Disabling exception handling so that the actual exception will be thrown during the execution of your tests is covered in the second module (see this commit https://github.com/nothingworksinc/ticketbeast/commit/c7837af96a4296ed160cae73c5e61526839116e1).

[adamwathan]

@erikverbeek you totally can! That's what I use the disableExceptionHandling helper for:

https://github.com/nothingworksinc/ticketbeast/blob/master/tests/TestCase.php#L29-L38

When you call that method at the beginning of a test, it'll prevent Laravel from turning exceptions into 500 "Whoops!" pages, and let the exceptions bubble all the way back to PHPUnit.

Here's a screencast dedicated to it (some things are probably slightly different in 5.4, but you'll get the idea):

https://adamwathan.me/2016/01/21/disabling-exception-handling-in-acceptance-tests/

[erikverbeek]

I got it working. I copied the function and use statements from your commit and had to just add

use Exception;

to TestCase.php to have it work in L5.4.

Thanks @adamwathan and @casperboone. On to module 2!

[philip]

Is there a semi-final verdict on this subject?

For example, I'm a Laravel (and testing) newbie that will begin this course next week and want to know which Laravel version to use. Meaning, will I be confused using 5.4 or are they close enough?

As a feature request, here are a couple of ideas:

• Offer a semi-simple 5.3->5.4 test cheatsheet that'll help with this video series
• Add a note section to each video and note the differences / potential confusion points worth considering for said video, somewhere near the "View Code" button

[GabrielQuintana]

@philip there's a video explaining what to update, I followed along in 5.4 and didn't have any issue, when I got the method not found issue I just referred to the update video

[cashlion]

You could also bring in the BrowserKit compatibility package, and then create a BrowserKitTestCase, as mentioned in the 5.3 - 5.4 upgrade guide, that your Tests will extend.

Later on in the course, Adam covers the upgrade but I'd recommend following along using this workaround and the dropping it once you get to that module.

[naillizard]

Just follow the course in L5.3, then read https://laravel.com/docs/5.4/releases#laravel-5.4, you should be able to apply what you've learned from the course on L5.4. If you try to do the other way around without some knowing the basics of Laravel, it will take you longer.

[martonbaranyai]

Yeah if you’re new to Laravel, better follow along with 5.3.

There is a module in the course where Adam upgrades the code to 5.4

It’s also great to see how he thinks when it comes to different errors due to the upgrade

On 31 Mar 2017, at 05:10, dtunes notifications@github.com wrote:

Just follow the course in L5.3, then read https://laravel.com/docs/5.4/releases#laravel-5.4 https://laravel.com/docs/5.4/releases#laravel-5.4, you should be able to apply what you've learned from the course on L5.4. If you try to do the other way around without some knowing the basics of Laravel, it will take you longer.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nothingworksinc/ticketbeast/issues/27#issuecomment-290604098, or mute the thread https://github.com/notifications/unsubscribe-auth/AC9hmulebIHGztfB_2PIzJeRbu9ReGP3ks5rrG66gaJpZM4LxrLh.

[adamwathan]

Hey @philip those are good suggestions; I'll try to incorporate those.

If you're new to Laravel, I would recommend starting on 5.3 and then upgrading when you get to the section of the course where we do the upgrade. It's not hard to start on 5.4 from the beginning, but if you're not comfortable troubleshooting when things aren't working as expected, it's a lot easier to just follow along with 5.3 to start.

[jesseleite]

It's not hard to start on 5.4 from the beginning, but if you're not comfortable troubleshooting when things aren't working as expected

I am working on a pet project along with the videos, and I chose start with 5.4, but I also watched the two Upgrading Our Suite to Laravel 5.4 videos quite early on, just to see what differences I'd be dealing with.

[philip]

Thanks everyone for the thoughts; I'll give 5.3 a go. As a benefit I get to learn/experience how to upgrade Laravel :)

[eezhal92]

hi guys, i'm having an issue.

i'm using laravel 5.4. when running the test, the stack traces of errors appear as html response and it becomes difficult to see the error messages. what i wanted is it show in the console like in adam's video. anyone could help?

thanks

[denismitr]

I think you need to put that code into your TestCase file and use those methods as necessary

    protected function disableExceptionHandling()
    {
        $this->oldExceptionHandler = $this->app->make(ExceptionHandler::class);
        $this->app->instance(ExceptionHandler::class, new class extends Handler {
            public function __construct() {}
            public function report(\Exception $e) {}
            public function render($request, \Exception $e) {
                throw $e;
            }
        });
    }
    protected function withExceptionHandling()
    {
        $this->app->instance(ExceptionHandler::class, $this->oldExceptionHandler);
        return $this;
    }

[adamwathan]

Hey @eezhal92 yeah, @denismitr is right, you need some way of disabling exception handling so PHPUnit gets a chance to see the real error instead of letting Laravel turn that into an HTML page.

We cover it in one of the first few modules for sure, but here's a gist that talks about it a bit as well:

https://gist.github.com/adamwathan/125847c7e3f16b88fa33a9f8b42333da

[eezhal92]

Got it! Thanks a lot @adamwathan @denismitr!