[9.x] Handle requests in test (rather than separate server process)#1170
[9.x] Handle requests in test (rather than separate server process)#1170inxilpro wants to merge 4 commits intolaravel:masterfrom
Conversation
|
Thanks for submitting a PR! Note that draft PR's are not reviewed. If you would like a review, please mark your pull request as ready for review in the GitHub user interface. Pull requests that are abandoned in draft may be closed due to inactivity. |
|
This would take Dusk to the next level in my opinion. Being able to assert things like in normal tests (Mailables, Events, Jobs etc) would be game changing for us. Are there any performance improvements by running the tests via this method? I was hoping to install this to test against our quite large Dusk test suite, but I am in some kind of composer dependency hell |
|
@JayBizzle what happens if you try: composer require laravel/dusk:dev-proxy-requests --dev -W |
|
Thanks for trying to help, dont want to derail this PR with technical support, I think i have other packages conflicting. Been down the ChatGPT route trying to fix this, but to no avail composer require laravel/dusk:dev-proxy-requests --dev -W
./composer.json has been updated
Running composer update laravel/dusk --with-all-dependencies
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires laravel/dusk dev-proxy-requests -> satisfiable by laravel/dusk[dev-proxy-requests].
- laravel/dusk dev-proxy-requests requires react/http ^1.10 -> satisfiable by react/http[v1.10.0, v1.11.0].
- react/http[v1.10.0, ..., v1.11.0] require psr/http-message ^1.0 -> found psr/http-message[1.0, 1.0.1, 1.1] but these were not loaded, likely because it conflicts with another require. |
Right now, Dusk makes requests to a separate server process. This has a few downsides:
_dusk/routes rather than using normal factories/setup.env.duskhandling is necessaryRefreshDatabase, aren't availableThis proof-of-concept adds an HTTP server and custom web driver implementation that lets us handle the entire Dusk lifecycle inside our test process. This allows us to treat incoming browser requests as though they were the same as
$this->get(...)or$this->post(...)right in the test case.Considerations
For the most part, this is a pretty minimal change for the impact it could have. That said, there are a few things to consider:
https://demo-app.test/profileintohttp://localhost:8099/profile. This doesn't account for things like domain-routing. Probably the easiest solution is to just pass the entire request as a query string, so something likehttp://localhost:8099/?url=https://demo-app.test/profile. This shouldn't be that hard, but might need some further thought.Laravel\Dusk\Http\Controllers\UserControllerwhich is no longer necessary with this approach, and the logic around.env.duskthat is also not necessary. Before I go ahead and make the diff that much larger, I'd like a little bit of community/maintainer feedback.If anyone out there has a big Dusk testsuite that they want to try this with, I'd love some real-world feedback!
How to test
If you don't have
repositorieskey in yourcomposer.jsonfile, add one, and then add my fork to it.Then, install my branch:
Finally, if you
DuskTestCaseimplements thedriver()method, you need to swapFacebook\WebDriver\Remote\RemoteWebDriverforLaravel\Dusk\Driver\AsyncWebDriver.