A PHP framework for web artisans.

This PR proposes to use Pest as the default testing framework in Laravel.

Advantages

Simple

Pest adheres to Laravel's core values by design. Its main focus is on simplicity:

• Clean and expressive syntax
• Extensive and thorough documentation
• Easy to read errors and stack traces with the most beautiful test reporting in the world

Powerful

Pest provides handy shortcuts to perform common actions in your tests:

• Higher order tests: easy to write, easy to read
• Code coverage: nice reporting straight from your console
• Datasets: they let you run the same test multiple times with different data

Backward compatible

First of all, PHPUnit would still be part of Laravel, as internally, Pest works on top of it. This should reassure most people with years of PHPUnit experience:

• Pest can run existing PHPUnit test suites natively, no need to rewrite them
• Pest can be a progressive buy-in, just write your new tests with its syntax
• You can still run PHPUnit if you don't want to try Pest

Code example

The syntax should be familiar if you’ve used other testing tools such as Mocha or Jest. Here’s a quick example of what you can expect:

<?php

beforeEach(fn () => factory(App\User::class)->create());

it('has a home page', function () {
    $this->get('/')->assertOk();
});

With its clean syntax, Pest have proven to help bring a few complete beginners to the testing world. Abstracting away most of PHPUnit's boilerplate code makes it easier for them to learn testing. This in itself should be a big benefit to the community.

Community

Pest already has dedicated team members working actively on multiple projects, including:

• Documentation
• PHPStorm plugin
• Framework features
• Plugins
• Videos
• Community Discord

This PR introduces a PHPUnit ~~watcher~~ bootstrap file that caches the config before the test suite runs for the first time, which in my benchmarks reduces the boot time of the Kernel during a test run by ~50% without any additional work by the developer.

This will only really have an impact on a larger test suite, but personally I think it is a worthwhile thing to consider.

The benchmark test suite ended up with the following durations:

• Without caching: 9.15s
• With caching: 4.2s

Caching the config before a test run is good for a couple of reasons:

1. It's faster.
2. It is closer reflects what you use in production.

If, for example, you cache your routes in production but try deploy a sneaky closure route, your app is gonna blow up when you go to cache the routes during production. Having this in place will help you catch that kind of thing during testing, either locally or during CI. (you could catch this in CI if you are already calling this command before running the tests).

The PHPUnit ~~listener~~ bootstrap file will cache the config for the test environment before a test is run. Because it is in "User land" it is 100% opt-in. If you don't want it, don't use it. One handy thing about running the cache command in a ~~PHPUnit listener~~ bootstrap file (as opposed to say in a composer script) is that it will already have the environment variables from the phpunit.xml file loaded, so we don't need to read those ourselves.

Notes

• As this doesn't require any changes to the framework, it is totally possible to just package up, which I'm more than happy to do.

• The watcher could be kept in core with just the phpunit.xml changes made here.

• it is possible we could see similar results by caching routes and events, but I haven’t tested this yet. I plan to extend the benchmark repo I setup to also have some feature (http) tests so we can see what kind of impact that might have on a test suite as well.

This PR is a simpler approach to my first run at this: https://github.com/laravel/framework/pull/28998

Hey everyone. With this PR I want to propose a new dedicated Integration test directory and in-memory DB defaults to the default Laravel test suite. As someone who's worked quite a bit with different test suites over the past years I think I can say for myself I have quite some experience in this area and wanted to share some small things through this PR.

In-memory DB

The first thing I want to change with this PR is to provide new defaults for the database that's being used when running the test suite of the app. This is probably the very first thing I change for every single app I start working on. All of my tests run in memory against a sqlite database which is pretty fast I must say.

While it is true that the current default Laravel test suite doesn't requires a database to be set up, it is from my understanding that a lot of people do add these new defaults as soon as they need to start testing against a database. It's also true that an sqlite can't mimic a MySQL or Postgres database which is probably used in production but the speed of an in-memory database makes it much more suited for running tests. Therefor, I believe these are good defaults to have in the skeleton.

Integration Directory

From what I often read on issues and on Twitter I still see that there's a lot of confusion about what a Unit test is and what an Integration test is. A unit test is something you test in isolation, without booting the entire app. You, for example, test a single object or function without any outside dependencies and maybe mock some of those dependencies. These tests usually run really fast.

Integration tests, however, are tests which test the behavior of different components together. They aren't full cycle tests like End-to-End tests or Feature tests but they do require some additional setup (like a database for example). These tests tend to run a bit slower.

In the current skeleton setup you only have two directories: a Unit test directory and a Feature test directory. I think there's room for an Integration directory which actually copies the behavior of the current Unit test directory. Because you see, the current default Unit ExampleTest extends from the default TestCase. This isn't wanted for unit tests because it boots up the entire framework and thus slows down these tests which should actually run much faster (because they should be isolated).

What I changed is that I've added a dedicated Integration test directory which keeps the current behavior of extending from the Laravel TestCase class and can be used to test different components in your app which require the framework to be booted. The old Unit ExampleTest is updated to only extend the default PHPUnit Testcase so the framework isn't booted and you get the speed boost for these types of test. It's also ok that you don't have all of the Laravel test methods for the Unit tests because most of these methods are meant for Integration tests and provide no value in Unit tests.

I also wanted to make a clear different between what a Unit test and what an Integration test is inside the example tests. For the Unit tests I'm testing if the User model accepts a name attribute and that it can be fetched properly (most people also don't realize you can perfectly Unit test Eloquent models as long as you don't do DB operations). For the Integration test I've added an example which actually makes use of the newly in-memory database defaults and I seed three users and fetch them with the User model.

Conclusion

What I'm mainly trying to achieve with these changes is to educate people better about testing in general and what the different types of tests are. And I'm hoping this saves a lot of people some time when they start on a new Laravel app (even though the changes are minimal).

I'm sorry for writing such a large description. I'm usually against these myself hehe. But I wanted to be thorough enough to explain the reasoning behind it 🙂

Let me know what you think.

Update: Taking from the feedback here I've made changes to this PR. More info here: https://github.com/laravel/laravel/pull/5169#issuecomment-562202777

Hi,

So currently, if I have something like this:

Route::get('/', function()
{
    echo 'First';

    return Redirect::to('second');
});

Route::get('second', function()
{
    return 'Second';
});

The redirect never happens and I just get an empty response. That's because Laravel isn't utilising output buffering. I have added output buffering, which means you can echo anything, set session values or whatever then return an object that's an instance of Laravel\Redirect, and the redirect will happen.

Signed-off-by: Ben Corlett [email protected]

When looking through errors it is not very clear where an error occured. For example 404 errors: from exception 'Symfony\Component\HttpKernel\Exception\NotFoundHttpException' in /var/www/html/project/vendor/laravel/framework/src/Illuminate/Routing/RouteCollection.php:140 you don't know on what path that happend (and beginners don't even get that this is just a 404). Error 404 on GET http://mydomain.com/my-route: exception 'Symfony\... would make much more sense imho..

(Follow-up on https://github.com/laravel/laravel/pull/2764 for 4.3 branch)

By simply setting Form::$remember to true, this makes forms automatically be re-filled with the previously entered data - this way this does not have to be done by hand for every field (very tire-some in large forms).

Some things to note:

• I realize this adds state to the Form helper class. Is that bad? I don't think so (at least in this case), but...
• ...maybe there is a more Laravel-ish way for enabling this feature instead of using Form::$remember. I could imagine an extra parameter to Form::open(), but I'm very much looking for suggestions.
• I haven't yet tested this with select boxes, but don't want to before somebody tells me about the chances of getting this pull request merged.
• Changing the default $value parameter is necessary so that password fields will not be re-populated.
• Input::old() has to be repopulated manually, e.g. by redirecting with with_input().

Based on a discussion with Taylor, I've added a HandleCors middleware similar to TrustProxies. This is using https://github.com/fruitcake/laravel-cors (formerly barryvdh/laravel-cors), which is updated with a few breaking changes to v1 (still in dev, awaiting possible feedback for this integration).

This would make it easy to implement CORS handling in Laravel, based on path matching. An alternative approach would be route middleware, but the biggest issue is that it wouldn't match 404-routes, which would in turn lead to difficult debugging issues.

An approach could be to add a fallback route for the API middleware though, if you prefer route middleware, instead of the paths option.

When running Model::firstOrNew() with a non mass-assignable field (id), it always returns the very first table row, regardless if the row exists or not.

Seems to have been introduced with this commit: https://github.com/laravel/framework/commit/df2761f0f3e24e884a9db0271044cff41238b564

I have made this change in just about every project I've built using Laravel, so I thought I would share it. If it's bad or wrong or not useful, that's fine, but I thought I would put it out there.

This "AJAXful" routing works pretty much like the RESTful routing; it prepends "ajax_" to your controller actions when the request is an AJAX one.

Here's a RESTful and AJAXful controller example:

<?php

class MyController extends Base_Controller {
    public $restful = true;
    public $ajaxful = true;

    public function get_index()
    {
        return View::make('my.nifty_view');
    }

    public function ajax_get_index()
    {
        return json_encode(array('my_nifty_content' => 'Hooray, AJAX'));
    }
}

Likewise, for non-RESTful controllers:

<?php

class MyController extends Base_Controller {
    public $restful = false;
    public $ajaxful = true;

    public function action_index()
    {
        return View::make('my.nifty_view');
    }

    public function ajax_action_index()
    {
        return json_encode(array('my_nifty_content' => 'Hooray, AJAX'));
    }
}

Pretty straightforward, but it's been helpful for me.

Hi Taylor,

I made a change to the bundle class, which allows one to set multiple handles for a bundle. It's a simple change, that won't add a lot of extra overhead, but makes the routing of bundles a bit more flexible.

A practical example would be when you have two separate blogs on your website (for example in different languages). They would both use the same blog bundle, but serve up different content based on the URI. With this addition you don't have to include a reference to 'blog' anymore like /blog/myfirstblog and /blog/mysecondblog. Instead you can simply configure multiple handles and use /myfirstblog and /mysecondblog directly. Looks a bit cleaner, I think.

Hope you like it :)

In some cases, the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY variables are not enough to authenticate to the AWS API. The AWS_SESSION_TOKEN must be provided as well.

The AWS_SESSION_TOKEN is part of the "Temporary Security Credentials" authentication mechanism. See the AWS Documentation.

One of those cases is when Laravel runs on AWS Lambda. In that case the AWS_SESSION_TOKEN variable is populated (source).

With the default Laravel installation, when listing files in the s3 drive, I get:

Aws\S3\Exception\S3Exception Error executing "ListObjects" on "https://redacted.s3.amazonaws.com/?prefix=&delimiter=%2F&encoding-type=url"; AWS HTTP error: Client error: GET https://redacted.s3.amazonaws.com/?prefix=&delimiter=%2F&encoding-type=url resulted in a 403 Forbidden response: <?xml version="1.0" encoding="UTF-8"?> <Error><Code>InvalidAccessKeyId</Code><Message>The AWS Access Key Id you provided does not exist in our records.</Message><AWSAccessKeyId>redacted</AWSAccessKeyId><RequestId>redacted</RequestId><HostId>redacted</HostId></Error>

By adding the token line to the configuration, the API call succeeds and my application works as expected.

I expect that adding the line will not cause any regression in cases where the AWS_SESSION_TOKEN is not define: the token option will remain empty.

This pull request adds PHPUnit 10 support to Laravel. Note that, before any release here on the skeleton, the following tasks need to be performed first:

1. [ ] Merge and release: https://github.com/laravel/framework/pull/45416.
2. [ ] Ensure Collision ^7.0 is released with support for Parallel Testing ( it may take a while ).
3. [ ] Adjust the composer.json with the latest version of laravel/framework, and release this pull request.

Note: this PR is one of four parallel pull requests to add first class support for Ably to Laravel. Please find the other PRs here:

• laravel/docs#8120
• laravel/framework#43685
• laravel/echo#351

Background: the current Ably broadcaster uses the Pusher JavaScript SDK and the documentation instructs users to use Ably with the Pusher compatibility mode enabled. We’ve received a lot of feedback that various features of the Ably Laravel integration don’t work as expected, often caused by the fact that there’s a dependency on the Pusher JavaScript SDK which we have no control over. This collection of PRs adds a new broadcaster which uses the ably-js SDK which means that we can ensure that the Ably broadcaster will remain stable. We are more than happy to take feedback and answer any questions about the work presented here :)

Adds example environment variables to .env.example for the new AblyBroadcaster and references them in broadcasting.php.